个性化提要的缓存策略

Question

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

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

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

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

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

我能想到的方法之一是：

“相同提要”部分按日期键（某些键表示日期范围）缓存。

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

但是这种方法对我来说有点“不正确”，因为它太复杂了。或者，是否使用微调的 DB（假设在 RAM 中运行，或在其中完全缓冲）而不进行缓存 - 在这种情况下可行（渲染/序列化时间并不重要，因为我几乎将其传递给客户端）？

我寻求平台/缓存层不可知的一般策略建议。

Answer 1

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

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

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

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

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

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