做技术这么多年一直觉得“分页”这事儿最容易被低估。数据库分页谁都会写LIMIT、OFFSET一套就完事可一旦业务场景切换成feed流这种时间线形态再拿传统那套分页逻辑往上硬套出问题只是时间早晚的事。我之前就被线上的feed流分页翻车狠狠教育过——页数越翻越慢、数据前后颠倒、边翻边漏用户反馈一条接一条。后来把方案的底层换到Redis上才彻底理顺今天就把这一路踩出来的经验完整写出来给正在被同类问题折磨的朋友一个可落地的参考。这套内容主要面向正在做信息流、朋友圈、动态广场、通知列表这类时间线业务的开发同学以及准备把Redis引入缓存层做分页治理的团队。我会把Redis在feed流场景下的数据模型设计、分页命令选型、翻页参数计算、重复与漏数据的排查思路、内存治理手段全部拆开讲透。既有原理也有可以直接拿去改的代码级方案保证你看完能在自己的项目里实操复现。1. 项目背景feed流分页为什么成了烫手山芋1.1 feed流的典型形态与数据组织方式feed流本质上就是按照时间倒序排列的内容列表微博时间线、朋友圈动态、抖音关注页都是这个形态。它的两个核心特征一是数据持续写入只要用户发内容feed就会在后台不断追加二是读取路径极其固定绝大多数请求都发生在“拉取列表”这一件事上。这种读多写少、新数据永远往头部追加的场景恰恰是Redis最擅长的领域。传统MySQL方案是怎么做的呢简单粗暴feed表加索引然后ORDER BY create_time DESC LIMIT offset, size。前几百条数据没问题但翻到几百页之后OFFSET越来越大MySQL要扫描并丢弃大量已经翻过的行查询计划就是先按索引把全表排一遍序再切偏移性能直线下降。我实测在单表三千万行、没有冷热分离的前提下翻到第100页时单次查询已经超过800毫秒这还是在有复合索引的前提下基本上等于不可用。Redis解决feed流的思路完全不一样把feed关系在写入那一刻就组织好读取时直接按数据结构天然的顺序切片返回根本不做全量排序。以ZSet为例score直接设计成毫秒级时间戳成员是feed ID或者动态ID查询时走ZREVRANGE按score从大到小切片。ZSet底层是跳跃表范围查询的时间复杂度是O(log N M)N是集合内数据量M是返回条数。就算一个用户的feed集合里塞了几万条数据取一页二十条也就是几十微秒到几百微秒级别性能比MySQL方案提升了至少两个数量级。这个模型拆开看就是三步用户发内容时把feed ID写入所有相关粉丝的ZSet集合用户刷列表时从自己的ZSet里ZREVRANGE拿一页翻页时记住上一页最后一条的score和member作为下一页的起点继续往下取。整个流程不涉及全表扫描也不涉及传统的偏移量概念。1.2 分页在feed流场景的三个特殊约束传统方案在feed流场景失效不只是性能问题还有三个额外的场景约束。如果只把分页简单替换成Redis命令不考虑这三个约束照样翻车。第一个约束是数据高频变更。feed流是活的每一秒都可能有新内容插入头部。使用MySQL的OFFSET方案时一旦第一页和第二页之间插入了新数据整条列表整体往后挤用户翻到第三页时可能和第二页出现重叠也可能直接跳过几条这在体验上特别明显——用户刷着刷着突然感觉“哎这条我看过了”或者“怎么莫名其妙地断了一截”。第二个约束是时间线要求全局单调。feed流的核心体验就是时间顺序如果两个feed的入库时间相同或者因为主从延迟导致先发的内容反而排在后面用户会直接质疑系统的正确性。所以分页不但要快还要保证顺序稳定。这里的稳定指的是用户翻完第一页再翻第二页时第二页的数据必须严格是第一页的后续不能因为中间有并发写入就出现错乱。第三个约束是数据量持续膨胀。好友多、粉丝多的用户feed ZSet集合很容易膨胀到几万几十万条。内存成本不可回避如果不做容量治理Redis会变成一台只会用内存换时间的奢侈品机器。我之前看过一个社交产品的Redis使用报告feed类存货Key占了整体内存的60%以上而且大部分访问热度集中在最近几百条老数据基本没人看这其实就是巨大的资源浪费。这三个约束叠加起来指向一个结论feed流分页不是简单的“换个存储取数据”而是要把写入序、读取序、容量治理放在一起设计最终落地成一个稳定的时间线模型。2. 核心设计Redis里组织feed关系的数据结构选型2.1 List方案与ZSet方案的本质区别用Redis做feed流社区里讨论最久的就是List和ZSet两种数据类型。List方案典型做法是用户发feed时LPUSH到粉丝的feed队列拉取时LRANGE key 0 19取第一页翻页时继续按start和stop切片。这个方案在粉丝量小、模型简单的时候跑得很欢因为LPUSH和LRANGE都是O(1)级别的操作代码写起来也最省事。但List有一个致命缺陷它压根不按时间排序只按插入顺序排序。只要出现跨实例的并发写入比如用户A的feed同时在两台应用服务器上被写入粉丝队列到达Redis的顺序可能和实际发feed的时间不一致那么LPUSH后的列表顺序就乱了。另外List不支持按score范围查询翻页只能一路LRANGE下去一旦列表中间因为做压缩或者淘汰被裁剪过翻页的连续性就崩了。ZSet方案则把score作为显式的时间因子。写入时ZADD key score member抽取时ZREVRANGE key start stop一切顺序都由score决定和写入顺序完全解耦。这解决了并发乱序的隐患因为score用的时间戳是业务层生成的同一毫秒内也可以引入序列号来保证严格单调。从语义上讲ZSet更贴近“按时间倒序排列”这个建模需求。我的选型结论很明确凡是toB端、重逻辑型的产品比如信息流、关注流、评论时间线一律用ZSet只有那种纯内部、允许插入顺序和真实时间不一致的简单队列场景才考虑List。ZSet每个元素额外耗用约24字节的跳跃表节点开销但换来的是时间语义的准确性这笔帐绝对划算。2.2 ZSet、List、Set三者的能力对比这几种结构经常被我拿来对比因为它们的适用边界在面试和实战里都被反复问到。直接引用我常用的一张对比维度表能力维度ZSet有序集合List列表Set集合按时间排序支持score决定不支持按插入序不支持范围查询ZRANGE/ZREVRANGEO(log NM)LRANGEO(NM)需额外排序翻页游标可用score定位下次起点只能用下标不适用重复成员天然去重重复ZADD只更新score有重复LPUSH不去重去重但无序内存开销约每元素24字节额外节点双向链表节点高比List低并发乱序风险低score可控制高与写序强相关不适用这里要特别强调一下Set。有些同学图省事会把feed ID塞进Set然后用SORT命令按时间排序来模拟ZSet但这本质上是把排序推给查询时做和MySQL全表排序是一个思路数据量大一点SORT就要全量取出再归并性能和ZSet的范围查询完全不是一个级别。所以Set在feed流里最合理的用途是辅助判断“这个feed是否已经处理过”这种幂等场景而不是作为主存储结构。2.3 为什么ZSet是feed流分页的默认答案讲到这里结论已经很明显了。ZSet能在feed流场景里站稳脚跟核心原因是它同时满足了三个条件排序能力、范围查询效率、去重能力。这三个能力恰好对应feed流的三个本质需求时间顺序展示、高性能分页拉取、重复内容的天然抑制。举一个实际案例某社交App的关注页feed流单用户关注上千个作者平均每天产生数百条新feed。上线ZSet方案后Redis单key存储约两万条feed记录ZREVRANGE取一页20条的P99延迟稳定在380微秒而同样数据量的MySQL方案在同样分页查询下P99是450毫秒。这个数量级的差异用户刷信息流的手感差别是“秒开”和“半天转圈”的区别。ZSet也确实有它的问题——所有数据都按score严格排序一旦score设计失误比如全用秒级时间戳导致同一秒内多条数据并列分页时会出现排序不稳定的情况。这个坑我会在第四章详细展开但总的来说只要score细节打磨到位ZSet就是feed流分页最可靠的地基。3. 实操落地ZSet实现feed流分页的完整方案3.1 写入流程score的生成与ZADD的实现细节ZSet写入流程里最容易被忽视的就是score生成。我见过太多代码直接用System.currentTimeMillis()当score表面上看时间精确到毫秒同一个用户在同一毫秒内发两条feed的概率极低。但问题是feed流往往聚合了很多人的动态一个用户A发了feed要写入成百上千个粉丝的ZSet这个写入过程是并发的两个feed的消费顺序可能颠倒就算时间戳不同也可能出现后写入的score更小。所以我在生产环境里对score做了一层设计score 毫秒时间戳 * 100 序号位。序号位占据两位表示同一毫秒内同一用户发feed的先后次序。举个直观例子两条feed的时间戳都是1700000000123第一个序号是01第二个是02那么它们的score分别是170000000012301和170000000012302。这样即使极端情况下同一毫秒内出现并发score依然严格递增。再进一步有些团队会把feed ID直接嵌进score里做最终保底。比如score 时间戳 * 1000000 seq和feedID的某种组合。但我个人不建议把feedID直接做数值嵌入因为得分大于long型上限的风险很高反而得不偿失。我倾向于这种方案score为long型时间戳乘以10000余下的四位用于并发时序控制然后member用feedID字符串。写入命令层面就是标准的ZADDZADD feed:user:123 170000000012301 feed_98765这个命令是O(log N)的插入复杂度但如果批量写入很多粉丝单个用户ZSet可能需要一次性ZADD几百条这时候用pipeline批量提交比循环单个提交效率高不少。我实测在Redis单机上pipeline一次性提交500条ZADD整体耗时从循环提交的1200毫秒降低到80毫秒提升超过一个数量级。代码示意Jedis jedis new Jedis(redis-host); Pipeline pipeline jedis.pipelined(); for (String followerId : followerList) { pipeline.zadd(feed:user: followerId, score, feedId); } pipeline.sync();3.2 首次加载ZREVRANGE取第一页的正确姿势第一页的拉取是feed流体验的开门之战。这里最核心的一点是明确用ZREVRANGE而不是ZRANGE。因为feed流是时间倒序最新数据应该排在最前面。ZRANGE是从score最小到最大取数据用于正序场景ZREVRANGE则反过来从最大到最小取出正好匹配feed流的时间倒序。第一页的命令长这样ZREVRANGE feed:user:123 0 19 WITHSCORES返回的20条记录就是用户时间线上最新的20条feed。这里我强烈建议带上WITHSCORES因为后面翻页要用到score作为游标第一页返回的最后一个score就是第二页的起点。虽然理论上可以二次查score但多一次round trip在延迟上不划算直接一次取回最稳妥。还有一个细节值得注意ZREVRANGE返回的成员顺序是严格由score降序排列的如果你的score里已经嵌入了序号位那么即使同一毫秒的两条feed顺序也是确定性的。这一点对用户体感至关重要——两个几乎同时发的动态无论刷新多少次排名都应该稳定不变。第一页拉取后正常的API层处理是把返回的member列表翻译成feed的业务数据比如查MySQL、查缓存再把最后一项的score和member作为nextCursor传给客户端。流程到这一步第一页就已经稳了。3.3 翻页游标用MAX(MIN) SCORE替代OFFSETfeed流翻页最核心的设计就是用上一页最后一项的score作为下一页的边界游标而不是用OFFSET。这个设计在Redis里落地成两条命令ZREVRANGEBYSCORE和ZREVRANGE。上一页结束后记录lastScore下一页用ZREVRANGEBYSCORE feed:user:123 (123456789012300 -inf LIMIT 0 20这里的“(”是Redis专用的开区间语法表示严格小于该score避免重复取到上一页最后一条。同时LIMIT 0 20限制只取20条。这条命令的含义是取所有score严格小于lastScore的记录按score降序排列后从第一条开始取20条。用术语讲这是基于游标的keyset分页和数据库里用WHERE create_time ? ORDER BY create_time DESC LIMIT 20的思路完全一致只是Redis把排序和切片都内化到了数据结构里性能翻倍。这个设计避开了OFFSET分页的经典问题翻页期间有新feed写入时因为每页的起点是确定的score而不是一个相对偏移量所以新feed完全不会影响已经翻过的页也不会导致数据遗漏或重复。更直白点说当用户从第1页翻到第2页即使第1页到第2页之间插入了50条新feed第2页依然是严格接续第1页的最后一条新feed只会出现在下次从第一页重新拉取时。这对无限滚动类的feed流是必不可少的方案。我在代码里实现得比较严谨会把游标分成score和member两个维度public PageResultFeedVO queryFeedNext(String userId, double lastScore, String lastFeedId, int size) { String key feedKey(userId); // 开区间排除上一页最后一条 SetTuple tuples redis.zrevrangeByScoreWithScores(key, Double.NEGATIVE_INFINITY, lastScore, 0, size); // 特殊处理当score相同时用member做二次比较 ListFeedVO list convertAndFilter(tuples, lastScore, lastFeedId); ... }这里之所以引入lastFeedId是因为score存在并列的可能。虽然前面设计里score是时间戳加序号但总可能出现不同业务线的feed用了同一个score的情况。一旦两条score相同下一轮查询ZREVRANGEBYSCORE的开区间会同时把两条都排除掉导致userId场景下丢数据。为了彻底防住这个问题我做了二次过滤如果返回的第一条member等于lastFeedId就把这条继续丢弃确保游标语义严谨。4. 深坑实录分页中的重复、乱序与漏数据排查4.1 翻页重复数据score并列与游标左闭右开开头提到的翻车问题最典型的表现就是翻页出现重复数据。用户刷到第二页发现有一条在第一页已经看过了这种体验极其掉价。根源往往就是游标的边界没有处理好。具体拆解如果你用的是ZRANGEBYSCORE取第二页命令是ZREVRANGEBYSCORE feed:user:123 (lastScore -inf LIMIT 0 20这里把lastScore用开区间语法排除了理论上不会重复。但如果代码里图省事写成了ZREVRANGEBYSCORE feed:user:123 lastScore -inf LIMIT 1 20这就埋了一颗雷。LIMIT 1相当于跳过了第一条也就是跳过了score等于lastScore的那条记录。问题在于如果lastScore这一档本身就有多条并列记录比如时间戳相同但member不同这里跳过第一条后剩下的记录中又包含了上一次分页已经翻过的那条member导致重复。这个bug我在压测里复现过好几回。代码里写LIMIT 1的初衷是“跳过上一页最后一条”但正确做法应该用开区间“(lastScore”从源头排除那条记录LIMIT永远从0开始只是在游标比较做文章而不是用偏移量去跳。简单总结成一句话游标要“左闭右开”用开区间后LIMIT必须从0开始绝不能用OFFSET语义去跳过重复项。另外如果score并列情况很多我建议进一步把游标升级成score member。在代码里实现时第一层用zrevrangeByScoreWithScores拿数据然后在业务层把member等于lastFeedId且score小于等于lastScore的记录过滤掉。这样即使并列多条也不会漏也不会重。4.2 跨页漏数据并发写入与分页期间的新增漏数据和重复数据是双胞胎。漏数据最典型的场景发生在OFFSET分页身上用户第一页取走了第0-19条此时有新feed插入到了第一个位置整个列表往后顶用户翻第二页时OFFSET20指向的是原第19条也就是第一页最后一条重复了又或者OFFSET20指向了别的位置某条数据被隔过去漏了。ZSet游标方案按理说不会出现这种问题因为第二页的起点是严格按score界定的无论中间插入多少新数据都不影响起点之后的排列。但我在实际项目里还是遇到了一种特殊漏法多个feed写入的score不是单调递增的。比如应用服务器A和B同时写ZSetA写的score是170000000010001B写的score是170000000009999。由于网络时序B的后写入却带着更小的score。这时候按score翻页小score的数据会被排到更后面虽然不会“漏”但用户会看到时间顺序颠倒的错乱感严重时甚至感觉某条动态“消失”了。根治方法有两个我生产环境都上了一是写入前统一用Redis自身的INCR或时间服务生成单调递增的序号确保全局时间因子单调二是就算score暂时回退也保证member唯一且按业务时间二次排序。这样即便极端情况下score并列或轻微回退翻页仍能通过member的比较兜住顺序。4.3 Redis遍历大Key的阻塞隐患与scan的正确用法feed流分页还有一个隐雷就是ZSet数据量到了一定规模后直接用KEYS pattern或者SORT类命令做全量操作会阻塞Redis。Redis是单线程一个慢命令会拖累整个实例。我之前在一个活动页面上踩过用户动态列表Key涨到五十万条有人为了做实时搜索用了KEYS feed:*直接扫全库瞬间Redis阻塞了5秒线上接口全部超时报警。针对这种场景的正确姿势是SCAN命令配合游标迭代。SCAN本身不是给分页用的它适合做后台任务、统计、清理等不追求实时顺序的操作。比如要批量清理超过30天的feed数据直接循环执行ZREMRANGEBYRANK可能也要注意阻塞更稳健的是用SCAN游标迭代每一个feed key再对单个key做范围删除操作。代码示意SCAN 0 MATCH feed:* COUNT 100这里COUNT不要设太大一般100上下就够了太大的COUNT会在一次迭代里处理过多key增加阻塞风险。我在生产环境固定用COUNT 100单次SCAN命令耗时稳定在1毫秒级别。这里特别提醒一点SCAN拿到的结果是不保证顺序的也不能在分页过程中依赖它做精确切片。SCAN的正确使用场景是遍历全量key做统计和淘汰分页还是要走ZREVRANGE或ZREVRANGEBYSCORE两边职责完全不同千万别混用。我还遇到过一种更隐蔽的坑ZSet本身就是一个大Key几十万条数据全部存到一个key上。即便用ZRANGE单次查询虽然快但这个key本身的写入、删除、拷贝操作都会成为慢命令。比如高峰期频繁ZADD这个keyRedis fork和内存碎片问题就会被放大。我建议对大V用户的feed单独做key拆分比如按时间分桶feed:user:123:202501 到 feed:user:123:202512这样每个桶的数据量可控删除过期数据也更快。4.4 Redis阻塞与内存穿透问题排查实录最后这一类问题虽然不是分页本身导致的但分页接口一旦曝出超时排查方向十有八九离不开Redis的阻塞和穿透。我第一次排查线上feed流分页超时时第一反应是分页命令不够快反复优化Redis命令都没用后来发现根源是同一台Redis实例上有另一个业务在跑一个MGET了十万个key的脚本直接把实例拖垮了。排查工具我用得最多的是Redis自带的SLOWLOG、MONITOR和INFO stats。SLOWLOG能精确记录执行时间超过阈值的慢命令SLOWLOG GET 50看到慢命令后重点检查是否来自feed分页的key。另外INFO命令的blocked_clients字段是个重要信号如果大于0说明有客户端正在被阻塞等待很可能遇到了BZPOPMIN、BRPOP这类阻塞操作这种操作如果配合超长超时值会长期占住连接导致分页请求得不到响应。内存穿透这块也要防。feed流接口一般先查Redis再查MySQL如果Redis里某个ZSet被误删或者过期所有请求瞬间全部穿透到数据库数据库连接池直接被打满。我处理这种问题的标准做法是给分页接口加一层本地缓存兜底同时用Redis的exists命令做前置检查一旦发现key丢失立刻走DB回源并重建ZSet缓存回源操作加分布式锁避免并发重建。锁的Redis命令典型就是SET NX EXSET lock:rebuild:feed:user:123 1 EX 10 NX拿到锁的线程负责重建其他线程短暂等待或者直接降级返回空列表避免雪崩。5. 进阶治理容量、冷热分离与未来扩展5.1 内存成本治理与feed数据瘦身ZSet方案跑一段时间后最现实的挑战是内存。一个百万级用户的社交产品人均ZSet两百条feed按每条feedID加score约40字节计算单用户key内存约8KB一百万人就是800GB纯内存显然扛不住。所以feed流上Redis的关键从来不是“存多少”而是“存多久、存哪些”。第一种治理手段是限制长度。ZADD之后用ZREMRANGEBYRANK清理超出容量的老数据。比如限制每个用户ZSet最多保留1000条ZREMRANGEBYRANK feed:user:123 0 -1001这条命令把排名最老的数据删掉只保留最新的1000条。滚动删除的时间复杂度是O(log N M)删除少量数据时很快但如果一次性删除几万条也要当心阻塞建议在低峰期分批执行。第二种是时间维度淘汰。用ZREMRANGEBYSCORE按时间删除超过指定阈值的feedZREMRANGEBYSCORE feed:user:123 -inf (170000000000000这种比保留条数更贴近业务比如只保留最近七天的feed。我把这两种策略做成了定时任务每天凌晨扫描一次所有feed key配合SCAN批量迭代删除过期数据整体对Redis实例的负载很平稳。5.2 冷热分离与多级缓存设计数据只保留最近的是不是就够了还有一个更深层的问题就算限制了条数如果所有热用户都集中访问Redis单个大Key的读写压力还是很大。我建议再叠一层冷热分离分页请求先走Redis热数据如果用户翻页翻得比较深已经超过了ZSet中保留的数据范围就直接走MySQL的历史feed表把返回结果组装后再返回。这一层不需要额外缓存历史feed的查询量本身很低走MySQL完全够用。这种设计的本质是Redis只解决“最近、最热、最高频”的查询MySQL负责兜底“久远、低频”的数据。我在Go和Java两个项目的落地经验是这个分层模型非常稳既能保证首次刷新秒开又不会让Redis被历史数据堆满。Redis内存从800GB降到了60GB主要就是靠这套“限长 冷热分层”。再补充一个微优化在应用内做二级本地缓存。由于feed流在短时间内同一用户很可能连续翻页在应用本地用LRU缓存保存最近十分钟内翻过的前两页数据响应速度还能再提一个台阶。本地缓存的命中率大概能有20%-30%并且完全不增加Redis压力。5.3 分页数据一致性与订阅策略扩展feed流分页里还有一个绕不开的取舍一致性与吞吐量。我一直用“最终一致”模型不追求用户发完feed后所有粉丝立刻在自己的时间线看到。写入feed时直接ZADD到粉丝ZSet如果粉丝量大就用异步消息队列来削峰避免长时间阻塞主流程。某个粉丝量特别大的作者发布一条动态需要推送给几百万粉丝如果同步ZADD很可能几秒内Redis都忙于写入。我的做法是作者发feed写一条作者自己的feed记录然后发一条消息给队列消费者异步把feedID写入所有粉丝的ZSet。这样发布接口的耗时稳定在几十毫秒粉丝的刷新延迟一般在几百毫秒到几秒之间业务完全可接受。反过来用户取关或者被拉黑时需要异步从粉丝ZSet里删除这个作者的feed。这块要注意的是删除范围和删除效率。如果作者在时间线上被删除了历史feed最简单的做法是异步删掉该用户ZSet中所有该作者的feed用ZSCAN找出member再逐个ZREM。个别大V粉丝量极大全量ZSet扫描删除也可能很慢可以结合粉丝的活跃度分层优先从近七天活跃粉丝的ZSet里删冷粉丝的残留数据就算展示出来影响也有限后续定时任务清扫即可。5.4 架构层面的Redis高可用与分页兜底最后聊聊高可用。feed流分页接口是所有流量入口里的高频接口Redis一旦故障最直接的后果是全站信息流不可用。我的架构里至少有三层兜底第一层是Redis主从加Sentinel或者Cluster自动故障转移。主节点挂掉后从节点秒级提升为主节点期间会有几十毫秒到几百毫秒的不一致但对刷feed场景来说影响不大。第二层是本地缓存兜底。如果Redis不可用接口返回本地缓存上最近几分钟的快照数据虽然可能不是最新的但用户不会看到白屏。这个兜底在双十一、春节这种流量洪峰时期尤其重要。第三层是MySQL兜底。Redis全面故障时直接降级为查询MySQL的feed列表可能性能差但至少可用。只要数据库没有被打爆服务就不会彻底死掉。我在压测中断言过即使Redis不可用全站feed流接口依然能维持QPS2000左右的降级吞吐这就是兜底设计的意义。关于分页本身再强调一点RedisZSet游标分页虽然性能强但它终究是内存型方案数据层要配合DB做完整闭环。千万别把所有feed数据只存在Redis一旦Redis重启或数据丢失连重建的依据都没有。我要求团队在写ZSet的同时必须把feedID和score落一份到DB或消息队列的审计表哪怕只是每天做一次全量快照也为冷启动和一致性修复留了底牌。这些年做下来我对feed流分页最深刻的体会是技术选型没有银弹ZSet也不是万能钥匙。真正决定成败的是细节——score是否严格单调、游标是否左闭右开、容量是否治理、Redis故障是否有兜底。只要你把这些细节抠到极致用户感知到的就是永远秒开、永不重复、永不漏数据的丝滑时间线。如果这篇梳理能帮你少走几条弯路就算没白写。