Sentinel 主从切换让 Redis 锁瞬间蒸发：异步复制下分布式锁失效的根因与 fencing 兜底

结论先行：SET key val NX 拿到锁这件事，本身不携带任何持久性保证。在 Redis Sentinel / 主从架构里，锁是写在单机主库上的一条普通 key，靠异步复制传给从库——主库在复制确认前宕机，这条锁就会从整个集群里"蒸发"，而你以为自己还握着它。我 3 年里见过两次"锁看着在、副作用却跑了两遍"的事故，根因都不是 TTL 太短、也不是看门狗没配，而是锁的载体在故障切换里被换掉了。这篇文章把这条链路的机制讲透，并给一套不依赖"锁一定可靠"的兜底写法。

一、现象：一个"只跑一次"的补偿任务，打款跑了两遍

去年我们上一套日终对账补偿任务：扫描对不平的订单，逐笔触发补款。链路是 6 实例（4C8G，JDK 17），Redis 是 7.0.11 的 1 主 2 从 + 3 Sentinel（down-after-milliseconds=5000，parallel-syncs=1），加锁用的是最经典的写法：

SET comp:lock:recon:2025-09-14 <instance-uuid> NX PX 30000

事故那天，主库正在回源一批历史订单（单实例内存从 3.1G 涨到 5.8G），恰好一次 GC + 一次跨机房网络抖动叠加，主库在补偿任务拿到锁后 180ms 处被 Sentinel 判 down。从库被提升为新主，补偿任务继续跑——但新主上没有那条锁 key（那 180ms 内的写还没复制过去）。于是另一个本来"抢锁失败、正在重试"的实例，在新主上 SET NX 直接成功，两个实例同时在做同一批补款。当天对不平的 2.3 万笔订单里，有 11,437 笔被补款流水重复落库，财务对账单拉出来一片红。

更迷惑的是：两个实例的日志里都显示"我成功拿到锁了"，SET NX 都返回了 OK。指标侧 CPU 71%、used_memory 离上限还有余量，慢日志干净——又是一次"监控全绿、业务翻车"，这是典型的并发正确性问题，不是性能问题。

二、根因：锁的"确认"是单机语义，异步复制不给它任何持久性

把机制拆开看，问题出在三层的错位：

1. SET NX 的确认 = 单机内存写成功。它返回 OK 只代表"这条 key 写进了当前这台主库的内存"。它不是 2PC、不是 quorum 提交，不要求任何从库确认。
2. 主从是异步复制。Redis 默认 repl-diskless-sync + 写后异步推送给从库，主库不等待从库 ACK 就返回客户端。这意味着"我拿到锁"和"这条锁在集群里安全"之间，存在一个复制延迟窗口。
3. Sentinel 的故障切换 = 换掉锁的载体。down-after-milliseconds=5000 触发后，从库被 SLAVEOF NO ONE 提升为主。如果宕机的主库有未复制的写（包括那条锁），新主的状态是"锁不存在"。旧的持锁方毫不知情，继续拿着"已经不存在于任何节点"的锁往下执行副作用。

一句话根因：你把"互斥"建立在了一条没有持久性、且载体随时会被替换的单机 key 上。TTL 和看门狗解决的是"持锁方卡死/崩溃"，根本解决不了"锁载体本身被换掉"这件事——这是很多人以为配了看门狗就万事大吉的地方，也是最大的误区。

三、具体做法：不要赌锁可靠，给副作用加一道"单调守卫"

分三层，越往下越接近真正的防线：

1) 提高锁的持久性下限（治标，但便宜）

让"拿锁"至少落到一个从库，缩小蒸发窗口：

# redis.conf（主 + 从都配）
min-replicas-to-write 1
min-replicas-max-lag 10

min-replicas-to-write 1 让主库在没有健康从库时拒绝写，那条 SET NX 就会失败而不是"写进即将消失的单机"。注意它只缩小窗口，不消除——两个主库短暂并存（脑裂）时它帮不上忙。

2) 换用基于 quorum 的协调服务（治本，但要懂它的边界）

把锁从 Redis 挪到 etcd / ZooKeeper 这类 ZAB/Raft 提交即"多数派确认"的存储上，锁的提交天然带持久性。但仍然不是万能的：Stewart（2011）的 fencing token 论文说得很清楚——即使锁是 quorum 提交的，持锁进程可能在"提交之后、执行副作用之前"被 GC 暂停或网络分区，等它恢复时 epoch 已经落后，它仍可能用旧 token 写脏数据。所以光换存储不够。

3) 最后一道闸：让数据侧自己拒绝"过期意图"（真正兜底）

这是安全加固视角的核心——不信任锁，信任数据里的单调状态。每次拿锁都带一个单调递增的 epoch（etcd 的 revision / ZK 的 zxid / 自己维护的 fence 计数），副作用写时把它当守卫条件：

-- 补款流水：只允许"epoch 更大"的写入通过，旧 epoch 一律挡下
INSERT INTO pay_comp_flow (order_id, epoch, amount, created_at)
VALUES (?, ?, ?, NOW())
ON DUPLICATE KEY UPDATE
    epoch    = IF(VALUES(epoch) > epoch, VALUES(epoch), epoch),
    amount   = IF(VALUES(epoch) > epoch, VALUES(amount), amount);

-- 关键：用 affected rows + epoch 比较判定"我是否真的赢了这一轮"

Java 侧把 epoch 当一等公民传进来，并断言"只有 epoch 单调递增的写才生效"。这样即使锁蒸发了、第二个实例真的拿到了锁，它带的 epoch 不会比在途的那个更小——数据侧的守卫会替你把"过期意图"挡在落库之前。 锁退化成"加速互斥"，正确性由数据守卫兜底。

四、踩过的坑 & 反直觉之处

1. SET NX 返回 OK ≠ 你"安全地"持有锁。 它只是单机内存写成功的回执，不携带任何复制/持久性承诺。两个实例日志都写"我拿到锁了"，是完全可以同时为真的。
2. 看门狗/续期解决不了"锁载体被换掉"。 看门狗防的是"持锁方卡死导致锁超时"，而 failover 是"锁跟着主库一起没了"，这俩是不同的失效模式，别混为一谈。
3. min-replicas-to-write 不是锁的解决方案。 它只保写入持久性，脑裂（两主并存）时它无能为力；真正的兜底永远是 fencing/epoch 守卫。
4. 换成 etcd/ZK 之后最容易放松警惕。 很多人以为"上了 quorum 存储就安全了"，忘了 fencing token 论文里那个"提交后、执行前被暂停"的窗口——DB 侧的单调守卫才是最后一道闸，不能省。
5. 验证方法要对得上失效模式。 我们压测时只测了"持锁方 kill -9"（看门狗场景，全绿），漏了"主动 SHUTDOWN 主库 + 立刻触发 failover"这条路径——后者才是这次事故的复现方式。上线前用 redis-cli SHUTDOWN NOSAVE 强杀主库、观察新主上锁是否还在，是这类问题唯一能提前暴露的压测动作。

五、结论 & 可复用清单

• 根因一句话：Redis 锁是单机 key + 异步复制，SET NX 的确认不带持久性；Sentinel failover 会换掉锁的载体，未复制的锁直接蒸发。
• 可复用清单：
  1. 主从架构下，任何"拿锁即执行副作用"的逻辑，默认锁可能丢，必须给副作用加单调守卫（epoch/fence token + affected rows 判定）。
  2. 主从都配 min-replicas-to-write 1 / min-replicas-max-lag 10，缩小蒸发窗口（治标）。
  3. 强一致性场景优先 etcd/ZK，但仍要保留数据侧守卫（治本 + 兜底）。
  4. 压测要把"主库 SHUTDOWN + failover"列为必测路径，不能只测"持锁方 kill -9"。
  5. 对账/补款/扣减这类有真实资金或库存副作用的写，正确性断言靠"并发 + 故障切换压测 + 数据侧守卫"三件套，不靠监控。

一句话收尾：锁是优化，不是正确性——把"只有我持有锁"当正确性前提，就是在赌一个单机内存写的持久性，而分布式系统从不欠你这份承诺。