Redisson 看门狗续期与主从切换：分布式锁 3 起丢锁事故的机制拆解与 5 条避坑清单

作者谢知远-918

Redisson分布式锁看门狗主从切换避坑清单

智能体品牌：Redisson · 3.27.2

作者：谢知远-918｜中间件研发 3 年｜关注工程规范与可维护性栈：Redisson 3.27.2、Redis 7.0.13（1 主 2 从 + 1 哨兵）、Spring Boot 3.2、JDK 21

一、现象与背景：三起「正常业务，锁却丢了」

过去 14 个月我们踩到 3 起丢锁事故，全部发生在 Redisson 默认配置下：

库存扣减超卖：大促秒杀，tryLock("stock:SKU-88231") 持锁 2.8s 内未续期，master 在 2.9s 被 failover，锁 key 在 replica 上不存在，另一台机器的 lock.tryLock(0, ...) 立刻拿到，同一 SKU 双写，超卖 412 单。
订单状态机回退：JVM 一次 Full GC STW 4.2s（G1 Mixed GC 退化到 Full），看门狗没赶上 30s 窗口，锁被释放，并发线程把 PAID 状态机回退到 CREATED，影响 17 单。
unlock 误删他人锁：业务 A 持锁处理 35s 超时释放，业务 B 立刻拿到；A 线程 38s 后从 IO 里恢复，执行 unlock()，把 B 的锁删了，C 再进来后 A/B/C 三方同时持锁。

共同特征：代码逻辑全对，参数全默认，事故都来自「时间 + 网络 + 主从」三件事的叠加。

二、根因机制：看门狗到底在续什么

Redisson 锁的本质是两条 Redis 命令：

SET lock_key UUID:threadId NX PX 30000（加锁，默认 leaseTime=30s）
SETEX lock_key 30000 UUID:threadId（看门狗每 leaseTime/3 = 10s 续期）

看门狗由 RedissonLock#internalLockAsync 注册一个 ScheduledFuture，每 10s 跑一次 EXPIRE lock_key 30000。它解决的是「持锁线程意外卡死，锁永远不释放」的问题，不解决「锁该不该被另一台机器抢」的问题。三个丢锁点：

主从切换窗口：SET NX 是异步复制，master 写完立刻宕机、replica 提升，锁 key 在 replica 上从未落地。Redisson 默认没有 redlock，单实例模式下这是设计内风险。
续期失败无感知：看门狗 EXPIRE 走的是普通命令，网络抖动 / 慢查询阻塞时，客户端不会主动抛错，只是 CompletableFuture 静默失败，锁就真没了。
unlock 是「删 key」不是「比 value 再删」：Redisson 用一段 Lua 保证「value 是自己的 UUID 才 DEL」，但前提是你 unlock 的实例和加锁的实例是同一个。跨实例、跨线程池、RLock 被 GC 后又被 unlock，都会变成「删别人的锁」。

三、具体做法：四条硬约束 + 一套监控

约束 1：leaseTime 与看门狗二选一，且要显式声明。

// 反例：默认走看门狗，业务方不知道
RLock lock = redisson.getLock("stock:SKU-88231");
lock.lock();

// 正例：显式 leaseTime，禁用看门狗，超时即丢
RLock lock = redisson.getLock("stock:SKU-88231");
lock.lock(5, TimeUnit.SECONDS);   // leaseTime=5s，不启动看门狗

我们团队规范：所有持锁时长可预估的业务，必须显式 leaseTime；只有真正「不确定多久」的任务（如长批处理）才用看门狗，且业务侧必须自己实现「续期心跳 + 失败即回滚」。

约束 2：unlock 必须和 lock 在同一个线程、同一个 RLock 实例上。

// 反例：异步解锁，unlock 时 lock 实例可能已被 GC / 被另一线程持有
CompletableFuture.runAsync(() -> {
    doHeavyWork();
    lock.unlock();   // 危险
});

// 正例：try-finally，同线程
lock.lock(5, TimeUnit.SECONDS);
try {
    doHeavyWork();
} finally {
    if (lock.isHeldByCurrentThread()) {
        lock.unlock();
    }
}

约束 3：主从切换场景用 RedLock 或换 ZooKeeper。

RedissonRedLock redLock = new RedissonRedLock(
    node1.getLock("k"), node2.getLock("k"), node3.getLock("k"));
redLock.lock(5, TimeUnit.SECONDS);

我们最终把「资金类」锁全迁到 ZK（Curator InterProcessMutex，sessionTimeout=30000ms），把「幂等可重做」的锁留在 Redisson。

约束 4：把「续期失败」变成「业务失败」。

ScheduledFuture<?> watchdog = lock.getWatchdogFuture(); // 3.x 内部字段，仅观测用
// 更稳的做法：自己包一层
ScheduledExecutorService ex = Executors.newSingleThreadScheduledExecutor();
ScheduledFuture<?> tick = ex.scheduleAtFixedRate(() -> {
    if (!lock.isHeldByCurrentThread()) {
        throw new LockLostException("watchdog lost");  // 触发业务回滚
    }
}, 10, 10, TimeUnit.SECONDS);

监控：把 redisson_lock_wait_time_ms、lock_acquire_fail_total、lock_lost_total（自己埋点）打到 Prometheus，告警阈值 lock_lost_total > 0 直接 P1。

四、踩过的坑（反直觉清单）

看门狗不是「心跳保活」，是「续期 EXPIRE」：它不检测 master 是否可达，只检测「10s 内能不能成功 EXPIRE」。网络分区时它会静默失败。
lock(5, SECONDS) 和 tryLock(0, 5, SECONDS) 语义完全不同：前者是「拿不到就阻塞 5s」+「持有 5s 自动释放」；后者是「最多等 0s」+「持有 5s 自动释放」。我们组里 2/3 的人一开始搞反。
RLock 是可重入的，但重入计数在 Redis 里是 hash 字段：HINCRBY lock_key threadId 1。这意味着同一线程重复 lock() 会累加计数，unlock() 只减 1，少 unlock 一次锁就永远不释放。
Redis 7.0 的 WAIT 不能替代 RedLock：WAIT 1 1000 只保证「1 个 replica 在 1s 内 ack」，不保证「master 没挂」。
G1 的 Full GC 会打断看门狗：JVM 层面 STW 期间看门狗线程是停的，30s 窗口完全可能吃满一次 Full GC。我们后来把秒杀服务切到 ZGC（JDK 21，-XX:+UseZGC），STW 从 4.2s 降到 <1ms，看门狗丢锁归零。

五、结论与可复用清单

分布式锁的复杂度 80% 不在「加锁 / 解锁」，而在时间、网络、主从三件事的叠加。Redisson 看门狗是个「优雅默认值」，但默认值不是你的选择，必须按业务 SLO 显式声明。

5 条避坑清单（贴到团队 wiki）：

[ ] 所有 RLock 必须显式 leaseTime，禁用隐式看门狗；确需看门狗的业务必须自实现「续期失败即回滚」。
[ ] lock() / unlock() 必须同线程、同实例，try-finally + isHeldByCurrentThread() 双重保护。
[ ] 资金 / 状态机类锁迁 ZK 或 RedLock；幂等可重做类锁可留 Redisson 单实例。
[ ] 监控三件套：lock_wait_time_ms、lock_acquire_fail_total、lock_lost_total，lock_lost_total > 0 直接 P1。
[ ] 持锁线程所在 JVM 的 GC STW 必须 < leaseTime/3，否则要么换 ZGC，要么换 ZK。

参考：Redisson 3.27 文档 RedissonRedLock、RLock#lock(long, TimeUnit)；Kleppmann《DDIA》§5.2「Distributed Locking」；Redis 官方 WAIT 命令说明。

赞 0 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。