承接上一篇 Redisson 可重入锁底层原理，本篇聚焦生产环境最容易踩坑的三大致命问题：锁超时释放、Redis 主从同步丢锁、集群脑裂锁失效，逐一分析问题成因、风险影响，并给出标准解决方案、代码适配与生产落地规范，同时补充 Redisson 对应机制源码级解读。
一、前言
在单机 Redis + 基础可重入锁实现之上，一旦部署到主从、哨兵、集群架构，再叠加业务执行时长不可控、网络抖动、节点宕机等线上场景，简单的分布式锁会直接失效，引发超卖、重复下单、数据错乱等严重事故。本篇不做理论空谈，全部围绕线上真实故障场景展开，先讲问题根源，再给解决方案，最后结合 Lua 脚本与业务编码做落地适配。
二、问题一：业务未执行完，锁自动超时释放（锁续租失效）
2.1 问题成因
我们给锁设置固定过期时间，初衷是防止节点宕机导致死锁。但线上业务执行时长不稳定：正常执行 2s，遇到慢查询、网络卡顿、第三方接口超时，耗时拉长到 10s。锁先到期被 Redis 自动删除，其他线程成功加锁，两个线程同时执行业务，分布式锁彻底失效。
2.2 传统简单方案弊端
- 单纯加大过期时间：业务正常执行时锁占用过久，高并发下线程阻塞堆积，吞吐量下降；极端宕机场景死锁时间同步拉长。
- 业务手动续期：硬编码定时刷新锁有效期，代码侵入严重，每个业务都要重复编写续期逻辑，维护成本极高。
2.3 工业级标准方案：看门狗续期机制（Redisson 原生实现）
核心设计逻辑
当加锁不手动指定过期时间时，自动开启看门狗：
- 锁默认过期时间：30 秒；
- 加锁成功后，客户端启动独立后台定时线程，每 10 秒主动续期一次，将锁过期时间重置为 30 秒；
- 只要持有锁的业务线程还在运行，续期就不会停止；
- 业务正常结束、主动解锁后，定时任务立即终止，不再续期。
关键边界规则
- 手动指定
leaseTime（锁超时时间）：看门狗直接关闭，由业务自行保证执行时长小于锁有效期； - 客户端宕机、网络断开：续期线程终止，锁走完 30 秒有效期后自动释放，避免死锁。
自定义锁适配改造（基于上篇 Hash 结构）
在原有加锁、解锁脚本基础上，增加客户端续期逻辑，续期同样使用 Lua 保证原子性：