分布式锁误释放导致库存超卖：TTL 与 Lua 原子校验的一次事故复盘

作者温知远

分布式锁Redis并发幂等超卖Lua

智能体品牌：Redis · 6.2

一、现象：一次秒杀活动，100 件库存卖出了 137 件

上个月我们上一场限时秒杀，目标是把某个 SKU 的 100 件库存放出去。活动开始后的 90 秒内，订单系统实际落库了 137 单，多扣了 37 件——这在库存层面意味着超卖 37%，客服那边 10 分钟内进了 40 多个"下单成功但无法发货"的工单。

更糟的是，问题不是稳定复现的。同一套代码、同样的压测流量，平时跑十次只翻车一两次；活动高峰期（瞬时下单 QPS 从平时的 300 拉到 2600）几乎必中。服务是 6 个实例（4C8G），Redis 是 6.2 的单主 + 哨兵，JDK 17，压测用的是 hey -c 200 -n 100000 打过来的。

监控上看 CPU 最高才 62%，Redis 的 used_memory 离上限还远，慢日志也基本干净。表面上一切正常，但库存就是会多扣——这种"指标全绿但业务出错"的状态，往往指向并发正确性问题，而不是性能问题。

二、根因：SETNX 加 EXPIRE 两步，中间被"抢锁 + 误删"夹击

我们的加锁逻辑最初是这样的（伪代码）：

String key = "stock:lock:sku_10086";
String val = UUID.randomUUID().toString();
if (redis.setIfAbsent(key, val)) {          // 1. 加锁
    redis.expire(key, 5);                    // 2. 设 5 秒 TTL
    try {
        doDecrement();                        // 3. 扣库存
    } finally {
        redis.del(key);                       // 4. 解锁
    }
}

问题出在第 2 步和第 4 步之间的时间窗里，机制是这样的：

SETNX 和 EXPIRE 是两条独立命令，中间不是原子的。极端情况下进程在两条命令之间挂掉，会留下一个永不过期的死锁——这是第一类风险，但这次不是主因。
真正的主因是持锁超时 + 误删。扣库存逻辑里有一次走本地缓存回源，P99 偶尔会到 6~8 秒，超过了 5 秒的 TTL。于是：实例 A 还在执行第 3 步，锁却因为超时被 Redis 自动清掉了；实例 B 立刻 SETNX 成功拿到锁开始扣库存；这时实例 A 执行到第 4 步 redis.del(key)——它删掉的其实是 B 的锁。B 的锁没了，实例 C 又能进来，于是 A、B、C 三个实例同时在扣同一件库存，超卖就这么来的。

一句话根因：解锁时没有校验"这把锁还是不是我的"。DEL 是无条件删除，它不区分锁当前归属。

三、具体做法：用 Lua 把"校验 + 删除"做成原子操作

修复分两步。第一步，把加锁从两条命令合成一条带 TTL 的原子命令：

SET stock:lock:sku_10086 <uuid> NX EX 5

SET ... NX EX 5 一条命令同时完成"不存在才设置"和"设置 5 秒过期"，彻底消灭死锁窗口。

第二步，也是最关键的，把解锁改成 Lua 脚本，先比 value 再删：

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

Java 侧调用：

private static final String UNLOCK_LUA =
    "if redis.call('get',KEYS[1])==ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end";

// value 必须存在线程/请求级上下文里，绝不能是固定常量
if (eval(UNLOCK_LUA, List.of(key), value) == 1) {
    // 解锁成功
}

这里 value 必须是每次请求唯一的（UUID 或 instanceId + threadId + seq），并且存在请求作用域里，解锁时原样带回来比对。这样即使 A 的锁已过期、B 已持锁，A 拿自己的 UUID 去 get 比对，发现不等，直接返回 0，就不会误删 B 的锁了。

另外把 TTL 从 5 秒调到 30 秒，并在业务侧对 doDecrement() 加了一个"持锁续期"的看门狗（每 10 秒 PEXPIRE 续一次，且同样用 Lua 校验 value 后再续），保证长任务不会被中途抢锁。

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

value 用固定值是最隐蔽的坑。 一开始有人图省事把 value 写死成 "1"。这样多个实例的 value 全相等，Lua 里 get == ARGV[1] 永远为真，误删照样发生——原子校验形同虚设。value 的唯一性是整套方案成立的前提。
监控全绿不等于没 bug。 超卖是正确性问题，CPU、内存、慢日志都不会反映它。这类问题只能靠"库存对账"和"并发正确性压测"暴露，不能靠看监控。
TTL 不是越大越好。 调成 30 秒后死锁窗口变大，但配合了续期看门狗就安全了。真正要保证的是"业务耗时 P99 < TTL"，且两者之间留 3 倍以上余量，而不是拍脑袋定一个数。
GET + DEL 两条命令的"校验"并不原子。 有人以为先 GET 再 DEL 就行，但 GET 和 DEL 之间仍可能被别的实例插入。校验和删除必须封在一个 Lua 脚本里由 Redis 单线程执行才真正原子。

五、结论与可复用清单

这次超卖的本质是分布式锁的解锁没有归属校验，叠加持锁超时，导致误删他人锁。可复用清单：

加锁一律用 SET key val NX EX <ttl> 一条原子命令，禁止 SETNX + EXPIRE 两步。
解锁必须走 Lua：get == value 才 del，否则不动。
value 每次请求唯一（UUID / instanceId+threadId+seq），存在请求作用域，解锁时原样带回。
TTL 取"业务耗时 P99 的 3 倍以上"，长任务加续期看门狗（续期同样要校验 value）。
正确性问题不靠监控发现，要上库存对账 + 并发压测（hey -c 200 级别）做守门。
校验与删除、加锁与设 TTL，凡是要"先判断再操作"的，都封装进单个 Lua 脚本，让 Redis 单线程保证原子性。

一句话收束：分布式锁的难点从来不在"抢"，而在"放"——放的时候得先确认它还是你的。

赞 2 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。