无限滚动页面的Redis分页策略

Question

TL；DR：下面三个选项中，哪一个是使用Redis分页最有效的？

我正在实现一个网站，其中包含多个用户生成的帖子，这些帖子保存在关系数据库中，然后以散列的形式复制到Redis，其中包含像站点：{site_id}： post：{post_id}这样的键。

我想对Redis执行简单的分页查询，以便在Pinterest风格的界面中实现延迟加载分页（即用户向下滚动，我们向服务器发送一个Ajax请求，请求下一批帖子）。

然后，我创建了一个Set来跟踪已发布的帖子id，其中包含像site：{site_id}： post这样的键。我选择了Sets，因为我不想在集合中有重复的ID，并且我可以在每次数据库更新中使用简单的SADD（不需要检查id是否存在）快速完成。

嗯，因为集合不是有序的，我正在计算我必须分页的选项的优缺点：

1） 使用SSCAN命令对已实现的集合进行分页

在这种情况下，我可以将返回的扫描游标保留在用户会话中，然后在下一个请求时将其发送回服务器（多个用户访问和更新数据库时，它似乎不可靠：有时游标将无效并返回奇怪的结果，除非有一些我遗漏的警告）。

2） 重构我的集合以使用列表或排序集

然后我可以使用LRANGE或ZRANGE分页。对于我的用例来说，列表似乎是最有效、最自然的选择。它非常适合分页和按日期排序，但我无法在不循环所有列表的情况下检查单个项目是否存在。排序集似乎结合了集合和列表的优点，但会消耗更多的服务器资源。

3）继续使用常规集，并将页码存储为键的一部分

它类似于site:{site\u id}:{page\u number}:posts。在执行扫描命令之前，这是推荐的方法。

因此，问题是：哪种方法最有效/最简单？是否有其他未列出的推荐选项？

Answer 1

“最佳”是最佳服务：）

我建议您使用第二种方法，但一定要使用排序集而不是列表。这种类型的作业不仅有意义（请参见ZRANGE），而且与LRANGE-ing列表相比，它们的复杂性更高。