Redis 分布式锁续期失败后如何判断锁已失效

Redis 分布式锁续期失败时，不能只看客户端抛出的异常，也不能收到一次超时就继续执行临界区。安全判断只有一个核心：锁键的值仍然必须等于本客户端保存的唯一令牌，并且租约还有正的剩余时间。续期脚本明确返回成功，代表脚本执行结束时仍持有锁；返回失败，代表锁已失效或已经换了持有者；连接超时则是“状态未知”，应先停止高风险操作。

官方文档：https://redis.io/docs/latest/

续期结果为什么不能直接当作锁状态

锁键通常保存一个随机令牌，例如 lock:order:123 的值是当前客户端生成的 worker-a:uuid。获取时可以使用下面的示例命令：

redis-cli SET lock:order:123 worker-a:uuid NX PX 30000
# NX 只在键不存在时写入，PX 给锁设置毫秒级自动过期时间

续期请求返回 0，一般能说明脚本看到的键不存在或令牌已不匹配；这时当前客户端不能再写临界资源。可是客户端只收到连接超时、断线或读响应失败时，Redis 可能已经执行了请求，也可能根本没有收到请求，客户端本身无法从异常文字推断结果。把这种情况当成“锁还在”会留下并发写风险。

Redis 官方分布式锁说明强调，释放锁时必须校验随机值，避免旧持有者删除后来者的锁。续期同样遵守这个原则，只是把删除换成了延长过期时间。

用令牌和 PTTL 原子确认是否仍是持有者

不要拆成“先 GET，再单独 PEXPIRE”两个客户端请求。两个请求之间可能发生过期或被其他客户端重新获取。下面的 Lua 片段把令牌比较、TTL 检查和续期放在 Redis 的一次脚本执行中：

-- 只有令牌匹配且租约仍有效时，才延长锁的 TTL
local current = redis.call('get', KEYS[1])
if current ~= ARGV[1] then
    return {0, -2} -- 键不存在或值已换成别人的令牌
end

local ttl = redis.call('pttl', KEYS[1])
if ttl 

脚本参数中 KEYS[1] 是锁键，ARGV[1] 是当前客户端令牌，ARGV[2] 是新的租约毫秒数。脚本返回的第一个值是业务判断依据：1 才允许继续，0 必须停止。第二个值用于记录诊断，不应被当成所有权证明。

PTTL 返回正数表示还有剩余时间，-2 表示键不存在，-1 表示键存在但没有过期时间。对于分布式锁，永久键通常意味着获取或恢复逻辑出了问题，因此宁可按失败处理并人工排查，也不要把它当成长租约。

续期异常时按三种状态收敛

重连后的检查仍然要比较令牌，最好复用一个只读脚本一次性返回“是否匹配”和 PTTL。如果读到的是自己的令牌且 TTL 为正，只能说明当前这个 Redis 实例此刻仍保存着这把锁；长时间暂停、主从切换或跨实例锁场景还需要结合部署模型重新评估。对库存、余额、订单状态等真正不能接受旧写入的场景，建议给每次成功获取分配递增的栅栏标识，由下游存储拒绝较小标识的写入。

释放锁和监控中最容易漏掉的边界

释放时也不能直接执行 DEL lock:order:123。客户端暂停后，原锁可能已经过期，键又被新客户端占用，裸删除会误删后来者。释放脚本应保持同样的令牌条件：

-- 只删除仍属于本客户端的锁，避免旧客户端误删后来者
if redis.call('get', KEYS[1]) == ARGV[1] then
    return redis.call('del', KEYS[1])
end
return 0

监控上至少记录锁键、令牌摘要、续期返回码、PTTL、网络错误类型和进入“未知状态”的次数。不要把“续期线程还活着”当作锁有效；真正有用的是 Redis 原子操作的返回值和业务写入端的栅栏校验。

相关问题

续期每次都返回 0 是不是 Redis 挂了？

不一定，也可能是锁已过期、令牌不一致、键名拼错或脚本参数顺序错误。先区分明确的脚本返回和网络异常，再检查键值与租约配置。

可以直接 GET 锁值再判断吗？

GET 适合排查，但不适合作为续期的并发安全实现。比较令牌和改变 TTL 应放在同一脚本或等价的服务端原子操作中。

PTTL 为 -1 时能不能继续使用锁？

对依赖自动释放的锁，不建议继续。没有过期时间意味着故障后可能永久占用，应先停止临界区并修复获取或续期逻辑。