假设用户可以订阅其他用户的帖子、标签或他可能需要的任何其他类似条件。
在他的提要上，应用程序返回用户之间相同的“主要提要”，并根据他的“订阅”标准提供提要项目(提要通过 API 提供)。
提要数据是一种实体(帖子)。而且该提要是无限滚动(分页)的，这增加了额外的复杂性。
如果提要在用户之间是相同的，缓存是微不足道的，但在个性化提要的情况下，我想不出什么是最好的方法。
每个“页面”都按日期范围(特定日期)偏移。
我能想到的一种方法是:
'same feed' 部分由日期键(一些代表日期范围的键)缓存。
个性化帖子提要项目将单独缓存。然后我根据标准保留帖子 ID 的数组，例如创作用户，或它被分配给喜欢的标签(用户#1:[10,15,23,64 ...]，标签#FOO:[1,2,5,10 ...])，以及分隔符他们按日期范围(根据他们适合的分页部分)，然后通过 mget/getMulti 从 Redis 或 Memcahed 获取这些帖子并返回组合结果。
但我觉得这种方法有点“不对”，因为它太复杂了。 或者， 是否在没有缓存的情况下使用经过微调的数据库(假设在 RAM 中运行，或完全缓冲在其中)- 在这种情况下是否可行(渲染/序列化时间并不重要，因为我几乎将其直接传递给客户端)？
我寻求与平台/缓存层无关的一般策略建议。
最佳答案
下面的设计可能是更好的实现方式。
查询处理器层: 通常，这将是一个 REST API，它接受查询并返回帖子提要(按日期或帖子计数等分页)。这将搜索帖子存储(数据库、索引存储，如 solr 等)并仅获取帖子 ID 列表[注意:不要加载所有帖子，只加载它们的 ID。
帖子服务层 查询处理器层将使用此服务层获取所有给定 ID 的帖子。首先，它联系缓存服务层 请求带有 ID 的帖子。如果找不到它们，那么获取它将从存储中加载帖子并将其返回给查询处理器。此外，它将加载的帖子发送到缓存服务层以缓存它以备将来使用。
缓存服务层 给定一个帖子 ID，只有当帖子存在于缓存中时，它才会返回该帖子。
现在，帖子的缓存键将帮助您加快帖子检索时间。
EG: Redis 为您提供键的模式匹配。因此，使用格式为 postId:date:userId:tag1,tag2 的键，您可以非常轻松地使用标签或 userId 等发布一个帖子或获取日期范围内的所有帖子。
关于database - 个性化提要的缓存策略，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/41532940/