字节的 top 榜、微博的热搜、电商的销量排序凡是日活量级上来之后排行榜几乎是无一幸免的“基建毒瘤”。我刚接手的那套系统日增榜单位次过亿一开始用的是 Redis 的 ZSET 硬扛后来内存涨到 60 多个 G单条命令的平均时延从 0.3ms 直接干到 8msCPU 动不动就警报到 90% 以上。你要说“亿级排行榜方案设计”如果不把这一套底层的取舍逻辑讲透只丢几个缓存方案出来那基本等于白说。这篇文章想聊的不是“怎么用 ZSET 实现一个排行榜”而是当数据规模真正走到亿级的时候怎么做方案选型、怎么做架构设计、怎么在成本和性能之间做权衡。我会把我在实际项目中验证过的分桶 缓存 异步归并的完整方案写出来包括关键参数是怎么算出来的、哪些坑是你试了才会发现的、以及线上故障时的降级预案。适合正在做排行榜需求、或者已经发现 Redis ZSET 开始吃力、想从根上解决这块问题的后端同学。1. 需求拆解亿级排行榜到底难在哪里1.1 “亿级”不只是数据量而是三层压力叠加很多同学一听“亿级排行榜”第一反应就是“把 ZSET 换成 Redis Cluster 就行”。这个想法我能理解但实际碰过之后就会知道亿级排行榜难的根本不是存储而是写入吞吐、查询延时、内存成本这三件事同时发生在你身上。先说写入。亿级用户里如果按照日活 20% 的参与率来算一天就有 2000 万次行为上报平均下来每秒大概 230 次貌似不高。但真实线上不是平滑的热点时段比如晚上 8 点到 11 点的峰值能达到平均值的 5 到 8 倍也就是每秒 1200 到 1800 次写入。你以为这不算什么可是别忘了——排行榜的写入不是一次 ZADD 就完了很多时候你还要做用户旧分数查询、榜单成员数量维护、过期数据清理等等一整套流程下来单次请求对 Redis 的实际压力可能被放大 3 到 4 倍。再说查询。亿级排行榜面临的不只是“我排第几”这一种查询。还涉及 TopN 榜单展示比如前 100 名、好友排行榜几十个人的相对排名、附近的人地理位置 名次等。查询模式一旦多样化ZSET 的单键结构就捉襟见肘了。只看 TopN 的话没啥问题但一旦要查中段名次或者某个用户的精确排名ZSET 的底层跳表查找虽然理论是 O(logN)可亿级数据下 Redis 是单线程一个慢查询可能把所有请求都拖慢。最后是内存。ZSET 在亿级数据下有多占内存这个是很多人忽略的。一个 value 是 32 字节的字符串加上 8 字节的 double 分数在 Redis 里实际占用的内存大概是 70 到 80 字节注意这里还没有算跳表节点的额外开销。一亿个成员光 ZSET 就要吃掉差不多 8 到 10 个 G 的内存。你以为这就完了如果还需要做多维度排行榜比如日榜、周榜、总榜按三份来算就是 24 到 30 个 G。再考虑 Redis 主从复制和持久化内存翻倍直接到 60 G 级别这个成本扛得住吗1.2 常规方案为什么会在亿级规模下崩掉我接触过不少团队排行榜一上来就直接用 ZSET也不做啥复杂设计。前期几千、几万用户的时候确实香因为 ZSET 的 API 简单ZADD 加积分、ZREVRANGE 拿 TopN、ZREVRANK 查排名一步到位。但数据量涨上来之后暴露的问题就很典型。第一个问题是单键热点。所有用户的数据全部塞进一个 ZSET 的 key 里这个 key 只能分布在一台 Redis 分片上。就算你上了 Redis Cluster它也只负责切片不能把一个 key 拆到多个节点。结果就是集群里有 16 个分片15 个闲着1 个被打满。CPU 在单线程上烧到 100%其他请求排队等整个集群的尾延迟全部拉高。这个问题是架构级别的靠升级配置解决不了。第二个问题是内存被倍数放大。ZSET 的底层是哈希表加跳表收益是读写效率稳定代价就是每一条成员数据都有大量的指针和节点开销。在 Redis 6 之后虽然引入了 listpack 来优化小体量 ZSET但数据量一上来编码还是会被迫转换成 skiplist内存占用一下子就失控了。你如果监控过 Redis 的 used_memory会发现当 ZSET 成员数从百万级涨到千万级、亿级的过程内存增长速度比想象中快得多。第三个问题是刷榜与治理困难。排行榜不是写进去就不管了它需要清理无效数据比如机器人账号、处理封禁用户、做每日整点重置。如果全部堆在一个大 ZSET 里每次批量清理都是一次大范围遍历Redis 的 KEYS 命令不能碰只能用 SCAN 游标慢慢扫一亿的量扫一轮要花好几个小时中间还不能有大批量删除否则主从延迟直接报警。所以我把结论先放在这里如果你正在用单个 ZSET 支撑亿级排行榜并且觉得还能用多半是你还没遇到真正的热点流量。只要某一次运营活动带来几倍流量你会看到 Redis 的慢日志刷屏然后整个服务的可用性被拖下水。2. 整体方案设计分桶 异步归并 缓存读路径2.1 分桶思想把一个大 ZSET 拆成 N 个小 ZSET解决单键热点和内存失控的核心思路其实非常简单——不要把所有鸡蛋放在一个篮子里。既然一个 key 只能驻留在一个节点那么我们就把这个 key 拆掉。具体做法是按照用户 ID 或者分数区间做分桶每个桶是一个独立的 ZSET。比如按用户 ID 取模分桶分成 256 个桶每个桶就是一个 ZSET key命名为 rank:bucket:{mod}:{date}。这样每个 ZSET 的成员数量就变成了 1 亿除以 256大概是 39 万这个量级对于 ZSET 来说完全在舒适区内。从 Redis 的角度看内存占用均衡了查询热点也被分摊到了不同的分片上单节点的 CPU 压力自然就下来了。那分桶后怎么查一个用户的排名呢你先根据用户 ID 算出他的桶号然后在对应的桶里查询排名。这里有个细节查出来的名次是相对于该桶的名次不是全局名次。要得到全局名次你需要知道该桶之前所有桶中的成员总数然后加上桶内排名。这个总数可以定期统计后放到一个单独的小 key 里或者用计数表维护。细节我放在后面的工程实现部分展开。除了按用户 ID 分桶还有一种按分数区间分桶的打法。比如按分数段把用户拆到 [0, 10000)、(10000, 20000) 等区间里这种方案对“查看同分段排名”的业务场景特别友好但实现起来难度更大因为用户分数是动态变化的跨桶移动是家常便饭维护成本比较高。我个人的经验是大部分业务场景用 ID 分桶就够了分数分桶只在特定排行榜里才会用不要一上来就上高难度的。2.2 读路径设计一次查询 90% 命中缓存分桶解决了数据分布问题但没有解决“查询一定要进 Redis”的问题。实际上排行榜的读流量是远高于写流量的——用户打开 App 看到排行榜页面页面上可能一次要拉取 TopN、当前用户排名、好友排名等好几类数据。所以在读路径上加缓存是性价比最高的优化手段。具体怎么做呢我在方案里设计了三个层级的缓存本地进程内缓存比如 Caffeine、Redis 聚合缓存、以及最终的 Bucket ZSET。对于一个 TopN 榜单请求它首先会打到一个聚合查询服务这个服务把 N 个桶的 TopN 数据拉回来做归并排序然后把最终结果写入一个 Redis 聚合 key 里并设置很短的过期时间比如 10 到 30 秒。在这段时间内所有同类的 TopN 请求都直接走 Redis 聚合缓存不再去碰底层的 N 个 ZSET。对于“查我的排名”这种请求由于用户 ID 已知我们可以直接在进程内缓存里保存一份“用户 ID - 用户当前分数和名次”的映射过期时间可以设置为 1 到 5 分钟。排行榜场景中用户对自己的名次敏感度其实没那么高稍微有一点点延迟是完全能接受的但带来的性能收益却是巨大的——我实测下来这种读路径设计能把 Redis 的整体 QPS 降到原来的 15% 左右。有一点需要提醒本地缓存是部署在多台机器上的数据天然不一致你千万不要把强一致性的业务逻辑寄托在本地缓存上。我见过有团队让本地缓存保存 30 分钟以上跑活动的时候用户分数和名次对不上引发大量客诉。排行榜这种场景用户是可以容忍“几秒到几分钟的延迟”的但不能容忍“我明明赢了却不显示我赢”。所以本地缓存的过期时间宁可短一点也不要图快设太长。2.3 写路径设计削峰填谷异步落桶排行榜的写入高频且实时性要求相对不高所以非常适合做异步化处理。客户端或者业务服务产生一次计分事件后并不需要直接写 Redis 的 ZSET而是先发到消息队列比如 Kafka 或 RocketMQ由专门的消费者服务去处理真正的 ZADD 请求。这样做的价值有两点一是削峰填谷消息队列天然具备缓冲能力即使上游流量在某一秒突增到几千甚至上万次计分消费者也能按照自己预设的速率消费Redis 端不会被打爆二是解耦计分业务和排行榜存储之间互相不知道对方的实现细节后续要换存储介质或者调整分桶逻辑只需要改消费者即可。延迟如何保证消息队列处理这几秒排行榜上其实看不出来因为展示的榜单快照本来就是缓存的。我通常是把“用户通知”比如提示你上升了多少名做成准实时的而“全量榜单还原”做成 1 分钟级别的最终一致。这样既有实时性的体感又不会因为链路太长导致 Redis 压力过大。还要设计一个兜底的失败重试机制。消费者处理 ZADD 时如果失败了比如 Redis 短暂不可用消息不能直接丢弃要带到重试队列或者依赖 MQ 自身的重投机制。我遇到过一个更微妙的问题消息重复消费导致分数被重复累加。这个问题必须在计分事件里带上一个全局唯一的事件 ID消费者侧做幂等判断否则一旦 MQ 重投用户分数会平白无故地翻倍后面排查起来非常痛苦。2.4 为啥不用 Redis Cluster 直接硬扛这段是写给我自己团队看的也希望能劝住一些正在犹豫的同行。Redis Cluster 的模式下单个 key 仍然不能自动化拆分成多个节点。它不是解决 ZSET 大 key 问题的方案它是解决“大量小 key 分布在多节点”的方案。你把一个亿级的 ZSET 放进 Cluster实际上只是把这个大 key 随机分配到某一个节点上其他节点帮不上忙热点、内存、慢查询问题一个都不会少。Cluster 该不该上我的答案是如果机器资源充足、预算到位它作为整个 Redis 层的扩容手段是有价值的毕竟它提供了良好的分片和管理能力。但如果你指望着它能解决亿级排行榜本身的单 key 瓶颈那方向就错了。真正解决单 key 瓶颈的只有业务层的分桶逻辑。当然不排除一种做法使用 Redis 企业版的“自动分片 ZSET”之类的功能。这个我没有在实际生产环境试过而且它的可用性和性能表现非常依赖版本和部署形态如果你不是刚好已经在用对应的商业版产品我不建议大家为了排行榜单独引入一套商业版——成本和复杂度往往收不住。3. 工程落地完整架构和关键代码细节3.1 分层架构图景与组件选型在动手写代码之前先把我落地这套方案时用的完整组件栈列出来方便你对照自己的环境做选型。这里不是唯一解但至少是我验证过的组合。业务服务负责接收计分请求发送计分事件到 MQ同时提供排行榜的查询接口。消息队列Kafkatopic 按业务线隔离比如score-rank-{biz}分区数充足建议桶数的两倍以上。消费服务独立部署一组消费者负责消费计分事件并写入 Redis 分桶 ZSET。聚合服务提供 TopN 和用户排名的查询接口也负责在查询 Miss 时回源汇总底层分桶数据。缓存层三层。进程内 Caffeine / 聚合 Redis / 底层分桶 ZSET。Redis 存储建议使用 Redis Cluster但只是作为通用的分布式存储底座不作为排行榜分片方案。组件选型上有个容易被忽略的点消息队列的 topic 分区数和分桶数之间最好有比例关系。我和团队最终稳定下来的是256 个分桶Kafka 分区数量设置 64 或 128。为什么因为消费者的并发度取决于分区数如果分区数太少消费速度跟不上写入速度如果分区数太多批量 ZADD 的合并效果会被稀释。你可以在上线后持续观察消费 Lag通过分区数调节消费吞吐。3.2 分桶 key 的设计和维护细节分桶 key 的命名和生命周期管理是整个方案里最容易写出“看起来能跑、上线就炸”代码的地方。我采用的 key 格式如下日榜rank:daily:{yyyyMMdd}:{bucketId}周榜rank:weekly:{yyyyMMdd}:{bucketId}// 这里的日期取当周周一总榜rank:total:{bucketId}分桶数 N建议第一步就确定为 256原因有两个一是 2 的整数次幂取模计算用位运算更高效二是 256 个桶在 Redis Cluster 里能相对均匀地分布后续如果流量再涨你还可以继续翻倍到 512、1024但每个桶里的 ZSET 数量会变小需要重新做一次数据迁移或双写过渡。生命周期管理方面日榜的数据过期时间设为 48 小时即可。Redis 的 TTL 机制能自动清理但要注意如果用户分数频繁更新key 的 TTL 会被自动延长比如你每次 ZADD 都重新 EXPIRE最终可能导致过期的 key 不能按时清理内存慢慢被撑爆。我的做法是只在每天首次写入某个日榜 key 时设置 TTL后续的 ZADD 不再重复设置过期时间这样时间一到它就会被 Redis 自动删除。你可以在代码里用SETNX的方式去设置一个额外的“初始化标记”用来判断是否需要重新 EXPIRE。还有一个细节周榜和月榜的 key 数量会持续累积必须有一个定时任务主动清理过期的周榜、月榜 key。我踩过的坑是第一次上线时没有做这个清理半年后 Redis 里积累了几千个大 key内存直接多出 30 多个 G。定时清理脚本很简单但一定要配监控确认它每天都在跑、每次都能扫到该扫的 key。3.3 写入链路消费端批量 ZADD 的性能调优消费端如果一条一条地 ZADD在亿级规模下效率太低。单条 ZADD 的网络往返开销非常大哪怕 Redis 本身处理只需要 0.1ms网络和序列化也会把整体吞吐拉下来。合理的做法是把多条计分事件合并成一个 Pipeline一次网络请求批量写入。伪代码如下public void consumeScoreEvents(ListScoreEvent events) { // 按分桶分组 MapInteger, ListScoreEvent grouped events.stream() .collect(Collectors.groupingBy(e - e.getUserId() (BUCKET_NUM - 1))); // 对每个分桶构建一个 Pipeline批量 ZADD for (Map.EntryInteger, ListScoreEvent entry : grouped.entrySet()) { String key buildDailyRankKey(LocalDate.now(), entry.getKey()); redisTemplate.executePipelined((RedisCallbackObject) connection - { for (ScoreEvent event : entry.getValue()) { connection.zAdd(key.getBytes(), event.getScore(), event.getUserId().toString().getBytes()); } return null; }); } }Pipeline 的批量大小不是越大越好。我实测下来单次 Pipeline 里放 200 到 500 条命令时性能最优再增大后收益变缓反而可能导致 Redis 侧的内存分配压力增大和单次请求耗时过长。建议你在压测环境里跑几组数据对比一下不同版本和部署模式下最优值会有差异。关于分数更新方式这里必须重点提醒一个“加法陷阱”。很多业务场景的计分逻辑是“每次 5/10”如果你简单的 ZADD 覆盖会造成严重丢分问题因为并发请求下你先写入的分数被后写入的覆盖了。正确做法是使用ZINCRBY让 Redis 在内部累加这样即使多条消息并发到达结果也是正确的。不过 ZINCRBY 有性能损耗所以消费端还是要做一层聚合比如把同一个用户 1 秒钟内的多次计分事件先合并成一次增量再通过 Pipeline 发到 Redis。如果业务对分数精度要求非常高比如涉及现金、积分那么在 Redis 里存整数分数就够了不要在 Redis 里做浮点累加。浮点数在跳表里的比较逻辑容易踩精度坑虽然一眼看不出问题但大促时会出现排名错乱的诡异现象。3.4 查询链路TopN 的聚合归并算法实现TopN 查询的完整流程是先查聚合缓存Miss 后去 N 个桶里各取当前 TopN然后再归并出总的 TopN。这里有两个细节值得展开讲。一是每个桶取多少数据。如果你要的是全局 Top100每个桶理论上只要取 Top100 就可以了因为一个用户在一个桶里排名在第 100 名之后绝无可能进入全局 Top100前提是每个用户只存在于一个桶中。所以桶内数据量取 TopN 即可不需要多取。二是归并排序的实现。N 个桶256 个每个桶返回一个已经按分数降序排好的列表归并方式最简单就是一个大小为 N 的最小堆容量为你要的最终 TopN 条数。桶数量不算多直接用一个大根堆反复把每个桶当前分数最高的元素弹出直到凑够你要的 TopN 为止复杂度是 O(N * TopN * log(N))。N256 时即使 TopN1000这个计算量也只是几十毫秒级别的完全可以承受。示例代码如下public ListRankItem queryTopN(int topN) { // 1. 先查聚合缓存 ListRankItem cached getFromAggregateCache(topN); if (cached ! null) { return cached; } // 2. 从每个桶拿 TopN ListListRankItem bucketLists new ArrayList(); for (int bucketId 0; bucketId BUCKET_NUM; bucketId) { bucketLists.add(getBucketTopN(buildKey(bucketId), topN)); } // 3. 在内存中归并排序 PriorityQueueRankItem heap new PriorityQueue((a, b) - Long.compare(a.getScore(), b.getScore())); // 初始化堆把每个桶当前第一位的元素放入按分数升序的堆方便淘汰最小 ListIteratorRankItem iterators bucketLists.stream() .map(List::iterator).collect(Collectors.toList()); for (IteratorRankItem it : iterators) { if (it.hasNext()) { heap.offer(it.next()); } } // 逐个取出分数最高的元素并补充同桶的下一个元素 LinkedListRankItem result new LinkedList(); while (!heap.isEmpty() result.size() topN) { RankItem item heap.poll(); result.addFirst(item); int bucketIndex item.getBucketId(); if (iterators.get(bucketIndex).hasNext()) { heap.offer(iterators.get(bucketIndex).next()); } } return result; }上面这段是基于每个桶的列表已降序的前提。实际操作时查出来的桶列表要带上 bucketId这样在归并时才能做到“每次弹出后从对应桶补充下一条”。另外归并完成后的一瞬间一定要把结果写入聚合缓存避免同一时间窗口内的请求全部回源底层。3.5 排名查询从用户 ID 到全局名次的计算路径“查我的排名”这个需求在分桶方案下的数据流是这样的根据用户 ID 计算所在分桶bucketId userId (BUCKET_NUM - 1)。在该分桶的 ZSET 中查询用户分数ZSCORE key member。如果用户不在该桶中返回未上榜。在桶内查当前用户在桶中的排名ZREVRANK key member得到的是从 0 开始的名次。计算该桶前面的所有桶中的成员总数加上桶内名次得到全局名次。第 5 步里“桶前面的所有桶成员总数”这个数据怎么来可以在分桶 ZSET 的元数据 key 里单独记一个“每个桶的成员总数”定时更新。或者更简单一点——在查询路径上动态统计用ZCARD查每个桶的成员数量然后累加。这两种方式各有适用场景动态统计的优点是实时准确缺点是要发好几个 Redis 命令定时维护的优点是一次统计多次使用缺点是刚更新后到下一次更新之间统计值会稍微滞后。考虑到“查我的排名”的吞吐本来就很高我倾向于采用“定时统计 极短过期时间”的方式。每个桶的成员数量由后台任务每 30 秒统计一次放入一个名为rank:bucket:count:{date}的 Hash 中查询时一次 HGETALL 就能拿到所有桶的数量。这样既保证了实时性的体感又不会给 Redis 增加额外压力。这里有个和产品预期相关的小经验排行榜名次里的“并列排名”处理策略要在需求阶段就确定。因为 Redis ZSET 在同分时按字典序排序不同用户即使分数一样位次也会分先后。绝大多数产品希望“同分同排名”这就需要用业务层再做一次名次重排。我自己的处理方式是取完 TopN 或全局名次后按分数段做一次压缩同分取最小名次这样既不会改变 Redis 内部排序也满足了产品的展示需求。4. 常见问题和故障排查实录4.1 故障现场一Redis 内存翻倍排查发现平滑过期失效当时现象很清楚日榜正常但 Redis 的内存占用每天都在涨而且没有任何下降的趋势。P99 时延从 2ms 一路到 10ms。排查过程从redis-cli --bigkeys入手发现大量日榜 key 的 TTL 长达十几天明显不是日榜该有的过期时间。代码审查后确认问题出在每次 ZINCRBY 后都调用了一次 EXPIRE导致 key 的 TTL 一直被续期永远无法被自动清理。看起来无伤大雅的一行代码在每天高频写入的场景下变成了内存泄漏。改造方案也很简单在第一次对 key 做写入时设置过期时间并且用一个独立的初始化标记位防止重复设置。上线后内存曲线肉眼可见地稳定下来再没有出现过类似问题。4.2 故障现场二大促峰值消费 Lag 暴涨某次大促活动流量是平时的 10 倍Kafka 消费组的 Lag 直接涨到几百万条排行榜上数据延迟超过半小时。我们当时的第一反应是加消费者实例但由于消费者的 Redis Pipeline 批量大小和线程数配置不合理加机器后 Redis 直接被压到 CPU 99%问题反而恶化了。后来通过逐步降低消费者线程数到合理水位、调整 Pipeline 批量大小为 300 条、并增加了一个本地微批聚合的逻辑同一个用户 1 秒内的计分事件先合一次再写消费速度才慢慢追上生产速度。这给我一个很深的教训异步化链路出问题时不一定是“加机器”能解决的多数时候瓶颈在下游存储上游加再多的并发只会把下游打得更惨。4.3 常见问题速查表问题可能原因排查方式解决方案Redis 内存持续上涨TTL 续期 / 过期 key 未清理检查 key 的 TTL 分布--bigkeys结合日常监控修正 EXPIRE 调用逻辑定时清理历史 key排行榜分数翻倍MQ 重复投递消费端未做幂等查看消费者日志是否有重复消息 ID对比线上分数计分事件带唯一 ID消费端做去重某分片 CPU 打满大量请求集中在少数桶检查 Redis Cluster 的 slot 访问热点重新调整分桶函数热点桶二次拆分明明有分数却排不上名次并发 ZADD 覆盖了分数检查写入链路是否用了 ZINCRBY消费端做时间窗聚合后再 ZINCRBYTopN 榜单数据陈旧聚合缓存过期时间过长查看缓存命中率和过期时间配置缩短过期时间或增加版本号主动失效大促消费 Lag 上涨消费者吞吐不足查看 Kafka Lag 和消费线程 CPU调整 Pipeline 批量大小微批聚合去重我强烈建议在排行榜服务上线之初就配好三张基础监控看板Redis 内存和慢查询、Kafka 消费 Lag、排行榜接口 P99 时延。这三张图能帮你省掉大量排查事故的时间。不要等到撒出去之后再来补第一天就要盯。4.4 两个容易忽略的“小决策”一个是分桶数的预设值。我在方案里建议了 256但如果你们的业务天花板明显更高建议直接设置 1024。因为分桶数在后期的调整成本很高期间需要经历数据迁移、双写、切流量每一步都有风险。宁可一开始多分一些桶里数据少一点无所谓ZSET 在百万级以内性能都很稳。不要为了省那几个 key 把桶数整得太少。另一个是分数过期策略。很多排行榜业务都有“超过 N 天不活跃就从榜单中移除”的需求。这可以通过在业务层扫描更新时间和当前时间的差值来实现也可以依赖消费端对活跃时间戳做一个旁路记录。后者更简单——在用户计分事件的同一批消费逻辑里额外维护一个rank:last-active:{bucketId}的 Hash定期清洗不活跃用户对应的分数记录。注意不要在主赛道里做大规模扫描否则会影响正常的读写链路。5. 扩展与演进这套方案还能怎么用5.1 同架构支撑多排行榜分桶 缓存 异步归并这套架构可不只是为“用户积分榜”服务的。比如电商业务的“销售额店铺榜”只需要把计分事件改成订单完成事件把分数的含义从积分换成交易金额其他环节基本原样复用。再比如内容平台的热度榜按阅读数、点赞数、评论数加权计算一个热度分同样走这条链路。复用的时候最需要注意的是“分数来源发生变化”。积分榜是高频小额的累计订单榜可能是低频大额的跳变。后者如果还用“时间窗内先做本地聚合再写”的策略会导致分数更新不及时用户明明刚完成一笔大额订单榜单上却看不到变化。这种情况应该跳过微批聚合直接走单条 ZINCRBY保证更新延迟在秒级以内。5.2 从 Redis 迁移到线程内存储的边界当分桶数到 1024 之后每个桶的数据量降到 10 万级此时还有一个更激进的优化方向把排名数据从 Redis 搬到服务进程内的 LocalCache 里用跳表或者 B 树结构维护。单机内存完全可以放下查询走本地写入走异步线程更新。这种方式把 Redis 从读链路上彻底摘掉延迟能压到微秒级。但它的代价是所有排行榜数据只能在一台机器上全量加载不能水平扩展服务重启后需要一段预热时间才能承担流量。除非你的排行榜规模大到连 Redis 集群都撑不住说实话这个量级已经不常见了否则我不建议轻易尝试。我的经验是把 Redis 方案压榨到极致大概率已经能满足 99% 的业务需求。方案设计的价值从来不在于追求某个“惊天妙招”而在于把每个决策背后的代价和收益都摆到台面上。比如我们今天说分桶不是说它比 ZSET 高级多少而是 ZSET 的模型在亿级数据下会碰到的痛点分桶恰好能合理规避。选择什么方案永远要回到你们的业务规模和资源预算上去。最后分享一个我个人很受用的体会做系统设计的时候一定要在方案文档里把“什么规模下这个方案会失效”写清楚。很多时候方案本身没有绝对的对错只有“适不适合当前阶段”。排行榜这种需求短期内可能几百行代码就能交付但长期看决定它是运维噩梦还是稳定组件的正是你最初设计时的那些取舍。
