1. 前言Redis分页这个需求比想象中要绕先说说我为什么想写这个话题。上周在群里看到一个新人提问Redis怎么实现分页查询底下一堆回答有人直接说用LRANGE有人说用ZSET还有人说别用Redis做分页。说实话这三种答案都对但又不完全对。因为Redis的分页查询本质上不是怎么查的问题而是你的数据模型适不适合这么查的问题。我早年接手过一个社交信息流项目用户动态列表要支持分页当时MySQL扛不住读写压力就把热数据全部怼进了Redis。结果第一版用List的LRANGE实现分页上线后各种诡异问题数据顺序对不上、翻页翻出重复数据、量大之后延迟飙升。那次踩坑让我花了整整两周重构也把Redis分页这事的边边角角摸了个遍。这篇文章就围绕Redis分页查询这一主题把方案选型、核心命令的细节、常见坑和排查思路一次性讲透。适合正在做缓存分页的Java/Python后端开发也适合刚入门Redis、被分页这个概念绕晕的初学者。放心我会用踩过坑的人的口吻来讲不整那些官方文档里抄来的漂亮话。2. 先想清楚你的场景到底需要什么样的分页2.1 分页查询的本质拆解分页这件事核心就三个维度范围要哪一段、排序按什么排、总量一共多少条。你在MySQL里写LIMIT 10 OFFSET 20数据库默默帮你做了这三件事。但Redis没有这样的SQL引擎它的每一个数据结构都只擅长解决其中某一两个维度的问题。List擅长范围因为它底层是双向链表按下标切一段出来非常快。ZSET擅长范围排序因为跳表结构天然维护了分数顺序。Set能去重但它连顺序都不保证除非你用SSCAN配合游标但它本质上只是遍历不是分页。Hash更别说了压根不适合做列表型分页。所以选方案的第一步不是打开Redis命令手册而是先回答三个问题数据是追加写入还是随机更新排序条件是写入顺序还是某个业务分数如时间戳、热度单Key的数据量级是多少几百条还是几十万条我见过最典型的错误就是用List去存储需要按分数排序的数据然后为了分页先把整个List读出来再在应用层排序。这属于把Redis当成MySQL用数据量一上来Redis的IO就会被打爆。2.2 四种主流方案的一页速览先把方案摆出来后面逐一展开方案适用场景排序依据核心命令最大坑点List LRANGE追加型数据流、简单评论列表插入顺序LRANGE / LLEN深分页性能差、顺序易混ZSET ZRANGEBYSCORE排行榜、按时间分页分数可自定义ZRANGEBYSCORE / ZCARD分数相同需处理并列问题SCAN游标大key遍历、模糊匹配分页无确定性顺序SCAN / HSCAN / SSCAN不保证分页一致性、有重复组合缓存ID列表批量查业务复杂、数据量大的通用方案由业务决定多个命令配合缓存一致性维护成本高这四种方案不是互斥的。我实际项目里最常用的是第四种Redis存ID列表做分页拿到ID后再去数据库批量查详情。这等于把Redis当成索引层分页的压力给缓存查询的压力给KV存储各干各的活。2.3 为什么Redis做分页经常被误解很多人以为Redis分页就是把要分页的数据全放在一个Redis Key里然后用命令切段。这个理解方向对但忽略了一个关键问题Redis的Key存储的是数据本身不是数据的视图。你存一个List它代表的就是这个列表当前状态。如果中间有元素被删除了后面所有元素的下标都会前移之前算好的页码就全乱了。举例来说List里有100条数据第1页取第0~9条第2页取第10~19条。如果此时有人删了第5条那么第2页实际会变成原来的第11~20条用户会看到一条原本在第3页的数据同时第2页尾部漏掉一条。这种问题在MySQL的LIMIT Offset模型下同样存在但Redis场景下因为数据变动频繁问题更明显。后面我会专门讲怎么缓解。3. List方案新手最容易上手也最容易踩坑3.1 LRANGE的完整语义与页码换算Redis的LRANGE key start stop返回从start到stop包含stop之间的元素。这个stop是闭区间是新人最容易踩的坑。比如你要每页10条第一页应该是LRANGE key 0 9不是LRANGE key 0 10。一旦写成0到10你会拿回来11条数据而且后续所有页码都会错位。页码和start/stop的换算公式start (page - 1) * pageSize stop page * pageSize - 1注意page从1开始算。如果你用的是Java的List.subList那种左闭右开的思维会在Redis这里栽跟头。我自己早期写过一个工具类就是因为记错了闭区间上线后翻页总是多一条。还有一点LRANGE的start支持负数-1代表最后一个元素-2代表倒数第二个。这在某些场景下很有用比如只取最近10条可以直接LRANGE key -10 -1不用先算长度。但分页场景建议统一用正数避免混用导致计算混乱。3.2 LLEN做总量控制分页展示通常需要返回总条数。List场景下直接用LLEN key即可时间复杂度O(1)非常快。但这里有个业务判断要提前想好总数是实时精确值还是展示时的近似值在并发写入场景下LLEN返回的是命令执行时刻的列表长度。你在数据库里总数100条Redis里可能已经加到105条了因为用户在不停发动态。如果你要求展示的总数必须严格等于数据库里的真实行数那Redis分页方案本身就不合适应该改走数据库COUNT查询或缓存计数器的方案。如果只是想给用户一个量级参考LLEN完全没有问题。3.3 深分页是List方案的死穴List的LRANGE灵活性很高但代价是深分页场景下的性能灾难。LRANGE key 100000 100009看起来只是取10条实际上Redis需要从链表头部开始跳过前面的十万个节点才能到达目标位置时间复杂度O(n)。实测下来List长度在5000以内时随便翻页基本无感。到了5万翻到第100页时单次延迟开始上到几十毫秒。到了20万以上翻到很深的页码时我在压测环境里见到过200毫秒以上的耗时。这个延迟对于列表页来说是致命的用户点下一页要等200毫秒体感就是卡。所以List方案我给的实践准则是如果预估单个列表Key的规模会超过1万条且用户可能翻到很深的页码就不要用List做分页了。要么改用ZSET分数定位要么用上一页游标的翻页方式替代页码跳转。上一页游标的思路在社交/信息流场景很常见不提供页码跳转只给加载更多。客户端传入上一次最后一条的ID或分数服务端从那个位置继续取。这样查询深度永远控制在O(logN)以内性能稳定很多。3.4 一个典型的评论列表场景示例说个最简单的例子文章评论列表。写入时用LPUSH comments:{articleId} commentId新评论在头部。分页查询第一页用LRANGE comments:{articleId} 0 9第二页用LRANGE comments:{articleId} 10 19。总评论数用LLEN comments:{articleId}。听起来挺顺的但这里有个体验问题LPUSH是往头部插入这意味着LRANGE 0 9返回的是最新9条而MySQL里ORDER BY id DESC LIMIT 0,9也是最新9条两者表现一致。但如果你用RPUSH往尾部插入LRANGE 0 9返回的是最旧的9条。数据插入方式和查询方向不对齐就很容易出现第一页显示的是最老的数据这种低级错误。给个建议无论用LPUSH还是RPUSH分页查询前先在Redis里模拟一遍插入顺序确认LRANGE返回的第一页确实是你想让用户看到的顺序再写业务代码。4. ZSET方案排序和分页的平衡点4.1 为什么排行榜场景几乎都用ZSETZSET底层是跳表哈希表每个成员有一个double类型的分数。它天然维护了按分数从低到高的顺序所以按分数范围分页非常高效。排行榜就是最经典的场景ZREVRANGE leaderboard 0 9 WITHSCORES取前10名ZREVRANGE leaderboard 10 19 WITHSCORES取第11到20名。这里的ZREVRANGE是从高到低对应排行榜的降序需求。如果是升序场景比如按时间从旧到新翻就用ZRANGE。ZREVRANGE和ZRANGE的start/stop语义完全一致闭区间换算公式和List一样。4.2 用时间戳做分数实现时间分页除了排行榜ZSET还常用于按时间分页。把业务数据的ID作为member把写入时刻的时间戳作为score比如ZADD user_posts:{userId} 1699999999999 postId_10086。这样天然形成了一个按时间排序的列表分页时ZREVRANGE user_posts:{userId} 0 9 -- 第一页最新10条 ZREVRANGE user_posts:{userId} 10 19 -- 第二页 ZCARD user_posts:{userId} -- 总数注意时间戳要统一用毫秒秒级时间戳在同秒内多条数据时分数会相同并列问题会让排序不稳定。如果用了毫秒还有并列极端情况可以在member设计上做文章比如member直接存时间戳_业务ID或者用sadd的成员名兜底总之要保证排序结果能区分先后。4.3 ZRANGEBYSCORE与LIMIT做分数段分页ZRANGEBYSCORE key min max LIMIT offset count是另一个非常有用的命令。它允许你按分数范围切分而且支持LIMIT。这个命令比ZRANGE灵活的地方在于你可以从任意分数起点开始取数据不需要每次都先偏移固定页码。比如时间分页场景客户端传了上次最后一条的时间戳1680000000000服务端直接用ZRANGEBYSCORE user_posts:{userId} 0 1680000000000 LIMIT 0 10取更早的10条。这其实就是游标分页在ZSET上的落地。它的好处是不管用户翻了多少页查询效率始终是O(logNM)不会像List的深度偏移那样越来越慢。分数段的min和max还支持-inf和inf对应不限制下界/上界用于第一个查询很方便。另外还有一个ZREVRANGEBYSCORE方向相反用的是max和min的顺序要注意别写反。注意ZRANGEBYSCORE的LIMIT是offset和count但offset在分数范围很大时仍然需要跳过offset个元素所以也不是完全没有深度分页问题。游标式分页才是根本解法。4.4 ZSET分页的并列分数处理这是ZSET分页最容易被忽视的细节。假如一个排行榜中多个用户分数相同按分数排序时Redis还会按member字典序作为次级排序。这个次级排序是Redis内部行为但对业务来说往往没有意义就会导致一个问题两次查询同一页返回的成员顺序可能不一致如果member的字典序和业务期望的顺序不一致。处理方式通常有两种在分数上做文章把原始分数乘以一个系数再加上一个基于时间的小数部分比如score 原始分数 * 1000000 (MAX_TIMESTAMP - 当前时间戳)这样并列分数也被时间戳区分开了。在member上做文章member设计成用户ID_时间戳利用字典序辅助排序前提是业务能接受这种排序逻辑。我建议在设计ZSET分页时一定要在分数里预留去并列的空间不然后续做分页会对不上。这个经验是我在做赛事排行榜时学到的当时一堆人同分翻了第2页发现和第1页尾部重复排查了半天才发现是并列导致的。5. SCAN游标当你需要遍历型分页5.1 SCAN和分页的区别与联系严格来说SCAN以及HSCAN、SSCAN、ZSCAN不是分页命令它返回的是一个游标每次调用返回一批元素和下一次调用所需的游标值。但它经常被用来实现分页遍历的效果尤其在单Key存储了大量数据且无法用ZSET排序的场景下。它的API长这样SCAN cursor [MATCH pattern] [COUNT count] [TYPE type]cursor是游标第一次传0后续传上一次返回的cursor直到返回0表示遍历结束。COUNT不是精确的返回条数更像是每批的工作量提示实际返回的数可能多可能少。MATCH是在遍历过程中做的模式匹配注意它不是先筛选再返回而是返回后再过滤所以MATCH下的返回条数更不可控。我举一个实际场景运营后台需要按某个前缀遍历所有用户缓存Key比如user:info:*然后在页面上以每页20条展示。用KEYS user:info:*确实可以直接拿到所有Key但KEYS命令是O(N)的且会阻塞Redis主进程线上谁敢用SCAN就是替代KEYS的正解它按游标分段返回每次只扫一小部分哈希槽不会长时间阻塞Redis。5.2 SCAN分页的三个固有特性用SCAN做分页必须接受它的三个不讲道理不保证顺序。SCAN的遍历顺序是基于哈希表的桶位不是数据插入顺序。所以你不能依赖它做按时间从新到旧的分页。同一个元素可能被返回多次。在遍历过程中如果有元素发生rehash或者你修改了集合内容同一个Key可能会在两次迭代中重复出现。业务层需要做去重。不保证分页快照的一致性。SCAN反映的是遍历过程中的最终一致性视图不是某一时刻的数据库快照。遍历中途插入的新元素可能在本次遍历中被扫到也可能扫不到。这三个特性决定了SCAN只适合两类场景一是后台管理类的低频遍历二是全量数据导出的分批处理。绝对不适合作为C端用户列表的分页方案。5.3 游标状态下拉加载的工程实现虽然SCAN不适合做常规分页但游标这个思路值得借鉴。很多信息流场景其实就是下拉加载更多本质就是游标分页。工程上的做法是客户端请求时带上参数lastId上一次最后一条数据的ID或score。服务端根据lastId定位数据List场景没有天然定位能力ZSET用ZRANGEBYSCORE定位关系型数据库用WHERE id lastId。每次固定取N条返回数据时同时返回新的lastId给客户端。这种模式规避了页码偏移的问题无论翻多深性能都稳定。Redis里的体现就是ZSET配合ZRANGEBYSCORE或者直接用List但每次通过LINDEX先定位到lastId对应位置再LRANGE取后续。我自己在实际项目中最常用的组合是MySQL存储全部数据Redis ZSET存储数据的ID列表score为时间戳分页时先在Redis查ID再回MySQL查详情。这样MySQL只承接点查压力列表页的压力几乎全被Redis扛住了数据库的慢查询直接少了一个数量级。6. 组合方案实战缓存ID列表 批量回源6.1 为什么这是最稳的分页架构上面说了那么多基于单一结构的方案但真正能在生产环境长期稳定跑的分页架构往往是组合式。核心思路一句话Redis负责索引与分页数据库或后端服务负责详情数据。具体来说数据写入 1. 业务数据落库拿到自增ID 2. ZADD feed_list:{userId} 时间戳 postId 3. (可选) 设置ZSET的过期时间控制列表长度 数据查询分页 1. ZREVRANGE feed_list:{userId} (page-1)*size page*size-1 -- 获取一页ID 2. ZCARD feed_list:{userId} -- 获取总数 3. MGET post:{postId} 或 pipeline查数据库 -- 批量查详情这样做的好处非常明显ZSET只存ID成员体积小内存可控单Key能轻松撑住几十万条数据。分页命令只操作ID列表不会把大对象传到网络上。详情数据走缓存或数据库点查天然支持冷热分离。列表清洗删除、过滤只需要删ZSET里的member和缓存Key数据库不动。6.2 示例Java RedisTemplate实现过程用Spring Boot RedisTemplate举个实际例子。假设Feed流场景用户发布动态动态ID由数据库自增现在需要按时间分页显示用户自己的动态列表。以下是核心代码的核心思路不贴完整类只说关键操作。写入侧// 假设postId已经由数据库生成 String feedKey feed:user: userId; long score System.currentTimeMillis(); // 毫秒时间戳 redisTemplate.opsForZSet().add(feedKey, postId, score); // 控制最大长度只保留最近5000条 redisTemplate.opsForZSet().removeRangeByScore(feedKey, 0, score - 30 * 24 * 3600 * 1000);查询侧public PageResultPost pageFeeds(Long userId, int page, int size) { String feedKey feed:user: userId; int start (page - 1) * size; int end page * size - 1; // 1. 查ID列表 SetObject postIds redisTemplate.opsForZSet() .reverseRange(feedKey, start, end); // 2. 拿总数 Long total redisTemplate.opsForZSet().zCard(feedKey); // 3. 批量回源查详情 ListPost posts postService.listByIds(postIds); return new PageResult(posts, total); }这段代码有几个值得注意的细节reverseRange返回的是从高到低即最新动态在前符合Feed流习惯。removeRangeByScore是清理过期数据的办法按分数范围删除避免ZSET无限膨胀。listByIds建议用批量SQL或pipeline千万别在循环里逐条查数据库。6.3 缓存一致性分页缓存最头疼的一环缓存ID列表的架构有个绕不开的问题数据流里的删除和更新怎么同步到Redis的ZSET里。真实业务里用户删除一条动态数据库里删了但Redis ZSET里的member还在分页就会把已删除的ID查出来。这时候有两种处理思路删除时同步删Redis业务代码里执行ZREM feedKey postId。简单直接但要求所有删除操作都走统一代码入口漏一处就会出现脏数据。查询时过滤拿到ID列表后在批量回源时把库里不存在的ID过滤掉。这样即使Redis里有残留member也不会展示给用户。这个做法更稳但每次查询多一次数据库判断代价可接受。我自己的实践是两者结合删除时主动删ZSET查询时也做过滤兜底。这样既能保证即时性又能兜住漏删的脏数据。如果你嫌麻烦纯查询时过滤也够了顶多Redis里留存一些无用ID占用点内存而已。7. 常见问题与排查实录7.1 问题速查表把我在实际项目中遇到的分页相关问题整理成一个速查表方便你遇到类似问题时直接对照症状可能原因排查命令 / 手段分页数据有重复ZSET分数相同次级排序不稳定ZRANGE key 0 -1 WITHSCORES检查分数修改分数设计去并列翻页后数据少了一页LRANGE的stop写成了开区间导致数据错位检查start/stop计算记住stop包含深分页越来越慢List方案深度偏移O(n)换成ZSET或游标式翻页列表总数和数据库不准并发写入导致Redis和库数据不一致接受近似值或改用计数器/COUNT查询Redis时阻塞严重误用KEYS或对大Key执行了复杂命令改为SCAN检查SLOWLOG页面偶尔显示已删除数据删除时没同步清理缓存全局删除切面 查询时过滤兜底内存增长过快ZSET未清理过期memberZREMRANGEBYSCORE定期清理或写入时限制7.2 大Key分页引发的阻塞事故有个项目我印象很深运营活动的用户列表直接存了一个List每天几百万条记录运营后台还要分页导出。某天线上报警Redis主线程阻塞了数秒排查下来就是有人对那个大List执行了LRANGE 0 -1一次性要把全量数据读出来直接把Redis IO打满。这个事故给我们的教训是生产环境禁止直接LRANGE 0 -1数据量大的Key必须分批取。大Key要监控用DEBUG OBJECT key或MEMORY USAGE key看序列化长度超过阈值就要拆分或改造。运营后台的分页导出建议用SCAN或分批ZRANGE每批1000条配合sleep让Redis喘口气。7.3 Redis Desktop Manager这类可视化工具里怎么看分页顺便说一句很多人喜欢用Redis Desktop ManagerRDM之类可视化客户端看数据。这类工具对开发调试确实方便但要注意RDM的加载全部按钮本质上是LRANGE 0 -1或类似的全量读取。如果你在生产环境连上了Redis又用RDM打开了一个大KeyRedis一样会被阻塞该挂还是挂。工具无罪但用工具的人要有点敬畏。可视化管理软件更适合做小数据量的键值检查、TTL查看、慢日志查询这些轻量操作。线上大Key的遍历请老老实实写脚本用SCAN去做。7.4 深分页优化思路一次参数级的调优记录之前在某个搜索联想词项目里单个ZSET从几千涨到了几十万。分页接口的P99延迟从8ms一路飙到150ms。定位后发现两处瓶颈一是在应用层我们通过ZREVRANGE取到了ID后又对ID做了逐条缓存查询这个循环在数据量大时拉高了耗用二是ZCARD和ZREVRANGE虽然是O(logNM)但M太大时网络传输耗时也不低。优化动作是这样的把逐条查缓存改成pipeline批量获取网络往返从N次降为1次。针对超过第100页的请求强制走游标式翻页不再允许深偏移。对ZSET做了定期裁剪只保留最近2万条热数据更早的数据让用户从数据库检索。优化完后P99回到20ms左右。这几次调优的核心原则是能用O(logN)解决的就别用O(N)能批量取的就别单条取该放弃深分页的就要果断放弃。8. 写在最后的一些个人体会回头看看这一路走过来的项目我觉得Redis分页查询最大的陷阱不是命令不会用而是没想清楚数据模型和访问模式就开始写代码。很多团队上来就Redis做缓存分页直接LRANGE看起来简单等数据量一大、需求一复杂全得返工。我现在的习惯是接到分页需求先画一个请求路径的草图数据从哪里来、写到哪里去、用户怎么翻页、总量怎么统计、删了怎么办。把这个草图理清楚Redis的命令反而成了最不值一提的部分。如果这篇文章能给你留一个可落地的印象我希望是List适合小规模追加型分页ZSET适合需要排序的分页SCAN只做后台遍历组合方案才是生产级的答案。后面如果你在实际项目里踩到别的坑欢迎顺着这个套路继续排查——先看数据模型再看命令复杂度最后看缓存一致性。数据模型对了分页其实也就没那么难了。