Redisson 分布式锁自动续期：设计模式、源码原理与方案对比

北漂老男孩

673人浏览 · 2026-02-13 00:00:00

北漂老男孩 · 2026-02-13 00:00:00 发布

Redisson 分布式锁自动续期：设计模式、源码原理与方案对比

概述

Redisson 的看门狗（Watchdog）是客户端侧“主动式、智能化”的分布式锁续期机制，专为“业务时长不可预估”的场景而生。它以 Netty 时间轮定时任务驱动续期，以 Lua 脚本保障原子性，以全局续期状态结构管理并发，形成“高可靠、低心智负担、无死锁”的工程方案。

价值主张：业务未完成前“锁不失效”，业务完成后“及时释放”；客户端宕机后“自然过期”，避免死锁。
默认策略：看门狗超时默认 30s，每 1/3（约 10s）自动续期一次；无参 lock() 启用看门狗；带租期 lock(long leaseTime, TimeUnit unit) 禁用。

简介与项目背景

在典型的“库存扣减、订单创建、跨系统一致性”场景中，事务时长受外部系统与网络影响难以精准预估。固定 TTL 要么过短导致锁提前失效，要么过长造成宕机后长期占用。Redisson 以“客户端主动续期”化解此两难：不要求你精准预估时长，仍能保障锁的时效与可靠释放。

名词解释

看门狗（Watchdog）：指 Redisson 客户端内部的锁续期调度器，按 1/3 TTL 周期触发续期。
Lua 原子脚本：在 Redis 侧以 Lua 执行业务校验与续期，确保“检查持有者 + 续期”在同一事务内完成。
Netty HashedWheelTimer：高性能时间轮定时器，O(1) 级别调度，复用事件循环线程池。
ExpirationEntry：每把锁的续期状态条目，记录线程 ID、重入计数、定时任务句柄等。
全局续期状态表（如 EXPIRATION_RENEWAL_MAP）：并发安全地存储锁对应的 ExpirationEntry，避免状态漂移与竞态。
键空间通知（Keyspace Notifications）：Redis 的 Pub/Sub 机制，可推送键过期等事件，适合统计与异步解耦，不适合锁续期。

原理与流程（三步闭环）

续期以“启动 → 续期 → 停止”的闭环运行，关键在“持有者校验 + 原子续期 + 递归调度”。

要点：

启动：无参 lock() 成功后创建续期任务，状态入表。
续期：定时触发 renewExpirationAsync() 的 Lua 脚本原子逻辑；成功则递归调度下一次。
停止：unlock() 时清理状态与定时任务；客户端宕机则任务自然停止，锁到期释放。

续时期序图（带样式分区）

源码关键点（点到即止）

加锁入口：lock() → 实际走到 lock(-1, null, false)，leaseTime=-1 表示启用看门狗。
定时器选择：HashedWheelTimer 提供轻量、高并发的 O(1) 级任务调度。
续期核心：renewExpirationAsync() 调用 Lua 校验锁归属并 pexpire 重置 TTL；完成后以回调形式递归安排下次续期。
状态管理：全局表（如 EXPIRATION_RENEWAL_MAP） + ExpirationEntry 保证线程安全与信息一致。

设计模式与思想

封装设计（Encapsulation）
- 将加锁、续期、解锁、Lua 原子逻辑、状态管理封装于 RedissonLock 内部，对外仅暴露简洁的 API。
观察者模式（Observer）
- 异步续期回调 future.whenComplete(...) 自动推进续期或停止，无需主动轮询。
单例模式（Singleton）
- RedissonClient 单例化，统一复用 EventLoop 与定时器线程池，避免多实例资源浪费。
防御式设计（Defensive Design）
- TTL 兜底、1/3 提前续期、持有者校验、解锁资源清理，构成多重防线，杜绝死锁并降低维护成本。

基于键空间通知的续期实现（示例与风险）

步骤与命令：

# 开启键空间通知（K: 键空间事件；E: 键事件通知；x: 过期事件）
CONFIG SET notify-keyspace-events KEx

# 订阅过期事件频道（示例：db0）
SUBSCRIBE keyevent@0:expired

伪代码（含“影子 Key”技巧）：

// 影子 Key: shadow:lock:order_1(TTL 20s)；主锁: lock:order_1(TTL 30s)
redisSubscriber.on('message', (channel, expiredKey) => {
  if (expiredKey === 'shadow:lock:order_1') {
    // 检查主锁是否存在且仍为我持有
    if (exists('lock:order_1') && valueEqualsMyUUID('lock:order_1')) {
      // 续期两者 TTL
      pexpire('lock:order_1', 30000);
      pexpire('shadow:lock:order_1', 20000);
    }
  }
});

局限性与风险：

可靠性低：Pub/Sub 发后即忘，监听者短暂掉线会错过事件，锁直接失效。
实时性差：expired 事件是在主键已删除后发布，续期常常为时已晚，必须依赖“影子 Key”前置触发。
服务端压力：大量过期事件会显著增加 Redis 推送负载。
并发复杂度：需要自己处理锁归属校验、双键一致性和竞态条件。

方案对比（工程选型）

维度	Redisson 看门狗（主动续期）	手动守护线程（被动续期）	键空间通知（被动回调）
易用性	自动启用，无样板代码	需自管线程/时机/异常	需维护订阅与“影子 Key”
可靠性	客户端在即续期在；多重校验	易线程泄漏/续期不及时	Pub/Sub 发后即忘，消息易丢
性能	复用 Netty 线程池，时间轮 O(1)	线程调度与资源占用风险	服务端推送压力集中
实时性	客户端自控，毫秒级	取决于实现	通知可能滞后（主键已过期）
复杂度	封装良好、参数可配	自研代码碎片化	需双键管理与额外并发校验
适用	生产级分布式锁	简单本地场景	统计/异步解耦

与 Redis 集群的一致性

Redis Cluster 以 CRC16 → 槽位分片存储；客户端需命中主节点执行锁操作。
Redisson 对锁 Key 计算槽位并固定路由到对应 Master，保证加锁/续期/解锁都在同一节点，减少跨节点一致性与时序问题。

工程实践建议

参数调优：按业务 P99 时长设置 Config.setLockWatchdogTimeout()（如 30–60s）；搭配应用层超时兜底。
监控指标：续期成功/失败次数、Lua 脚本耗时、定时任务排队/丢失、解锁清理延迟、锁持有时长分布。
故障演练：模拟客户端宕机（观察 TTL 自动释放）与网络抖动、主从切换（验证校验与路由一致性）。
常见坑：误用带租期 lock(long leaseTime, TimeUnit unit) 导致不续期；忘记解锁虽然有 TTL 兜底但会延长占用窗口；单机多客户端实例导致线程池重复。

FAQ 与避坑速查

Q：如何判断是否启用看门狗？
- A：无参 lock() 启用；显式 leaseTime 则禁用。
Q：续期失败会怎样？
- A：回调终止续期并清理状态；若仍持有锁失败，需检查线程归属与网络；最终 TTL 到期自动释放。
Q：集群环境如何保证一致性？
- A：客户端复用槽位路由固定到 Master；同一把锁的所有操作在同一节点执行。
Q：为什么不建议用键空间通知做续期？
- A：可靠性与实时性差，复杂度高，压力集中在服务端；更适合统计类或解耦场景。

参考资料与权威文献

Redisson 官方文档与 Wiki：https://github.com/redisson/redisson/wiki
Redisson GitHub 仓库：https://github.com/redisson/redisson
Redis Keyspace Notifications：https://redis.io/docs/latest/operate/notification/keyspace-events/
Netty HashedWheelTimer：https://netty.io/
Lua 脚本与 Redis 事务语义：https://redis.io/docs/latest/develop/programmability/eval-intro/
Redlock 算法与讨论（pros & cons）：https://redis.io/docs/latest/develop/data-types/locks/ 和 https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html