想象一下像Instagram这样的应用程序，它具有无限的提要。该Feed是根据一系列因素（例如，朋友，关注的帐户等）填充的。
接下来，我们假设有一个名为Posts的表格，其中包含所有当前发布在Instagram上的帖子。
还有一个端点GET /user/feed?page=1，该端点返回一个分页的帖子数组，登录的用户在打开应用程序时将在其供稿中看到它们。
最后，在该路线的后端，有一个复杂的算法（X），该算法对数千个帖子进行排名，最终得出用户将看到的100-500个PostId数组。太酷了吧？
由于端点GET /user/feed?page=1已分页：
一种实现它的暴力方式是重新计算相关帖子的数组，然后跳过page * POSTS_PER_PAGE帖子并返回。这是一个丑陋的，可行的解决方案。
另一种方法是在主MySQL数据库前面有一个Redis存储区，该存储区为每个用户缓存大约30分钟的提要（帖子数组）？ （我假设30分钟是假设用户现在正在使用该应用，并且我们应该在滚动时迅速返回结果。一旦他们离开该应用并在之后返回，请说2 hours ，只有重新计算PostIds并重新填充缓存才有意义。如果您认为30 minutes太苛刻，请提出另一个限制。）
第二种方法是否足够好，或者我缺少什么？对于任何反馈，我们都表示感谢。