Redis 分布式锁的五个致命坑：从超卖事故到 Fencing Token 加固方案

一、现象：一把"看似安全"的锁，烧掉了 3 天库存

去年双 11 前压测，我们的秒杀服务用 Redis SETNX + EXPIRE 做了库存扣减的互斥锁。线上 10 秒内涌入 12 万 QPS，结果同一 SKU 被扣了 2 倍 库存，产生 4700 笔重复订单，资损约 23 万元。事后复盘发现：3 台应用节点中有 1 台因 Full GC 停顿 8 秒，锁的 EXPIRE 5 已经失效，另外 2 台节点各自拿到了"锁"，并发扣减同一行库存。

这不是个例。据我 5 年踩坑统计，分布式锁相关的线上事故中，超过 70% 源于"锁过期但业务未完成"和"误删他人锁"这两个根因。

二、原理：为什么 SETNX + EXPIRE 天生不安全

很多人写锁是这样的：

// ❌ 危险写法：两步非原子
if (redis.setnx(lockKey, "1")) {
    redis.expire(lockKey, 5); // 如果这里崩了，锁永不过期
}

问题有三层：

1. 非原子：SETNX 和 EXPIRE 是两条命令，中间宕机 → 死锁。
2. 无持有者标识：value 写死 "1"，任何客户端都能 DEL 别人的锁。
3. 无续期机制：业务执行超过 TTL 后，锁自动释放，但业务线程还在跑——这就是"锁丢失"（lock loss）。

更隐蔽的是 ZK 的 session timeout 同理：客户端到 ZK 的网络抖动 3s（默认 sessionTimeout），ZK 认为你死了，删掉 ephemeral node，你的锁就没了。

三、具体做法：五层加固

第 1 层：原子加锁 + 唯一 value

# Redis 7.x 推荐写法（一条命令，原子）
SET lock:order:SKU-8842 "uuid-7f3a-9c21" PX 30000 NX

• NX：只有 key 不存在才设置（等价 SETNX，但原子）。
• PX 30000：30 秒过期，毫秒精度，避免 EXPIRE 秒级粒度。
• value 用全局唯一 UUID，后续解锁时校验"是不是我的锁"。

第 2 层：Lua 脚本安全解锁

-- unlock.lua
if redis.call("GET", KEYS[1]) == ARGV[1] then
    return redis.call("DEL", KEYS[1])
else
    return 0
end

EVAL "if redis.call('GET',KEYS[1])==ARGV[1] then return redis.call('DEL',KEYS[1]) else return 0 end" 1 lock:order:SKU-8842 "uuid-7f3a-9c21"

关键：先 GET 再 DEL 必须是原子的，Lua 脚本在 Redis 单线程里执行，天然原子。

第 3 层：Watchdog 续期

参考 Redisson 的实现：起一个后台线程，每隔 TTL/3（10s）检查锁是否仍被自己持有，是则 PEXPIRE 续期；业务完成后主动停止续期。这样即使业务跑了 200s 也不会丢锁。

// 伪代码
ScheduledFuture<?> watchdog = scheduler.scheduleAtFixedRate(() -> {
    String val = redis.get(key);
    if (myUuid.equals(val)) {
        redis.pexpire(key, 30000); // 续期
    } else {
        watchdog.cancel(false);   // 锁已丢，停止续期并告警
    }
}, 0, 10, TimeUnit.SECONDS);

第 4 层：Fencing Token（防"僵尸持锁者"）

即使有了上面三层，仍有一种极端场景：节点 A 的 GC 暂停 35s，锁过期，节点 B 拿到锁并执行，然后 A 恢复后继续执行旧逻辑。此时 A 是"僵尸持锁者"。

Fencing Token 的解法：每次加锁成功时，从 DB 的单调递增序列表取一个 token：

UPDATE lock_fence SET token = token + 1 WHERE resource = 'SKU-8842'
-- 取出 token = 10081

执行写操作时带上 token 做 CAS：

UPDATE inventory SET stock = stock - 1, fence_token = 10081
WHERE sku_id = 'SKU-8842' AND fence_token < 10081

僵尸节点 A 恢复后拿的是 token 10080，SQL 条件不满足，写入被拒绝。这就是 Martin Kleppmann 在 Designing Data-Intensive Applications 里强调的：锁只能"降低"并发概率，真正的安全靠 fencing。

第 5 层：降级与告警

• 锁获取失败 → 进入本地队列异步重试（最多 3 次，间隔 200ms/500ms/1s）。
• 连续 5 次获取失败 → 触发 Prometheus 告警 + 自动切到 DB 行锁兜底。
• 监控指标：lock_wait_ms（P99 > 50ms 告警）、lock_loss_count（> 0 即 P1 告警）。

四、踩过的坑与反直觉

| # | 坑 | 现象 | |---|---|---| | 1 | EXPIRE 用秒级，业务恰好 4.9s 完成 | 锁在第 5s 被释放，下一个请求进来 → 并发。改用 PX 毫秒级 + TTL 至少覆盖 P99 耗时 × 3 | | 2 | 用 SET key val 然后 DEL（无 NX） | 两个实例同时"加锁成功"，互不互斥。必须 NX | | 3 | 以为主从切换后锁还在 | Redis 主从是异步复制，主节点写入锁后立刻宕机 → 从节点没有这把锁。单实例 Redis 锁天然有主从切换丢锁风险，生产建议用 ZK 或 etcd（CP 协议） | | 4 | RedLock 在 3 个独立 Redis 上取多数派 | 实际生产里 3 台 Redis 共用同一台物理机 → 机器宕机 = 3 把锁全丢，"多数派"形同虚设 | | 5 | 锁的 value 写 System.currentTimeMillis() | 两台机器时钟差 2s，value 相同 → 解锁时 A 删了 B 的锁。必须用 UUID |

五、结论与可复用清单

分布式锁不是"加上就安全"，它是一个多层防御体系。可复用清单：

• [ ] 加锁：SET key UUID PX <TTL> NX，TTL ≥ P99 业务耗时 × 3
• [ ] 解锁：Lua 脚本 GET == UUID 才 DEL
• [ ] 续期：Watchdog 每 TTL/3 续一次，丢失即告警
• [ ] 防僵尸：DB 层 Fencing Token CAS
• [ ] 降级：锁获取失败 → 本地队列 + DB 行锁兜底
• [ ] 监控：lock_wait_ms P99、lock_loss_count、Watchdog 续期失败率
• [ ] 选型：强一致场景用 etcd/ZK（CP），性能优先且可接受极小概率丢锁才用单 Redis（AP）

一句话总结：锁是"减速带"，fencing token 才是"安全气囊"。只装减速带，迟早翻车。