Redis分布式锁实现：SETNX加过期时间详解

Redis分布式锁的实现远不止简单调用SETNX，其核心在于通过原子性命令SET key value NX EX seconds确保加锁与过期时间设置不可分割，配合唯一value标识和Lua脚本校验解锁，才能真正规避死锁、误删锁等致命问题；而单节点Redis的可靠性局限、集群下的key路由约束、过期时间的动态权衡、客户端库的底层陷阱，以及生产中必须依赖幂等设计兜底的务实思路，共同揭示了高并发场景下分布式锁不是“能用就行”，而是需要对每一步边界条件都严丝合缝的工程实践。

SETNX 为什么不能单独用作分布式锁

因为 SETNX 只能判断 key 是否存在并设置，不支持原子性地设置值 + 过期时间。如果先执行 SETNX 成功，再调用 EXPIRE，中间进程崩溃或网络中断，就会留下一个永不过期的锁，导致死锁。

常见错误现象：SETNX 返回 1（加锁成功），但后续 EXPIRE 没执行，锁永远卡住；多个客户端反复抢锁失败却查不到谁持有锁。

• 必须用 SET 命令的 NX + EX 组合替代 SETNX + EXPIRE
• Redis 2.6.12+ 才支持 SET key value NX EX seconds 这种原子写法
• value 必须是唯一标识（比如 UUID 或 client ID），否则解锁时无法验证所有权

解锁时为什么不能直接 DEL key

直接 DEL 会删掉别人持有的锁。比如 A 加锁后处理超时，锁自动过期；B 获得锁开始执行；A 结束后仍执行 DEL，把 B 的锁删了——这是典型的误删。

使用场景：任何需要安全释放锁的业务逻辑，尤其是耗时不确定的服务（如支付回调、文件处理）。

• 解锁必须用 Lua 脚本保证“校验 value + 删除”原子执行
• 脚本内容类似：if redis.call("GET", KEYS[1]) == ARGV[1] then return redis.call("DEL", KEYS[1]) else return 0 end
• 客户端传入的 ARGV[1] 必须和加锁时的 value 完全一致（建议用 UUID.randomUUID().toString()）

Redis 单点故障对锁可靠性的影响

用单台 Redis 实例实现分布式锁，一旦它宕机，所有锁状态丢失，可能引发重复执行或数据错乱。这不是“锁没生效”，而是“锁系统不可用”。

性能 / 兼容性影响：Redis Cluster 或哨兵模式下，SET ... NX EX 在跨 slot 时可能失败；Lua 脚本在集群中必须确保 key 在同一 slot（可用 {xxx} 包裹 key 名强制路由）。

• 生产环境别指望单节点 Redis 提供强一致性锁
• Redlock 算法理论上更安全，但实际落地复杂、延迟高、多数业务并不需要那幺半毫秒级的严谨
• 更务实的做法：接受小概率失效，配合幂等设计（比如用唯一订单号 + 数据库唯一索引兜底）

Java 客户端用 Jedis/Lettuce 写锁要注意什么

很多封装库（比如老版本 Redisson）默认用 SETNX + EXPIRE，表面看没问题，压测一高就暴露问题。关键不在“有没有锁”，而在“锁是否可重入、可续期、可安全释放”。

参数差异：SET key value NX EX 30 中的 30 是秒级过期，但业务执行时间可能波动。设太短容易误释放，太长又拖慢故障恢复。

• 过期时间建议设为「平均执行时间 × 3」，并记录日志监控超时率
• Jedis 示例：jedis.set(key, value, "NX", "EX", 30) —— 注意参数顺序，旧版 Jedis 不支持该重载
• Lettuce 推荐用 StatefulRedisConnection.sync().set(key, value, SetArgs.Builder.nx().ex(30))

真正难的不是写对一行 SET，而是让加锁、续期、解锁、异常清理整套逻辑在各种网络分区、GC 暂停、机器重启下依然不越界。这些边界情况，文档里通常不写，但线上会咬人。

今天带大家了解了的相关知识，希望对你有所帮助；关于数据库的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~