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

Redis分布式锁进阶第三十四篇：看门狗机制深度剖析与集群高可用实战

前言

日常开发中单纯使用SET key value NX EX实现的简易 Redis 分布式锁，只能满足简单短时效业务，一旦遇到长耗时任务、服务集群部署、主从节点宕机切换等场景，极易出现锁提前失效、锁误释放、死锁、集群锁失效等一系列线上问题。本篇承接前文，重点深挖 Redisson 原生分布式锁核心续命机制，补齐集群环境下分布式锁的高可用落地方案。

一、简易分布式锁致命缺陷复盘

1. 手动设置固定过期时间无法适配业务，业务执行未完成锁提前过期，多个线程同时获取锁引发数据错乱

2. 无自动续期能力，长任务场景基本不可用

3. 非可重入锁，同一线程多次加锁直接死锁阻塞

4. 主从同步存在延迟，主节点加锁成功立即宕机，从节点晋升为主节点后锁直接丢失，并发击穿防护失效

5. 异常场景下锁无法自动释放，极易造成全局死锁

二、Redisson 看门狗核心运行机制

1. 基础配置规则

Redisson 默认加锁无指定过期时间时，自动启用看门狗续命机制

• 锁默认有效期：30 秒

• 自动续期间隔：10 秒

• 底层依托后台异步线程定时执行续命逻辑

2. 执行流程

1. 客户端调用无参lock()方法完成加锁，锁存入 Redis

2. 成功获取锁后，后台定时任务自动启动

3. 每间隔 10 秒检测当前线程是否依旧持有锁

4. 持有锁则自动将锁过期时间重新重置为 30 秒，持续续命

5. 业务执行完毕主动调用unlock()释放锁，直接终止看门狗续期线程

6. 客户端意外宕机、进程崩溃，续期线程直接终止，锁不再续期，30 秒后自动过期，彻底杜绝死锁

3. 看门狗失效场景

• 手动指定锁过期时间lock(时间)，直接关闭看门狗，不再自动续期

• 非锁持有者执行解锁操作，锁提前释放，续期终止

• Redis 服务断开连接，续期指令发送失败，锁到期自动失效

三、可重入锁底层实现原理

Redisson 分布式锁基于 Lua 脚本实现可重入特性，采用Hash 结构存储锁数据

• key：锁名称

• field：当前客户端唯一线程 ID

• value：锁重入次数 同一线程多次加锁，仅累加计数，不会阻塞；解锁逐层递减计数，计数归 0 才真正删除锁释放资源，完美适配嵌套业务调用场景。

四、集群架构下锁丢失解决方案

1. 问题根源

Redis 主从集群采用异步复制，主节点加锁成功后数据未同步至从节点，此时主节点宕机，从节点升级为主节点，新请求可直接再次加锁，分布式锁彻底失效。

2. Redisson RedLock 红锁方案

部署多个相互独立、无主从关系的 Redis 独立节点

1. 客户端统一向所有节点发起加锁请求

2. 必须超过半数节点加锁成功，才算整体加锁成功

3. 严格控制整体加锁耗时，必须小于锁有效时长

4. 业务执行完成后，统一向所有节点执行解锁操作 优势：极致保证数据一致性，杜绝集群切换锁丢失问题；劣势：性能偏低，资源开销大，仅用于金融、订单等高严谨业务。

3. 联锁 MultiLock 实战应用

适用于需要同时锁定多个业务资源的场景，批量锁定多个分布式锁

• 全部锁获取成功，才算加锁成功

• 任意一把锁获取失败，自动释放已获取所有锁

• 解锁同步释放全部锁定资源，保证多资源锁定原子性

五、线上生产环境最佳使用规范

1. 普通常规业务优先使用默认无参加锁，依靠看门狗自动续期，开发成本最低，稳定性最强

2. 短时效秒杀、限流场景可手动指定过期时间，关闭看门狗提升性能

3. 核心资金交易、对账结算业务，直接使用 RedLock 红锁保障强一致性

4. 所有加锁代码必须放入 try-finally 结构，确保无论正常执行还是异常报错，锁都能正常释放

5. 严格控制锁内业务逻辑执行时长，避免长时间占用锁影响服务并发吞吐量

6. 禁止跨服务、跨线程传递分布式锁，避免出现锁错乱误释放问题