Database 个性化提要的缓存策略

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

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

提要数据是一种实体（posts）。这个提要是无限滚动的（分页的），这增加了额外的复杂性

如果用户之间的提要是相同的，那么缓存就很简单了，但是对于个性化提要，我想不出最好的方式是什么

每个“页面”都由日期范围（特定日期）进行偏移

我能想到的方法之一是：

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

个性化帖子提要项将单独缓存。然后，我根据标准保留帖子id的数组，例如创作用户，或分配给它的标签（用户#1:[10,15,23,64…]，标签#FOO:[1,2,5,10…]），并根据日期范围（根据它们适合的分页部分）对它们进行分隔，然后通过Redis或Memcahed的ID通过

mget

/

getMulti

获取这些帖子，并返回组合结果

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

---

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

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

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

发布服务层 查询处理器层将使用此服务层获取给定ID的所有帖子。首先，它与缓存服务层联系，请求使用ID的帖子。如果找不到，则get将从存储器中加载帖子并将其返回查询处理器。此外，它还将将加载的帖子发送到缓存服务层以缓存以备将来使用

缓存服务层 给定一个post ID，它将仅在post存在于缓存中时返回该post

现在，文章的缓存键将帮助您加快文章检索时间

---

例如：Redis为您提供了键的模式匹配。因此，使用格式为postId:date:userId:tag1、tag2的键，您可以很容易地发布一篇文章或获取日期范围内的所有文章，使用标记或userId等。

您所描述的内容基本上类似于Facebook可伸缩性挑战，这是一个注释。基本上，它是通过提前创建个性化提要并将其放入memcached，解决了这个问题

要进行更多优化，您可以记录用户读取提要的频率，并调整缓存对象的生存期，以缩短重用户的使用时间

类似地，您需要较少地刷新那些由很少更新的源提要组成的个性化提要。

---

最后，据我所知，Facebook并没有完全解决由超过5000个来源组成的订阅源的问题，这可能就是为什么他们先设置5000个好友的限制，然后在创建个性化订阅源时选择忽略不太亲密的好友的更新。因此，如果你有能力丢失一些条目，最后一步就是忽略ng一些来源。

使用redis/memcache的优化键空间看起来是一个可行的设计。您将如何准备posts提要？是在每次请求时准备，还是在每次请求前准备？它将在每次请求时准备，因为它将是高度动态的。嗨，您能否提前扩展第二行的

部分