个性化提要的缓存策略

Question

假设用户可以订阅其他用户的帖子、标签或他可能想要的任何其他类似条件。

在他的提要上，应用返回用户之间相同的“主要提要”，并且还根据他的“订阅”标准提供提要项目（提要通过 API 提供）。

Feed 数据是一种实体（帖子）。而且该提要是无限滚动（分页）的，这增加了额外的复杂性。

如果用户之间的提要相同，缓存是微不足道的，但在个性化提要的情况下，我想不出最好的方法是什么。

每个“页面”都按日期范围偏移（特定日期）。

我能想到的一种方法是：

'same feed' 部分由日期键（一些表示日期范围的键）缓存。

个性化帖子提要项将单独缓存。然后我根据标准保留帖子ID数组，例如创作用户，或分配给喜欢的标签（用户＃1：[10,15,23,64 ...]，标签＃FOO：[1,2,5,10 ...]），以及分隔符它们按日期范围（根据它们适合的分页部分），然后通过 mget/getMulti 从 Redis 或 Memcahed 的 id 获取这些帖子并返回组合结果。

但这种方法对我来说有点“不正确”，因为它是如此复杂。 要么， 是否在没有缓存的情况下使用经过微调的数据库（比如说在 RAM 中运行，或完全缓冲） - 在这种情况下可行（渲染/序列化时间并不重要，因为我几乎将其原始传递给客户端）？

我寻求与平台/缓存层无关的一般策略建议。

Answer 1

以下设计可能是更好的方法。

查询处理器层： 通常，这将是一个 REST API，它接受查询并返回帖子提要（按日期或帖子计数等分页）。这将搜索帖子存储（数据库，索引存储，如 solr 等）并仅获取帖子 ID 列表[注意：不要加载所有帖子，只加载它们的 ID。

帖子服务层 查询处理器层将使用此服务层来获取所有给定 ID 的帖子。首先，它联系 cache-service 层 请求带有 ID 的帖子。如果没有找到它们，那么 get 将从存储中加载帖子并将其返回给查询处理器。此外，它会将加载的帖子发送到缓存服务层以缓存它以供将来使用。

缓存服务层 给定一个帖子 ID，只有当它存在于缓存中时它才会返回该帖子。

现在，帖子的缓存键将帮助您加快帖子检索时间。

EG： Redis 为您提供键的模式匹配。因此，使用格式为 postId:date:userId:tag1,tag2 的键，您可以非常轻松地发布一篇文章或获取一个日期范围内的所有文章，带有标签或 userId 等。

Answer 2

您所描述的内容基本上类似于 Facebook 可扩展性挑战，评论为 here。基本上它是通过提前创建个性化提要并将它们放入 memcached 来解决的。

为了进一步优化，您可以记录用户阅读提要的频率并调整缓存对象的生命周期，以便它们为重度用户提供更短的时间。

同样，您需要较少刷新那些由很少更新的源提要组成的个性化提要。 最后，据我所知，Facebook 并没有完全解决由超过 5.000 个来源组成的提要的问题，这可能就是为什么他们首先设置了 5.000 个朋友的限制，然后在创建时选择忽略来自不太亲密的朋友的更新。个性化的饲料。因此，如果您可以承受丢失一些条目的后果，最后一步就是忽略一些来源。