Redis 分布式锁误删排查：为什么 SET NX 后仍会并发进入

Redis 分布式锁看起来很简单：用 SET key value NX PX 抢锁，业务完成后删除锁。可线上偶尔还是出现两个请求同时进入临界区，日志里还看不出明显报错。本文从这个现象出发，复现旧请求误删新锁的过程，再把释放锁流程改成“先校验 token，再删除自己的锁”。

适合读者：已经了解 Redis 基础命令，正在用 Redis 做订单处理、库存扣减、任务调度、接口防重等并发控制的开发者。

问题现场：加了锁仍然偶发并发进入

我们先看现象。接口对同一个订单做处理，代码里已经用了 Redis 锁，但日志偶尔出现两条处理记录：请求 A 先拿到锁，业务执行时间偏长；请求 B 后面也拿到锁并进入；最后两边都写了结果。

很多人第一反应是“锁没有加成功”。但如果日志显示 A 和 B 都在不同时间拿到过锁，真正的问题可能不是加锁，而是释放锁时误删了别人的锁。

初步判断：SET NX PX 只能保证加锁动作原子

先确认加锁方式。推荐的基础写法是一次命令同时完成“只有不存在才写入”和“设置过期时间”：

SET lock:order:123 A-123 NX PX 30000

这条命令能避免两个问题：先 SETNX 再 EXPIRE 时中间崩掉导致死锁；多个请求同时抢锁时，只有一个请求能写入成功。但它只保护“加锁动作”，并不自动保证“释放锁动作一定删的是自己的锁”。

动手验证：复现旧请求误删新锁

接着验证这个猜测。假设锁过期时间是 30 秒，请求 A 拿锁成功后业务跑了 40 秒；第 31 秒时锁已经自然过期，请求 B 重新拿到同一个锁；第 40 秒 A 业务结束，如果它直接删除 lock:order:123，删掉的就是 B 的新锁。

t=00s  A 写入 lock:order:123 = A-123，TTL 30s
t=31s  锁过期，B 写入 lock:order:123 = B-456，TTL 30s
t=40s  A 结束业务，直接删除 lock:order:123
t=41s  其他请求发现锁不存在，可能再次进入

这一步说明，加锁成功并不等于释放安全。只要业务时间可能超过 TTL，或者机器暂停、网络抖动、下游调用变慢，就可能出现“旧请求还活着，新锁已经被别人拿走”的窗口。

定位原因：锁值没有表示当前请求身份

现在可以定位到原因：锁的 key 只表示资源，例如 lock:order:123，但释放时没有确认 value 是否属于当前请求。正确思路是给每次加锁生成唯一 token，把 token 写入锁值，释放时只有 token 匹配才允许删除。

token 可以是 UUID、雪花 ID、请求追踪 ID，关键是每次请求都不同。不要用固定值，例如 locked 或用户 ID，因为它无法区分这一次请求和下一次请求。

修复方案：token 校验后再释放锁

修复方案分两步：加锁时写入本次请求 token；释放时在 Redis 侧完成“读取、比较、删除”这一组动作，避免客户端先读后删中间又被别人改掉。

SET lock:order:123 a1b2c3d4 NX PX 30000

释放锁时使用 Lua 脚本表达“值相同才删除”：

if redis.call('GET', KEYS[1]) == ARGV[1] then
  return redis.call('DEL', KEYS[1])
end
return 0

注意这里的重点不是 Lua 本身，而是把“读锁值、比 token、删锁”放到 Redis 里一次完成。这样即使 A 的业务超时，只要锁值已经变成 B 的 token，A 的释放动作就会返回 0，不会删掉 B 的锁。

验证结果：过期、重试和释放都要看

最后确认修复是否有效，不只看“正常请求能通过”。至少要验证三个场景：

1. 请求 A 正常完成，token 匹配，释放锁返回成功。
2. 请求 A 超过 TTL 后结束，锁已经不存在，释放锁返回 0。
3. 请求 A 超过 TTL 后结束，请求 B 已拿到新锁，A 释放锁返回 0，B 的锁仍然存在。

如果第三个场景能稳定通过，说明“误删新锁”的风险已经被挡住了。线上还可以把释放锁返回值、业务耗时、锁 TTL、请求 token 写到日志里，便于后续分析超时比例。

常见误区与总结

常见误区有四个。第一，只用 DEL key 释放锁，忽略锁值身份；第二，锁 TTL 设得太短，业务稍慢就过期；第三，TTL 设得太长，故障恢复变慢；第四，没有给释放失败做日志，导致线上只看到并发结果，看不到锁链路。

这次排查的结论很明确：SET NX PX 解决的是加锁原子性，token 校验解决的是释放锁安全性。一个可靠的 Redis 分布式锁至少要做到三点：加锁时有过期时间，锁值能标识本次请求，释放时只删除 token 匹配的锁。把这三点补齐后，再结合合理 TTL 和业务幂等，线上并发问题会稳很多。