Redis分布式锁进阶第三十八篇

在分布式系统中，Redis 分布式锁凭借高性能、易接入的特性，成为跨节点互斥控制的主流方案。基础版SET key value NX EX虽能实现简单互斥，但在长事务、集群部署、异常容灾等场景下存在明显短板。本文聚焦 Redis 分布式锁进阶能力，从核心痛点、关键技术、生产实践到性能调优，全面讲解如何构建安全、可靠、高可用的分布式锁体系。

一、基础分布式锁的核心痛点
原生 Redis 分布式锁基于 **SET NX（互斥）+ EX（过期）** 实现，存在四大致命问题：

锁超时释放风险：业务执行时间超过锁过期时间，锁被自动释放，导致并发冲突。
锁误删问题：线程 A 超时释放锁后，线程 B 加锁成功，线程 A 执行完毕直接删除锁，造成锁失效。
不可重入：同一线程多次请求同一锁时被阻塞，无法适配嵌套调用场景。
集群脑裂失效：主从异步复制下，主节点加锁后宕机、锁未同步，从节点晋升后主锁丢失，引发重复加锁。
这些问题决定了基础锁仅适用于简单场景，生产环境必须通过进阶方案补齐能力。

二、进阶核心技术：解决基础锁缺陷
（一）原子化解锁：Lua 脚本杜绝误删
防误删的核心是锁归属校验 + 原子删除，通过 Lua 脚本实现两步操作原子化：

lua

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

脚本中，KEYS [1] 为锁 key，ARGV [1] 为线程唯一标识（UUID + 线程 ID），只有归属匹配才执行删除，彻底避免线程 A 删除线程 B 持有的锁。

（二）看门狗自动续期：解决长事务锁超时
针对业务耗时不可控问题，引入 ** 看门狗（WatchDog）** 机制：

加锁成功后启动后台定时任务，默认每 10 秒（锁过期时间 30 秒的 1/3）执行续期。
检查线程仍持有锁时，重置锁过期时间为 30 秒。
业务正常结束或进程崩溃后，看门狗停止续期，锁到期自动释放。
看门狗是 Redisson 的核心能力，无需手动维护过期时间，完美适配长流程业务。

（三）可重入锁：支持嵌套加锁
基于 Redis Hash 结构实现可重入：

key：锁名称；field：线程唯一标识；value：重入计数。
同一线程加锁时，计数 + 1 并重置过期时间；解锁时计数 - 1，计数为 0 时删除锁。
可重入锁适配 Spring 事务、嵌套方法调用等场景，避免线程自我阻塞。

三、集群高可用：Redlock 算法解决脑裂
Redis 主从集群的异步复制特性，导致单主锁存在脑裂风险。Redlock 算法由 Redis 官方提出，通过多节点独立部署实现强一致锁：

部署5 个独立 Redis 主节点（无主从关系），避免单点故障。
客户端同时向所有节点发起加锁请求，超过半数（≥3 个）节点加锁成功，且总耗时小于锁过期时间，才算加锁成功。
加锁失败时，向所有节点释放已获取的锁，防止资源泄漏。
Redlock 牺牲部分性能换取高可靠性，适用于金融、交易等强一致性场景。需注意：Redlock 依赖节点时钟一致性，极端情况下仍有理论风险，生产中可结合业务降级策略使用。

四、生产级实践：Redisson 分布式锁落地
Redisson 是 Java 生态最成熟的 Redis 分布式锁框架，封装了所有进阶能力，开箱即用：

核心特性：支持可重入锁、公平锁、读写锁、红锁、联锁，内置看门狗续期，全链路 Lua 原子化操作。