Redis里分页查询怎么搞，优化思路和实现细节聊聊

关于Redis中的分页查询,核心思路是利用其有序的数据结构，最常用的方法是使用有序集合（ZSET）和列表（LIST），但它们的适用场景和优化方式不同。

基础实现方法

• 使用有序集合（ZSET）：这是最灵活、最常用的方案，你可以把每个成员的分数（score）设置为发布时间戳、热度值等，用于排序。

  • 实现细节：使用 ZREVRANGE 命令（按分数从大到小）或 ZRANGE（从小到大）进行分页，获取第一页10条数据：ZREVRANGE key 0 9 WITHSCORES，第二页就是 ZREVRANGE key 10 19 WITHSCORES，这相当于传统的 LIMIT offset, count。
  • 适用场景：排行榜、按时间线排序的动态、带权重的列表等需要动态排序和更新的场景。

• 使用列表（LIST）：如果数据顺序是固定的，或者主要进行追加操作，列表很合适。

  • 实现细节：使用 LRANGE 命令进行分页，LRANGE key 0 9 获取前10个元素，它的元素顺序是插入顺序，或者通过 LPUSH/RPUSH 控制。
  • 适用场景：消息流水、操作日志、固定顺序的目录页等，但列表中间元素的插入删除效率较低，不适合需要频繁更新排序的场景。

核心优化思路

基础的分页在数据量小的时候没问题,但一旦数据量巨大（比如几十万、上百万），并且页码很深时，就会暴露出问题，主要优化方向如下：

• 避免使用大偏移量（Offset）：这是最关键的一点，在有序集合或列表中，ZRANGE key 100000 100019 这样的命令，虽然只返回20条数据，但Redis需要先从头开始遍历到第100000个元素，这个过程很慢（时间复杂度O(n)），页码越深，效率越低，可能导致请求超时。

  • 优化方案：使用“游标”或“上次分值”查询，放弃传统的页码概念，改为记录“上一页最后一个元素的分值（score）或ID”，查询下一页时，使用 ZRANGEBYSCORE 命令，上一页最后一条的分数是 last_score，那么查询下一页就是：ZREVRANGEBYSCORE key (last_score -inf LIMIT 0 10，这里的 表示开区间，排除掉已经查过的上一条边界值，这样，无论翻到第几页，查询速度都只和每页大小有关，是稳定的O(log N + M)。（参考自Redis官方文档关于范围查询的建议）

• 缓存热门页数据：对于访问量巨大的首页、前几页，可以直接将分页结果缓存起来，使用 String 类型存储序列化后的第一页JSON数据，设置一个较短的过期时间，这样能极大减轻对主数据结构的压力。

• 分离热冷数据：对于像新闻排行榜这类场景，可以只将热门的数据（如最近3天的）放入Redis ZSET进行排序和分页查询，全量的历史数据可以存入数据库，当需要访问更老的数据时，直接走数据库分页，这是一种空间换时间和性能的思路。

• 注意大Key问题：如果一个ZSET或LIST里元素数量极其庞大（例如千万级），不仅分页慢，还会在集群迁移、持久化时带来问题，需要考虑按时间或其他维度进行拆分，例如按月份创建多个ZSET键。

• 保证数据一致性：在分页过程中，如果数据源本身在频繁增删（比如列表中的元素被删除），可能会导致相邻两页的数据出现重复或丢失，游标（基于分值）的方式相对于基于偏移量的方式，在这种动态场景下更稳定，因为它基于一个确定的分数值进行锚定，但依然无法做到完全的业务强一致，需要根据业务容忍度来权衡。

总结一下： 在Redis中做分页，优先考虑使用有序集合（ZSET），因为它功能强大。务必采用基于分值（游标）的查询来替代大偏移量查询，这是性能优化的关键，结合缓存、数据拆分等辅助手段，才能应对高并发、大数据量的分页场景，用ZSET，别用大Offset，记下最后一条的分数来翻页”。