单纯订阅 expired 事件不可靠，因无法确认锁归属、通知可能丢失、多节点竞争无控制；redisson 仅将其作唤醒信号，通过 lua 脚本原子校验 value 后才删除，确保安全。
可以，但不能直接靠 PSUBSCRIBE __keyevent@*:expired 可靠感知“锁过期”，必须配合锁的 value 校验和分布式协调逻辑，否则会误触发、漏处理甚至释放别人的锁。
为什么单纯订阅 expired 事件不适用于分布式锁失效感知
Redis 的 key 过期通知（__keyevent@0__:expired）只告诉你“某个 key 刚被删了”，但不告诉你：
- 这个 key 是不是你加的锁（value 可能已被覆盖）
- 它是不是在你持有期间过期的（可能刚被别人重设了 TTL）
- 通知是否送达（Pub/Sub 是 fire-and-forget，无 ACK，网络断开就丢）
- 多个节点同时收到同一条 expired 消息，谁该处理？没有竞争控制
比如你用 SET myLock "nodeA-123" EX 30 NX 加锁，30 秒后 key 过期，Redis 发出通知；但若 nodeB 在第 25 秒用相同 key 成功抢锁（value 变成 "nodeB-456"），此时过期通知仍会触发 —— nodeA 若盲目调用 unlock()，实际删掉的是 nodeB 的锁。
Redisson 是怎么安全用 expired 通知的
Redisson 的 RPatternTopic 订阅确实监听 __keyevent@*:expired，但它只把通知当「唤醒信号」，不直接执行解锁。真正判断是否要释放锁，靠的是：
- 本地缓存的锁状态（是否是自己加的、当前 value 是什么）
- 收到 expired 消息后，立刻用 Lua 脚本原子校验：
if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end - 只在 value 匹配时才执行删除，否则忽略
也就是说，expired 事件只是个“提醒你去看看”，不是“命令你删掉”。没这层校验，redis.publish("__keyevent@0__:expired", "myLock") 这类手动模拟完全不可靠。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
自己实现时必须绕开的三个坑
如果你不用 Redisson，而是基于原生 Redis + Pub/Sub 做锁过期感知，这几个点不处理，基本等于没做：
-
必须用 Lua 校验再删除：不能先
GET再DEL，中间可能被篡改；必须用单次 EVAL 原子执行 -
必须区分“过期”和“被显式删除”：Redis 不会为
DEL myLock发送 expired 事件，所以你的业务里主动释放锁时，也要同步清理本地状态，否则 expired 通知来了会重复处理 - 不能依赖单节点订阅：一个服务实例挂了，它的订阅就断了；要用所有节点都订阅，并靠 value 校验保证幂等，避免多节点同时响应同一事件
示例关键 Lua 脚本：
if redis.call("get", KEYS[1]) == ARGV[1] then
return redis.call("del", KEYS[1])
else
return 0
end
更稳的替代方案：用 Redisson 的看门狗（watchdog）机制
Redisson 默认开启自动续期（leaseTime 默认 30s，每 10s 续一次），根本不需要依赖 expired 通知 —— 它靠后台心跳保活。只有在 client 断连、无法续期时，锁才自然过期。这时 expired 通知最多起辅助诊断作用，不是主流程。
自行实现 watchlog 难度高（需维护定时任务、处理网络分区、避免时钟漂移），而 Redisson 的 tryLock(long waitTime, long leaseTime, TimeUnit unit) 已封装完整。除非你明确需要锁“绝对准时过期”（比如金融场景的强时效控制），否则别绕过看门狗去折腾 expired 订阅。
真正容易被忽略的是：expired 通知本身不可靠，而 value 校验 + Lua 原子操作才是安全边界的最后一道闸。不写对那几行 Lua，其他都白搭。
