Redis ZSET排行榜位置原子交换：高并发下的锁粒度与Lua脚本实战

游戏后端最容易被低估的需求，就是匹配服排行榜。它不仅仅是给玩家看的一张表，而是匹配算法实时依赖的数据源。今天我想复盘一个具体的设计：排行榜位置原子交换，以及为了支撑高并发交换，锁粒度到底怎么定。这个题目听起来有点绕，但背后是无数线上事故换来的经验，尤其是当同一秒内几百场对局同时结束、几十个玩家分数同时跳动的时候，一个不小心就会踩出线上事故。

先说明一点，这篇文章默认你已经知道 Redis 的 ZSET 大概是什么，至少知道它是按 score 排序的有序集合。如果你还没用过，没关系，我会把排行相关的结构讲清楚。本文的核心场景放在匹配服，但思路同样适用于任何需要高频更新名次、且要有严格一致性的业务排行榜，比如活动实时榜、赛季积分榜、榜单运营位等。

1. 从业务场景说起：匹配服排行榜到底特殊在哪

1.1 普通榜和匹配服榜是两种生物

先聊聊普通排行榜。你看很多技术社区、数据平台发布的“编程语言排行榜”或者“游戏销量榜”，这类榜单有一个共同点：更新频率极低，可能一天、一周甚至一个月才变动一次。这类排行榜用缓存加定时任务刷一刷就完了，性能完全不敏感，即便漏掉一次更新也没人会在意。

匹配服排行榜完全不是一回事。匹配服每天承载多少场对局？一个中型在线竞技游戏，日活几十万，一天下来轻轻松松上万场甚至几十万场。每一场 5v5 对局结束后，双方十个人的匹配分（一般叫 MMR 或者 ELO）都要重新计算，这十个分数落入排行榜后，排名会瞬间发生多点变化。也就是说，匹配服的排行榜是一个“写多读也多”的高频动态榜，不是那种可以慢慢算的离线榜。

这带来两个直接后果。第一，排行榜更新必须在毫秒级完成，否则匹配流程会被拖慢。第二，所有玩家分数变化必须是可预期的，A 从第 5 名掉到第 8 名，B 从第 9 名升到第 5 名，这个结果必须精准反映到后续的读取和匹配计算中。如果中间出现“A 在第 5 名和第 8 名之间反复横跳”的中间态，匹配算法读到脏数据，就可能把两个实力差距很大的玩家放进同一个比赛池，那玩家体验就直接崩了。

1.2 位置交换从哪里来：几个典型触发场景

你可能会问，排行榜名次变化不都是分数变化带来的吗，分数变了排名自然变，为什么还要单独设计“位置交换”？

我刚开始做这个功能时也这么想，后来发现匹配服里存在不少“分数不变但名次需要互换”的真实场景，下面这些是我实际遇到过的：

• 玩家申诉与积分回滚。系统误判玩家违规，扣了分，后来申诉成功，分数要恢复。这时候玩家往往已经掉到了某个名次，而恢复分数后他要“回到”原来的位置，这本质上是和当前名次靠前的玩家交换位置。
• 处罚后的名次调整。一个前十名玩家被查出作弊，分数清空或者冻结，后一名顺位补上，这也是一种隐式交换。如果清分和补位不是同时完成，就会出现某个名次短暂空缺或者两个人同时显示为同一名的怪象。
• 运营活动的换座机制。有些赛季活动允许榜单前列玩家使用“换座卡”，和指定名次的玩家互换展示位。这种玩法听起来很简单，但并发请求下极容易出问题，因为没有分数变化，纯粹是位置交换，要额外处理。
• 跨赛季段位继承。新赛季开启时，玩家分数按比例压缩，分数压缩后临界点附近的名次也会发生大范围重排，其中很大一部分就是两个或多个玩家之间的位置对调。

可以看到，位置交换是一个被业务逼出来的独立需求，不是分数变更的附属品。它和分数变更的最大区别在于：交换发生时，两个玩家的 score 都可能不变或变，但最终效果是名次互换，而所有观察者都必须在任意时刻看到一致的名次序列。

1.3 设计目标：先想清楚“不能错到哪里”

做技术设计，第一步不是画架构图，而是定义“错了会发生什么”。位置交换如果坏了，最轻微的表现是排行榜显示抖了一下，重一点的表现是匹配算法读到错误名次，把实力不对等的玩家分到一起，最严重的表现是数据永久不一致，玩家分数和名次对不上，客服被投诉淹没。

所以我把这个功能的设计目标定成了三条：

1. 原子性：一次交换要么完全生效，要么完全不生效，不存在中间状态。
2. 实时性：交换完成后，后续任意一次读操作都能立刻看到新排名。
3. 高并发安全：多个交换请求并发执行时，不能互相踩踏，不能丢更新。

目标定清楚之后，再来定技术方案就顺多了。

2. 原子交换的核心问题：为什么两条 update 会打架

2.1 并发场景下的经典事故重演

先还原一个很多团队都踩过的坑。假设排行榜数据放在 MySQL 里，表结构非常简单：player_id、score、rank。交换 A 和 B 的位置，很自然的写法是这样的：

UPDATE leaderboard SET rank = 2 WHERE player_id = 'A'; UPDATE leaderboard SET rank = 1 WHERE player_id = 'B';

第一眼看上去没问题，对吧？但你想一下并发场景。假设这时候 C 也同时发起交换，要把 A 从第 2 名换到第 5 名。三条 SQL 在数据库里的执行顺序完全不可控，一旦交错，结果可能变成 A 的 rank 被改成 2，又被改成 5，而 B 还停留在 2，数据库里出现两个 rank=2 的玩家。这就是典型的非原子操作导致的并发事故。

有人会说，加事务不就行了？确实，用事务包住这两条 SQL，能保证它们要么都成功，要么都失败。但事务只能解决“同一时间点的一致性”，解决不了“并发事务之间的隔离”。两个事务同时读到了相同的旧值，各自执行更新，后提交的就会覆盖先提交的，这需要引入行锁或者乐观锁才能解决。

2.2 数据库悲观锁和乐观锁的初步思路

先看悲观锁。选 A 和 B 两行，在事务里SELECT ... FOR UPDATE，把这两行锁住，再执行更新。这个方案在数据量小、并发量低的场景下完全可行，问题在于匹配服的高并发场景下，每一场对局结束都有十个玩家分数在变，加上位置交换，锁竞争会非常集中。尤其当热门玩家频繁处于排行榜前列时，所有人都在抢那几行记录，数据库会变成瓶颈，事务等待超时很快就会出现。

再看乐观锁。给排行榜表加一个version字段，更新时带上版本号判断，UPDATE ... WHERE player_id='A' AND version=10，更新成功则说明没有冲突，失败则重试。这种思路适合读多写少的场景，但匹配服排行榜的写频率非常高，大量更新的重试率会让人崩溃。而且位置交换涉及两行记录，版本号必须成对判断，如果 A 的版本没变但 B 的版本变了，重试逻辑要更复杂地协调。

我不否认数据库方案在某些场景下的价值，但针对匹配服排行榜这种吞吐量要求，大多数团队最后都会把目光放到 Redis 的 ZSET 上。

2.3 Redis ZSET 上的原子交换：基础结构

Redis 的 ZSET（有序集合）是排行榜场景的经典数据结构。每个成员（member）关联一个分数（score），Redis 内部按 score 排序，score 相同时再按 member 的字典序排序。排行榜排名查询用ZREVRANGE（从高到低）或者ZRANGE（从低到高），取指定区间成员，性能非常稳定。

如果我们把玩家的匹配分直接作为 score 存进 ZSET，那“交换位置”在数据层面到底意味着什么？举个例子，当前 A 的 score 是 1500，排第 1；B 的 score 是 1480，排第 2。要让 A 和 B 的位置互换，最直接的做法是：

• 把 A 的 score 变成 1480
• 把 B 的 score 变成 1500

这样 A 掉到第 2，B 升到第 1。也就是说，交换位置本质上就是交换两个人的 score 值。可用 ZSET 做交换，必然面临两个问题：第一，两步操作都得原子完成；第二，交换后的 score 会不会和别人产生新的并列，影响后续排名。

Redis 官方提供了一个原子执行脚本的机制，通过执行 Lua 脚本来保证一段逻辑在 Redis 内部串行完成。换句话说，Lua 脚本天然规避了“两条 update 打架”的问题。我们后面专门讲脚本本身是怎么写的，这里先记住一个结论：在 Redis 里做位置交换，优先选 Lua 脚本，不要自己在应用层写两步更新。

3. 锁粒度设计权衡：全局锁、分段锁与无锁

3.1 全局锁最省事，也最容易瓶颈

先聊最容易想到的方案：给整个排行榜的交换操作加一把全局锁。不管是 JVM 内部的synchronized还是分布式锁，只要保证同一时刻只有一个交换请求在执行，就不会有并发踩踏的问题了。

我见过一些团队最开始确实这么做，实现起来非常快，几行代码就完事。但压测跑起来问题就出来了：所有交换请求都被串行化，吞吐量非常难看。我实测过一个 MySQL 表结构下的全局锁方案，TPS 大概只能到两三百，超过这个量，锁等待时间就会把请求超时率拉到不可接受的水平。

更麻烦的是，全局锁保护的粒度太大，连不相关的玩家交换也被迫排队。比如一个在 1000 名的交换请求，和一个在第 2 名的交换请求，它们明明没有任何交集，却要互相等待。这种无意义的等待在匹配服场景下尤其浪费，因为排行榜越高频更新，请求互相“堵门”的概率就越大。

3.2 分段锁的拆分思路与死锁风险

既然全局锁粒度太粗，很自然的想法就是拆细。比如按排名区间拆成多个锁：第 1 到 1000 名一把锁，第 1001 到 5000 名一把锁，第 5001 到 20000 名一把锁，以此类推。交换操作只锁自己涉及的区间，不同区间的交换请求互不干扰。

这个方案看起来很美，但有一个绕不开的问题：跨区间交换怎么办？A 在第 900 名，B 在第 1200 名，交换位置时，A 要去第 1200 名，B 要去第 900 名，那这两个玩家实际上跨越了两个锁区间。此时你必须同时持有两把锁，而且要注意加锁顺序，否则就可能死锁。

经典的死锁场景是：请求 1 想交换 A（第 900 名）和 B（第 1200 名），先锁住了小区间，再等大区间；请求 2 同时想交换 C（第 1200 名）和 D（第 900 名），先锁住了大区间，再等小区间。两个请求互相等待对方释放锁，谁也执行不下去。要避免死锁，最简单的办法是规定一致的加锁顺序，比如永远先锁排名靠前的区间，再锁排名靠后的区间。但这么一来，跨区间的交换操作实际上又把多个分段耦合在了一起，实现复杂度明显上升。

如果你只有单机应用，分段锁还有意义。但在匹配服这种通常多节点部署的微服务架构里，应用内部的分段锁只能保证本节点内的并发安全，跨节点还是要依赖分布式锁，复杂度又上一层。

3.3 基于 Redis Lua 的脚本级原子性

聊到这里，你可能已经预感到了：如果 Redis 自己就能保证一串命令的原子性，为什么还要在应用层费劲加锁？

对，这就是 Lua 脚本方案的核心优势。Redis 从 2.6 版本开始支持执行 Lua 脚本，脚本运行期间，其他客户端的任何命令都不会插入执行。也就是说，脚本里的所有读写操作天然形成了一个隔离级别最高的“临界区”，不需要你在外部再加任何锁。这个特性太适合排行榜交换了。

用 Lua 脚本完成一次交换，整个过程在 Redis 内部是串行执行的，外部观察者不可能看到“A 已经改了但 B 还没改”的中间态。相比全局锁，Lua 方案没有额外的锁等待，Redis 单线程模型下的命令处理本身就是顺序的；相比分段锁，Lua 方案不需要考虑跨区间加锁顺序，也不用担心死锁。只要你的 Redis 实例能扛住整体读写压力，交换操作本身的并发上限会比所有“应用层加锁”方案高一个数量级。

当然，Lua 脚本不是银弹。它最大的限制是集群模式下要求脚本涉及的 key 必须在同一个 hash slot 里，否则会报 CROSSSLOT 错误。这个问题我会在后面的常见问题部分展开说。另一个限制是，应用层如果还需要保证“同一个玩家同时只能发起一次交换”这种业务级别的约束，单靠 Lua 脚本是不够的，因为脚本只管数据层操作，管不了业务请求的重复提交。

3.4 四种方案对照：怎么选，看匹配服的规模

这里我把全局锁、分段锁、数据库乐观锁、Redis Lua 脚本四种方案放在一起做一个直观对照。这些数据不是实验室指标，是我在某个具体项目压测时得到的大致量级，不同硬件和网络环境下会有浮动，但相对关系是稳定的。

我自己在实际项目中最终选用的是 Redis Lua 脚本方案，原因很直接：匹配服的并发峰值远高于分段锁能支撑的量级，而 Lua 脚本把“原子性”从应用层下沉到了 Redis 内部，实现代码最少，性能和一致性反而最好。

4. 完整落地实现：数据结构、Lua 脚本与调用链路

4.1 数据模型与 key 设计

在设计实现之前，先想清楚排行榜数据放在 Redis 里怎么组织。我的做法是直接用 ZSET，key 形如match:rank:global，每个玩家是一个 member，score 就是匹配分。这里有一点需要注意：ZSET 的 score 是双精度浮点数，如果用整数匹配分，几万玩家、几百个并列分数是完全正常的，但 Redis 在 score 相同的情况下会按照 member 的字典序排序，这可能导致同分玩家的排名和你预期不一致。

针对这个痛点，业界常用的一个做法是“分数扩展法”。把实际匹配分乘以一个大数，再加上一个微小的排序因子，例如设定 score = 匹配分 * 10000 + (一个固定值 - 玩家等级/段位修正)，让同分玩家也能有一个确定的先后顺序。不过交换位置时如果分数里带了这种修正位，需要谨慎处理，否则交换后可能出现 score 精度误差。我的选择是：玩家匹配分本身保留一位小数，交换时完全不碰排序因子，让 ZSET 的自然排序来展示名次。

除了 ZSET，我还会为每个玩家保存一个简单的玩家信息 Hash，key 为match:player:{playerId}，里面存当前分数、段位、最后更新时间等。这样交换脚本执行时，除了改 ZSET，还能顺带把玩家 Hash 里的分数同步更新，避免后续读玩家信息时出现“分数和排名不一致”的情况。

4.2 交换脚本逐行解析

直接上一个核心的 Lua 交换脚本。这个脚本我拆成基础版和带版本号的升级版，先说基础版：

-- KEYS[1]: 排行榜 ZSET 的 key -- ARGV[1]: 玩家A -- ARGV[2]: 玩家B local scoreA = redis.call('zscore', KEYS[1], ARGV[1]) local scoreB = redis.call('zscore', KEYS[1], ARGV[2]) if not scoreA or not scoreB then return { err = 'player not found' } end -- 先把B设置为A的旧分数，再把A设置为B的旧分数 redis.call('zadd', KEYS[1], scoreA, ARGV[2]) redis.call('zadd', KEYS[1], scoreB, ARGV[1]) return { scoreA, scoreB }

这段脚本逻辑非常简单，但有几个容易被忽略的点。

第一，为什么先更新 B 再更新 A？在 Lua 脚本内部这其实是无所谓的，因为脚本运行期间其他命令进不来，外部看不到中间状态。但我建议先更新排名靠后的玩家，再更新排名靠前的玩家，这样即使在日志审计里，每一步都更符合直觉。

第二，zscore查询时，如果玩家并不在排行榜里（比如新玩家或者已经被清理出榜），脚本会返回false，此时必须终止交换，否则会误把新玩家插入排行榜。上面的脚本用not scoreA做了判断。

第三，zadd默认是如果 member 不存在就插入，存在就更新。交换场景下两个玩家必须都在榜内，所以前面的存在性判断极其关键。如果想把防御做深一点，zadd命令还可以带上XX选项，表示只在 member 存在时才更新，进一步防止意外插入新成员。

我再给一个带版本号的升级版脚本。假设我们在 ZSET 之外，还用match:player:{playerId}这个 Hash 保存了玩家的版本号，每次交换前都要求双方版本号匹配，交换成功后版本号自增。这样可以防止两个交换请求在极端时序下互相覆盖：

-- KEYS[1]: 排行榜 ZSET 的 key -- KEYS[2]: 玩家A的Hash key -- KEYS[3]: 玩家B的Hash key -- ARGV[1]: 玩家A -- ARGV[2]: 玩家B -- ARGV[3]: 期望的玩家A版本号 -- ARGV[4]: 期望的玩家B版本号 local currentVA = redis.call('hget', KEYS[2], 'version') local currentVB = redis.call('hget', KEYS[3], 'version') if not currentVA or not currentVB then return { err = 'player not found' } end if tonumber(currentVA) ~= tonumber(ARGV[3]) or tonumber(currentVB) ~= tonumber(ARGV[4]) then return { err = 'version conflict' } end local scoreA = redis.call('zscore', KEYS[1], ARGV[1]) local scoreB = redis.call('zscore', KEYS[1], ARGV[2]) redis.call('zadd', KEYS[1], scoreA, ARGV[2]) redis.call('zadd', KEYS[1], scoreB, ARGV[1]) redis.call('hincrby', KEYS[2], 'version', 1) redis.call('hincrby', KEYS[3], 'version', 1) return { ok = 'done' }

这个升级版的思路类似乐观锁，但把“检查版本”和“执行交换”合并到了一个 Lua 脚本里，中间不会插入其他命令，所以并发冲突的概率进一步降低。实践中我会把“一次交换请求”作为整体处理，同一玩家同一时间只允许一个请求进入，防止重复操作。

4.3 服务端调用与并发控制

Redis 这边准备好脚本后，Java 服务端的调用就很简单了。我用 Jedis 客户端举例：

String luaScript = "local scoreA = redis.call('zscore', KEYS[1], ARGV[1]) ..."; List<String> keys = Collections.singletonList("match:rank:global"); List<String> args = Arrays.asList(playerAId, playerBId); try (Jedis jedis = jedisPool.getResource()) { Object result = jedis.eval(luaScript, keys, args); // 解析 result，如果是错误信息则走异常分支 }

这里有几个细节值得注意。第一，Lua 脚本字符串最好在服务启动时预加载到 Redis，通过SCRIPT LOAD拿到 sha，后续用EVALSHA执行，这样可以避免每次请求都传一遍脚本内容，节省网络带宽。第二，eval调用本身是同步阻塞的，如果 Redis 压力很大，调用超时会影响服务线程，建议设置合理的 socket 超时时间，同时给 Redis 配置监控告警。

服务端层面，我会用一个简单的“进行中交换集合”来防止同一个玩家同时发起多个交换。这个集合可以放在本地内存，也可以用 Redis 的 Set 结构。比如一个交换请求进来时，先把两个玩家 ID 插入match:exchanging，如果插入时发现已经有玩家在集合里，直接拒绝当前请求。交换完成后再从集合里移除。这个操作配合 Lua 脚本，能做到应用层“去重”和数据层“原子”双保险。

4.4 压测数据与容量预估

方案落地后，一定要压测，不然不知道极限在哪。我的压测环境是三台应用节点、一台 Redis 主节点，模拟请求是随机抽取两个上榜玩家进行位置交换。跑出来的数据大概是这样：

为什么 Lua 脚本方案平均耗时这么低？因为脚本在 Redis 内部执行，没有网络往返的多次通信，也没有应用层锁的等待。一次交换只需要一次EVALSHA调用，Redis 内部跑完两个 ZSET 的读写，然后返回结果。网络 IO 只有一轮，耗时自然低。

容量预估上，如果你们匹配服日活 50 万，高峰期每秒约 500 场对局结束，每场 10 人更新，那就是每秒 5000 次分数变更，再加上位置交换类操作，Redis 单实例 ZSET 完全可以扛住。但如果把这个量级再翻十倍，就需要考虑 Redis 集群和分片了，此时要注意 hash tag 的使用，保证同一个排行榜的 key 落在同一个 slot。

5. 常见问题与排查技巧实录

5.1 排行榜“抖动”：版本号与快照缓存

上线第一天，运营同事跑过来说排行榜在“抖”：玩家刷新页面时，看到的榜单顺序偶尔会闪一下，过一两秒又恢复正常。排查发现，页面读取走的是一个多级缓存，缓存里存的是排行榜快照，而交换请求直接更新了 Redis ZSET，导致缓存还没刷新时，用户读到的是过期数据，和最新 ZSET 做对比后看到名次跳变。

这个问题的根源不是交换逻辑出了问题，而是“读链路”和“写链路”没有统一。我后来给排行榜加了一个全局版本号，每次发生交换或者批量更新时，都把版本号自增一次。读链路先检查版本号，如果版本号变了，就重新拉取 ZSET 快照并更新缓存。这样用户看到的就是一次干净的从旧快照切换到新快照，而不是反复闪烁。

5.2 CROSSSLOT 报错：集群模式下的 key 规划

项目中后期流量增大，Redis 从单实例迁移到集群模式，第一个踩到的坑就是 Lua 脚本运行时报错：CROSSSLOT Keys in request don't hash to the same slot。

原因很简单：Redis Cluster 把 key 按照 hash slot 分布到不同节点，而 Lua 脚本执行时会校验所有涉及到的 key 是否在同一个 slot，否则拒绝执行。我涉及了match:rank:global和多个match:player:{playerId}，这些 key 默认情况下 hash slot 完全不同，脚本一执行就报错。

解决办法是使用 Redis 的 hash tag。把 key 改成match:rank:{global}和match:player:{global}:{playerId}，这样花括号里的global作为 hash tag，参与 slot 计算的只有global这一个字段，所有 key 都会落到同一个 slot。改造之后，脚本在集群模式下也能正常运行。这个坑非常典型，建议一开始就规划好 key 的命名规则。

5.3 死锁与超时：持锁时长与重试策略

虽然 Lua 脚本方案不需要应用层锁，但如果你还在用分段锁或者全局锁的老方案，就一定要关注死锁和超时。我们早期用过一段时间的分段锁，就发生过线上死锁导致交换接口大面积超时，排查日志才发现是两个跨区间的交换请求互相持有对方需要的锁。

后来我彻底切到 Lua 脚本后，这类问题没有再出现过。但我还是建议保留一层兜底：应用层给每个交换请求设定一个最长执行时间，比如 3 秒，超时后直接返回失败并记录告警。就算 Redis 卡顿，也不至于拖垮整个服务。

5.4 数据回源不一致：幂等与补偿

另一个容易被忽视的问题是排行榜数据回源。如果 Redis 数据因为故障被清理，需要从数据库恢复排行榜。恢复过程中，如果有交换请求已经落库但 Redis 里没有，就会导致恢复后数据不一致。

我的处理方式是在数据库记录每次交换操作的日志，包含一个唯一的交换请求 ID。回源时，把 Redis 重新构建成数据库里最新一次落库的状态，同时保证所有交换操作都是幂等的。这样即使某个请求被重复执行，也不会因为两次操作叠加而产生错误名次。

6. 写在最后：几点个人体会

这个功能做完之后，我最大的感受是：看似简单的“交换位置”，只要你把它放在一个高并发真实场景里，所有隐藏的复杂性都会浮出水面。最初用全局锁、后来改分段锁、最后落到 Redis Lua 脚本，这个演进路径本质上是在回答一个问题：到底在哪一层保证原子性最合适？

我的答案是把原子性尽量下沉到数据存储层内部，而不是在应用层靠锁去协调。Redis 单线程模型加上 Lua 脚本，天然就是为这类短小精悍的原子操作设计的，你非要绕开它去搞一堆分布式锁，反而容易制造更多复杂度。

另外还有一个体会是，设计排行榜交换时，一定不要把眼光只盯在“交换”本身。读链路的一致性、缓存刷新策略、集群模式下的 key 设计、应用的幂等控制，这些都是同一个问题的不同侧面。只解决数据层的原子交换，就像只修了一个车的发动机，其他零件晃动一样会翻车。

如果你后续也遇到类似场景，我建议从小处起步，先用 Lua 脚本把交换逻辑跑通，然后加上版本号和缓存刷新，最后根据压测数据决定要不要上集群。这个顺序能帮你用最小的复杂度拿到最稳的结果。