全球排行榜的难点：你要实时，还是要全球一致

凌晨两点，某款竞技手游的东南亚服刚结束一轮天梯赛。

一个越南玩家刷新排行榜，发现自己从第 3 名掉到了第 7 名。更让他困惑的是，第 6 名是一个五分钟前还没出现在榜单上的匿名账号。

他不知道的是，这个账号的最新积分来自美国西部 Region，只是因为跨区域同步延迟，直到现在才进入全球榜。

玩家眼里，这像是排行榜“算错了”。

但从系统角度看，这可能不是 Bug，而是架构设计主动接受的一种结果。

因为全球排行榜真正难的，从来不是排序。

真正难的是：

“现在看到的排名”，和“最终定义的排名”，并不是同一件事。

玩家看到的是某个时间点的局部快照，而所谓“全球第几名”，意味着系统必须同时知道所有区域、所有玩家的有效成绩。

当玩家分散在新加坡、欧洲、北美甚至更多 Region 时，这两个目标之间天然存在距离。

而这段距离，就是全球排行榜真正的架构成本。

一、排行榜最大的敌人，不是排序，而是距离

如果排行榜只部署在一个机房，事情其实非常简单。

玩家提交积分：

Client  ↓API  ↓Redis ZSET / Database  ↓返回最新排名

单机房内网络延迟通常很低，写入完成后立刻查询，玩家几乎可以马上看到自己的新排名。

问题出现在全球化之后。

假设系统部署在：

• 新加坡
• 法兰克福
• 美国弗吉尼亚

三个 Region。

如果要求每一次积分更新都必须在多个 Region 达成一致之后才能返回，那么一次普通写入，就会被迫等待跨洲网络往返。

而跨洲通信的延迟，不是换一个数据库就能消失的。

这背后首先是物理距离，其次还有公网路由、网络抖动、丢包、链路拥塞以及跨云网络成本。

于是系统会面对一个很现实的三角关系：

本地低延迟写入、跨区域强一致、网络故障下持续可用，很难同时做到最好。

注意，这并不是简单地套一句“CAP 三选二”。

CAP 真正讨论的是发生网络分区时，一致性和可用性的选择。

而全球排行榜日常更常见的问题，是另一层现实：

为了获得跨 Region 的强一致，你必须付出额外的网络往返时间。

也就是说，即使系统没有发生真正的网络分区，只要你把一致性边界扩大到全球，延迟就已经开始上升。

所以全球排行榜的第一个问题从来不是：

Redis 还是 MySQL？

而应该是：

一次积分提交，必须多久返回？

玩家看到的排名，允许落后真实状态多久？

最终结算时，又必须准确到什么程度？

这三个问题不明确，后面的技术选型几乎都没有意义。

二、先把排行榜拆成三条数据路径

理解全球排行榜，一个非常有效的方法，是不要把它看成一个“排序服务”。

而是拆成三条完全不同的数据路径：

写入路径、同步路径、查询路径。

这三条路径的目标并不相同。

1. 写入路径：先保证玩家本地体验

玩家完成一局比赛后，客户端提交结果。

典型路径可能是：

Client   ↓Nearest Region API   ↓Score Validation   ↓Region Leaderboard Store

这里最重要的原则是：

玩家的核心请求，尽量在本 Region 内闭环。

因为对于游戏来说，积分提交首先是一次用户交互。

如果每次比赛结束都要等待欧洲、亚洲、北美多个数据中心确认，这个延迟会直接暴露给玩家。

因此常见设计是：

1. 请求进入最近的 Region；
2. 服务端校验比赛结果；
3. 更新 Region 内排行榜；
4. 立即向玩家返回；
5. 再异步同步到全球排行榜。

Region 内的排行榜可以使用：

• Redis Sorted Set
• ScyllaDB / Cassandra
• 自研内存排序结构
• 关系数据库 + Top N 缓存

具体选什么并不是关键。

真正关键的是：

本地写入路径不要被全球一致性拖住。

2. 同步路径：全球排名的代价在这里产生

本地积分更新完成之后，系统需要把变化传播出去。

一种常见方式，是发布积分变更事件：

Region A   ↓Score Update Event   ↓Kafka / Pulsar / Event Bus   ↓Global Leaderboard Processor

事件可能包含：

player_idscoreversionregionupdated_at

全球排行榜服务消费这些事件，再更新自己的排名视图。

这样做最大的好处是：

写入路径和全球聚合彻底解耦。

玩家不用等待全球同步完成。

代价也同样明显：

全球排名不再是“立即正确”，而是“最终正确”。

Region A 的数据可能已经更新，而 Region B 的最新事件还在路上。

这时系统计算出来的全球榜，本质上只是：

“截至当前已收到事件”的全球排名。

而不是理论意义上的绝对实时排名。

这也是很多排行榜出现“名次回跳”的根本原因。

3. 查询路径：用户看到的，其实只是一个版本

第三条路径，是查询。

玩家点击排行榜时，系统返回什么？

这看似简单，其实决定了用户最终感受到的是“实时”，还是“稳定”。

一个常见结构是：

Client   ↓Leaderboard API   ↓Leaderboard Cache   ↓Global View / Region View

这里至少有三种策略：

策略一：永远读取 Region 榜

优点是快。

缺点是玩家看到的只是区域排名。

策略二：读取异步计算的全球榜

优点是具备全球竞争感。

缺点是榜单存在几秒甚至几十秒延迟。

策略三：两个榜同时存在

例如：

东南亚排名：12全球排名：186全球数据更新时间：3 秒前

从用户体验角度看，这往往比“假装全球榜绝对实时”更合理。

因为系统并没有隐藏一致性延迟，而是把数据的新鲜度明确暴露出来。

这是一个非常重要的产品设计思想：

一致性问题，不一定全部靠后端消灭，也可以通过产品语义进行管理。

三、局部榜和全球榜之间，真正关键的是“合并窗口”

全球排行榜最重要的架构参数之一，不是 QPS，也不是玩家数量。

而是：

Merge Window，合并窗口。

所谓合并窗口，就是：

一条 Region 内已经生效的积分变更，最长允许多久之后才进入全球榜？

假设定义：

Merge Window = 1 秒

那么用户看到的全球排名最多落后真实状态约 1 秒。

如果定义：

Merge Window = 5 分钟

那么整个系统就可以简单很多。

所以排行榜设计中真正应该被量化的问题不是：

“要不要实时？”

而是：

允许多实时？

四、三种最常见的全球榜合并方式

方案一：定时批量计算

最简单的方案，是每隔一段时间重新计算全球排名。

例如：

Region A ─┐Region B ─┼─→ Batch Job → Global LeaderboardRegion C ─┘

每分钟、每五分钟甚至每小时运行一次。

优点非常明显：

• 实现简单
• 数据逻辑容易理解
• 故障恢复简单
• 运维成本低

缺点也明显：

• 榜单存在固定延迟
• 计算窗口内排名不会更新

但如果排行榜只用于：

• 每日榜
• 周榜
• 赛季榜
• 奖励结算

那么这种方案可能已经足够。

很多系统的问题，恰恰来自于本来只需要“分钟级正确”，却设计成了“秒级全球一致”。

方案二：事件流实时合并

如果产品希望全球榜几秒内更新，可以让每个 Region 把积分变化写入事件流。

Region A ─→ Event Stream ─┐Region B ─→ Event Stream ─┼─→ Global ProcessorRegion C ─→ Event Stream ─┘

消费者持续更新全局排名状态。

这种方案的优势是：

Merge Window 可以压缩到秒级。

但真正复杂的地方也随之出现。

第一类问题：重复事件

消息系统通常不会天然保证“业务上的 Exactly Once”。

同一条积分更新可能被消费多次。

所以排行榜更新必须具备幂等性。

第二类问题：乱序事件

例如同一个玩家连续完成两局比赛：

Version 101 → 2500 分Version 102 → 2600 分

但跨 Region 网络并不能保证消费者一定先收到 101，再收到 102。

实际可能变成：

先收到 102再收到 101

如果消费者只根据“最后收到的事件”覆盖数据，玩家积分就会从 2600 错误回退到 2500。

所以事件必须携带一个可以比较的新旧版本。

例如：

player_idscorescore_version

服务端只接受：

incoming_version > current_version

的更新。

这里尤其要注意：

不要依赖客户端时间戳作为全局顺序依据。

客户端时钟无法信任，不同 Region 的服务器时钟也不能简单等同于严格全序。

更稳妥的办法，是让权威比赛服务生成：

• 单玩家递增版本号
• 数据库 revision
• 逻辑时钟
• HLC（Hybrid Logical Clock）

对于排行榜来说，大多数情况下根本不需要构造“全球所有事件的严格全序”。

只需要解决：

同一个玩家的多个状态，哪个更新更新。

这会让问题简单很多。

方案三：局部实时，全局延迟

这是实践中非常值得考虑的一种设计。

玩家所在 Region 的榜单实时更新。

全球榜允许延迟。

例如：

区域排名：实时全球排名：10 秒更新一次赛季最终排名：结算时强校验

这其实把三个不同业务需求拆开了：

• 游戏反馈需要实时
• 全球展示只需要近实时
• 奖励结算必须准确

一旦拆开，架构复杂度会明显下降。

这也是排行榜设计中一个非常重要的原则：

不要让“展示一致性”和“结算一致性”共享同一个 SLA。

五、排行榜系统最容易犯的错误：为了 Top 100，维护整个全球有序集合

假设全球有一亿玩家。

用户打开排行榜时，真正会看到多少人？

通常只有：

Top 100Top 1000自己附近 ±20 名

绝大多数用户永远不会浏览第 5,000 万名。

这意味着一个很重要的优化方向：

用户需要的通常不是完整排序，而是局部有序结果。

因此系统完全可以把需求拆成：

Top N Ranking+Player Rank Query+Nearby Players Query

例如：

• Top 100 常驻内存；
• Top 10000 放 Redis；
• 普通玩家只保存 score；
• 查询个人名次时通过分桶、分位索引或离线结构估算/计算。

这比维护一个包含一亿玩家的实时全局 Sorted Set，更符合真实访问模式。

架构设计最危险的一种思维，就是看到“排行榜”三个字，就默认：

所有数据都必须始终保持完整有序。

其实未必。

六、真正需要强一致的，通常不是排行榜，而是结算

这是全球排行榜里非常容易被忽略的一点。

用户看到的排行榜，可以允许几秒延迟。

但是：

奖励发放不能错。

例如赛季结束：

第 1 名：10000 美元第 2 名：5000 美元第 3 名：2000 美元

这时候系统不能再说：

“因为数据最终一致，所以排名可能回跳。”

展示阶段允许 Eventually Consistent。

结算阶段必须进入另一个状态。

一个更合理的设计通常是：

正常比赛阶段     ↓近实时排行榜     ↓赛季截止     ↓冻结积分     ↓等待同步完成     ↓生成全局快照     ↓校验     ↓发布最终榜单     ↓发放奖励

也就是说：

实时榜和最终榜，本来就应该是两个概念。

实时榜强调体验。

最终榜强调正确性。

如果把这两个需求强行做成同一个系统，复杂度会急剧上升。

七、不同方案，到底牺牲了什么

架构没有免费的午餐。

每一种排行榜方案，都在主动牺牲某些东西。

强一致全球榜

获得：

• 排名语义最简单
• 所有 Region 看见相同结果

牺牲：

• 写入延迟
• 故障时可用性
• 跨 Region 网络成本
• 系统复杂度

适合：

• 电竞比赛
• 金融奖励
• 强监管结算

异步全球榜

获得：

• 本地写入快
• 系统吞吐高
• Region 故障隔离更好

牺牲：

• 秒级绝对准确
• 排名可能回跳

适合：

• 普通竞技游戏
• 社交排行榜
• 活动榜

只做 Region 榜

获得：

• 最简单
• 最稳定
• 延迟最低

牺牲：

• 全球竞争感

适合：

• 区域服游戏
• MMO 分服
• 休闲游戏

局部实时 + 最终结算

获得：

• 用户体验和系统复杂度之间更好的平衡
• 结算正确性

牺牲：

• 实时榜不是绝对最终结果

而这恰恰是很多大型排行榜系统最现实的选择。

八、架构评审时，我会先问这 6 个问题

如果让我评审一个全球排行榜方案，我不会先问：

“Redis 用几台？”

我会先问下面这些问题。

1. 用户要的是“实时排名”，还是“最终名次”？

这是两个完全不同的需求。

实时排名强调：

Latency

最终名次强调：

Correctness

不要混在一起。

2. 全球榜允许延迟多久？

请给出数字。

不要说：

“尽量实时。”

而应该说：

P99 5 秒内完成全球同步

或者：

全球榜最多延迟 1 分钟

只有数字才能变成架构。

3. 排名允许回跳吗？

如果允许，UI 是否要提示：

数据同步中

或者：

全球榜更新时间：3 秒前

很多一致性问题，其实可以通过产品语义降低用户困惑。

4. 匹配系统是否依赖这个排行榜？

这是一个非常关键的问题。

很多系统错误地让：

Leaderboard

同时承担：

Matchmaking Rating

实际上两者并不应该强耦合。

排行榜可以延迟。

匹配分可能需要更实时、更稳定的状态。

如果二者耦合，一致性要求会被无谓放大。

5. Region 离线时怎么办？

假设欧洲 Region 断网十分钟。

全球榜应该：

• 暂停更新？
• 使用最后一次快照？
• 显示数据不完整？
• 暂时隐藏全球榜？
• 继续更新但标记部分 Region 延迟？

这不是事故发生之后再决定的问题。

而应该提前写进降级策略。

6. 最终结算如何保证正确？

需要明确：

• 截止时间
• 数据冻结策略
• 延迟事件处理
• 重复事件处理
• 快照版本
• 排名校验
• 奖励幂等

排行榜真正最不能错的地方，往往不是“玩家此刻看到第几”。

而是：

系统最终给谁发了奖励。

九、一个更现实的演进路径

全球排行榜不应该一开始就设计成全球强一致系统。

更合理的方式，是随着业务需求逐步增加复杂度。

第一阶段：单 Region

Client   ↓API   ↓Redis / Database

先把最基本的：

• 写入
• Top N
• 玩家排名
• 附近排名

做好。

这个阶段不要解决全球问题。

因为你可能根本没有全球用户。

第二阶段：多 Region 独立排行榜

Asia LeaderboardEurope LeaderboardUS Leaderboard

每个 Region 独立运行。

需要全球榜时，每隔几分钟做一次汇总。

这时候系统已经可以支持全球业务。

第三阶段：事件驱动全球榜

当产品开始要求：

全球排名必须几秒内更新。

再引入：

Region Event    ↓Message Stream    ↓Global Ranking Processor

将 Merge Window 压缩到秒级。

第四阶段：结算快照

如果排行榜开始关联：

• 现金奖励
• 电竞资格
• 高价值虚拟资产

再增加：

Freeze→ Drain Events→ Global Snapshot→ Audit→ Settlement

此时系统才真正拥有“最终排名”。

第五阶段：只有业务真的要求，才考虑全球强一致

如果业务真的要求：

全球任何地方更新积分后，所有玩家必须立即看到完全一致的排名。

那么你才需要认真考虑：

• 跨 Region 共识
• Global Coordinator
• NewSQL
• 数据主 Region
• 更高的延迟预算

但必须非常清楚：

这不是一次技术升级，而是一次业务成本升级。

十、结语：全球排行榜，其实是一道产品选择题

全球排行榜没有唯一正确答案。

它真正的问题不是：

“怎么实现全球排序？”

而是：

什么数据必须立刻正确？

什么数据可以稍后正确？

什么数据只有结算时必须绝对正确？

一个休闲游戏为了全球排行榜做跨洲强一致，是过度设计。

一个涉及现金奖励的电竞比赛，用最终一致榜直接发奖，则是架构事故。

真正成熟的设计，不是追求“最强的一致性”。

而是把一致性花在真正值得的地方。

本地反馈要快。

全球展示可以近实时。

最终结算必须准确。

当这三句话被业务、产品和技术共同接受之后，全球排行榜最难的一半，其实已经解决了。