Redis分页策略的优缺点

时间:2015-08-18 15:37:58

标签: pagination redis language-agnostic lazy-loading

TL; DR:以下三个选项中哪一个对Redis进行分页最有效?

我正在实施一个包含多个用户生成帖子的网站,这些帖子会保存在关系数据库中,然后以Hashes的形式使用site:{site_id}:post:{post_id}等密钥复制到Redis。

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

然后我创建了一个Set来跟踪已发布的帖子ID,其中包含site:{site_id}:posts等关键字。我选择了Sets,因为我不希望在集合中有重复的ID,我可以使用简单的SADD快速完成(不需要检查是否存在id)。

好吧,由于套装没有订购,我正在考虑我必须分页的选项的优缺点:

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

  

在这种情况下,我可以将返回的扫描光标保留在用户的中   会话,然后在下一个请求时将其发送回服务器(似乎不是   多个用户访问和更新数据库时可靠:at   有时光标无效并返回奇怪的结果 -   除非有一些我不知道的警告。

2)重构我的集合以使用ListsSorted Sets代替

  

然后我可以使用LRANGEZRANGE进行分页。列表似乎   是我用例中性能最佳,最自然的选择。它的   完美的分页和按日期排序,但我根本无法检查   对于单个项目存在而不循环所有列表。排序集   似乎加入了集合和列表的优点,但消耗更多   服务器资源。

3)继续使用常规套装并将页码存储为密钥的一部分

  

这就像site:{site_id}:{page_number}:posts。它   是扫描命令实施前的recommended way

所以,问题是:哪一个是最有效/最简单的方法?这里没有列出任何其他推荐的选项吗?

1 个答案:

答案 0 :(得分:8)

"最佳"最好服务主观:)

我建议你采用第二种方法,但绝对使用排序集超过列表。这种类型的工作不仅有意义(参见ZRANGE),与LRANGE - 列表相比,它们在复杂性方面也更有效。