昨天有位粉丝找我哭诉腾讯 IEG的二面经历。题目很经典：“王者荣耀全服 1 亿玩家，如何设计实时战力排行榜？”
他显然是有备而来，自信满满地甩出了“Redis ZSet 分段桶排序”的方案：把玩家按分数每 1000 分切一个 ZSet，避免 BigKey，查排名时累加各桶人数。
本以为稳了，结果面试官冷冷地问了三个问题，直接让他破防：
“你知道正态分布吗？如果中间段位（如钻石/星耀）集中了 6000 万人，你那个‘钻石桶’是不是依然原地爆炸？”
“Redis Cluster 模式下，Lua 脚本跨节点无法执行。你为了原子性把所有桶绑定到一台机器（HashTag），那这台机器还能活？”
“同分你怎么排？用小数存时间戳？你知道 Double 类型的精度会丢失吗？”
兄弟出了会议室直接想删号。今天我们就来硬核拆解这道题。从“想当然”的八股文，到真正能扛住亿级流量的“工业级”架构。
一、 致命陷阱：被忽视的“正态分布”
很多候选人死守“分桶”策略（0-1000分一桶，1000-2000分一桶）。这在电商金额分布里可能行得通，但在游戏里是死路。
游戏段位是典型的正态分布！
王者（头部）：人少，也许就 10 万人。
青铜（尾部）：弃坑号多，不活跃。
钻石/星耀（腰部）：拥堵区！这里可能堆积了全服60%~70%的活跃玩家。
惨案复现：
如果你按固定分数分桶，那个“钻石桶”里依然会有5000 万+的数据。
结局：BigKey 问题压根没解决，Redis 单线程操作依然卡死，且集群数据严重倾斜，一个节点忙死，其他节点闲死。
二、 破局：P8 架构师的“三层漏斗”设计
要解决 1 亿人的排名，核心心法只有一条：“抓大放小，甚至不准”。真正的全服排行，其实不需要对 1 亿人都做 ZSet 排序。我们把玩家分成三层漏斗：
第 1 层：Top 1000 “荣耀榜” —— 极致精确
对象：全服最顶尖的那 1000 人。
方案：单 Key Redis ZSet。
逻辑：这部分人最少，但关注度最高（膜拜榜）。直接用一个
global_rank_zset存储，实时性要求秒级。
防坑（跨界摩擦）：
如果第 1001 名赢了一把变成了第 1000 名，涉及“ZSet 踢人”和“Hash 计数器减人”的跨数据结构操作，Redis Cluster 无法保证原子性。
策略： “数据冗余”。ZSet 实际存储 Top 5000，对外只展示 Top 1000。这样“边界摩擦”发生在第 5000 名，对前 1000 名的展示没有任何影响，实现了软隔离。
第 2 层：活跃玩家（中间 90%）—— 统计概率
痛点：钻石玩家不关心自己是第 50,000,001 名，他只关心“我超过了多少人”（百分比排名）。
方案：Redis Hash 计数器（直方图）。我们不再存
(PlayerID, Score)的 ZSet，而是把分数切得更细（比如 1 分一个槽），只存“这个分数有多少人”。
结构示例（Redis Hash）：
Key: Rank_Counter Field: "Score_2500" -> Value: 12050人 Field: "Score_2501" -> Value: 13000人算排名：
我的排名 （比我高分的所有 Score 的人数之和） + （Top 1000 人数）。
Fox 高能预警（防杠补丁）：
如果 5000 万人在线，每秒有 10 万人结算，这 10 万写 QPS 打在一个Rank_CounterKey 上，Redis 依然会爆。
优化： Sharding（分片）。必须将 Hash 拆分成 N 个 Key（如Rank_Counter_1~Rank_Counter_10）。写入时随机分片，读取时聚合所有分片的数据。这就把单点压力分散到了集群。
第 3 层：我的排名 —— 惰性与降级
场景：玩家点开“个人主页”看排名。
逻辑：前端不需要显示精确的“第 43,241,555 名”，而是显示“星耀II - 前 35%”。
如果非要精确排名？那就走ClickHouse或Spark的分钟级离线计算。玩家打完一局，排名不会秒变，等个 5 分钟更新一次，完全可接受。
三、 隐形深坑：写扩散与数据对账
面试官如果问到这里，说明他对你很满意了。但真正的杀招在后面。
1. 写扩散与削峰
问题：1 亿玩家，晚高峰每秒几十万局游戏结束，直接操作 Redis 会导致写风暴。
解法：Kafka 缓冲 + 微批处理。
GameServer 不要直连 Redis，把分数变化推到 Kafka。
中间件
Rank-Service消费 Kafka，将 100 毫秒内的 50 个+1操作合并成一次INCRBY 50，再写 Redis。效果：这能把 Redis 写压力降低两个数量级。
2. 数据漂移与对账
问题：计数器方案是INCRBY操作，如果服务挂了，-1成功但+1失败，总人数就会永久少 1 个。时间久了，排行榜人数会越来越少（数据漂移）。
解法：T+1 离线对账。
Redis 只负责“实时趋势正确”。每天凌晨，利用 ClickHouse 的全量数据重算一遍 Hash 计数器，覆盖 Redis。实时求快，离线求准。
四、 细节防坑：同分排名与精度陷阱
面试官问的第 3 点：“同分先到先得”。
网上的通解是：Score = 分数 + (1 - 时间戳/极大值)。
错！大错特错！
Redis 的 ZSet Score 是Double 类型（IEEE 754），有效精度只有52 位。如果你的时间戳（毫秒级）除以一个大数，变成小数点后十几位，Redis 会直接丢弃精度！导致两人 Score 变成一样。
正确解法（位运算拼接）：
利用整数的“高位”和“低位”思想，但要确保总数值不超过 。
公式：
真实分数
高位：保证了分数高的绝对排在前面。
低位：时间越小（越早），
(Max - Cur)越大，低位补得越多，总分越大，排前面。
注意：必须严格计算位数，确保拼接后的数字不超过9 千万亿（即 安全整数范围），否则 double 依然会丢精度。如果业务分数很高，建议直接牺牲时间精度（精确到秒即可）。
五、 面试标准回答模板（直接背诵）
下次再被问 1 亿排名，请抛弃“简单的分桶”，甩出这套工业级组合拳：
“面试官，针对 1 亿级玩家，单纯的分桶策略无法解决正态分布导致的 BigKey 问题，且集群下无法原子操作。我的设计思路是‘分层架构 + 统计估算’：
分层架构（Funnel）：
头部（Top 5000）：使用 ZSet 存储。数据冗余设计，避免排名变动时的跨数据结构事务问题。
腰部（99%）：使用Redis Hash 计数器。为了解决单点热点写，我采用了Sharding 策略（拆分 16 个 Key 随机写）。
尾部：异步落库 ClickHouse，不做实时排名。
抗压与一致性：
削峰：引入Kafka做写缓冲和微批处理（Micro-batching），降低 Redis 写 QPS。
对账：承认 Redis 计数器存在‘漂移’可能，采用T+1 离线对账覆盖修正，保证最终一致性。
精度处理：
同分策略：放弃小数时间戳（有精度丢失风险），采用‘高位分数 + 低位时间互补’的整型拼接策略，确保先到先得，且数值控制在 以内。
这套方案既规避了 Redis 内存瓶颈，又完美契合了游戏业务对‘实时性’和‘精确度’的分层需求。”
写在最后
技术面试考的永远不是死记硬背 API，而是你对“极端场景”的敬畏心。能用 1 万个 Key 解决的问题（计数法），绝不用 1 亿个 Key（ZSet）。架构做减法，才是真专家。
https://mp.weixin.qq.com/s/ZhVULR3esu66ZrMVaCEm2g
