Redis 的 Pub/Sub 不能用于锁续期监听，因其“发即忘”且无消费确认；Watchdog 是客户端后台线程，仅执行 PEXPIRE 刷新 TTL，不触发任何 PUBLISH；唯一有效用途是监听锁释放事件（redisson_lock__channel:{lockName}）以唤醒等待线程。
Redis 的发布订阅（Pub/Sub）本身不能直接用于实现分布式锁续期，也不能替代 Watchdog 机制；它不保证消息可达、不支持重试、无消费确认，且无法绑定到某个锁实例的生命周期。 直接监听一个频道来“接收 Watchdog 续期通知”是误解了 Redisson 等客户端的设计逻辑 —— Watchdog 是纯客户端侧的后台线程，不发任何 Pub/Sub 消息。
为什么不能靠 PUBLISH/SUBSCRIBE 实现锁续期监听
Redisson 的 Watchdog 不触发任何 PUBLISH 操作。它只在持有锁的 JVM 进程内执行 PEXPIRE 命令刷新 TTL，全程不涉及频道通信。试图用 SUBSCRIBE lock:renew:channel 等方式监听续期事件，结果只会是收不到任何消息。
- Pub/Sub 是「发即忘」模型：消息不持久、不落盘、消费者离线即丢失
- 没有机制将某次
PEXPIRE lock:order:123 client_a关联到某个频道或事件类型 - 即使你手动在续期时
PUBLISH lock:renew "lock:order:123"，也无法解决核心问题：其他节点无法据此判断“该锁是否仍被合法持有”
真正需要监听的，是锁释放事件（不是续期）
Redisson 在锁被主动释放或过期时，会通过 Pub/Sub 广播 redisson_lock__channel:{lockName} 频道，发送一个空消息，用于唤醒等待中的线程。这才是 Pub/Sub 在分布式锁中唯一被客户端框架实际使用的场景。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 监听频道名格式固定：
redisson_lock__channel:myLock - 收到消息仅表示“锁可能已释放”，必须再次
tryAcquire确认，不能直接认为自己获取到了锁 - 该机制用于优化
tryLock(long, TimeUnit)的等待效率，和续期无关 - 若使用
lock()（无超时），Redisson 内部就依赖这个频道做锁释放通知 + 重试调度
想观察 Watchdog 行为？别监听频道，改看日志或 TTL
要验证 Watchdog 是否正常工作，最直接有效的方式是检查锁 key 的 TTL 变化，而不是订阅不存在的“续期频道”。
- 加锁后立即执行：
PTTL myLock，应返回接近 30000（毫秒） - 等待 10 秒后再次执行：
PTTL myLock，仍应返回接近 30000 —— 这说明 Watchdog 已生效 - 调用
unlock()后再查：PTTL myLock返回-2（key 不存在） - 若 TTL 持续下降未被重置，说明 Watchdog 线程异常终止（如 JVM 被 kill -9、线程池 shutdown 失败）
Watchdog 的可靠性取决于客户端进程存活状态，它不依赖网络通信，也不暴露可监听的续期信号。把注意力放在 key 的 TTL 稳定性上，比设计一个无效的订阅方案更接近问题本质。
