本篇继续深耕 Redis 分布式锁进阶内容，重点拆解 Redisson 可重入分布式锁的底层设计逻辑，同时结合原理手写一套具备生产可用性的可重入锁实现，覆盖数据结构、Lua 原子脚本、看门狗续期、发布订阅唤醒等核心能力，补齐实战落地要点。
一、Redisson 可重入锁底层设计解析
1. 核心数据结构
Redisson 并没有使用简单的 String 类型实现分布式锁，而是选用Hash结构，这也是它支持可重入的核心基础。
- 外层 Key：全局唯一的锁名称，用来区分不同业务锁，例如
lock:goods:stock。 - Hash 的 Field：当前持有锁的线程唯一标识，一般由客户端 ID + 线程 ID 拼接而成，精准标记锁的归属。
- Hash 的 Value：当前线程的锁重入次数，线程首次加锁值为 1，多次重入则持续累加，解锁时逐步递减。
这种结构优势十分明显：既能精准判断锁持有者，避免误删他人锁；又天然支持同一线程反复加锁，完美适配方法嵌套调用的场景；同时只有重入次数归零时，才会真正删除锁 Key，保证解锁逻辑严谨。
2. 看门狗自动续期机制
这是 Redisson 解决业务执行超时导致锁提前释放 的关键机制。 当我们调用无超时时间的lock()方法加锁时，看门狗会自动激活。加锁成功后，框架会启动一个后台定时任务，默认每 10 秒执行一次，主动将锁的过期时间重置为 30 秒。只要业务线程还在运行，锁就会持续续期；一旦业务执行完毕、线程结束，定时任务会随之停止，不再继续续期。 如果手动指定了锁的过期时间，看门狗机制会直接失效，由业务自行把控锁生命周期。
3. 发布订阅阻塞唤醒
常规分布式锁实现中，加锁失败的线程会不断循环自旋尝试加锁，空耗 CPU 资源。Redisson 对此做了优化，引入 Redis 发布订阅模式。 加锁失败的线程不会持续轮询，而是订阅当前锁对应的消息频道，进入阻塞等待状态。当锁持有者执行解锁操作后，会向频道推送锁释放的消息，所有阻塞等待的线程收到通知后，再重新发起锁竞争，大幅降低无效轮询带来的性能损耗。
4. Lua 脚本保证原子性
加锁、重入、解锁等操作都涉及多条 Redis 命令组合，在高并发场景下极易出现竞态问题。Redisson 将整套逻辑封装在Lua 脚本中执行，Redis 会把整个脚本当作一个原子命令执行，中间不会被其他请求打断，从底层规避并发安全问题。
二、可重入锁 Lua 脚本实现
1. 加锁脚本
实现锁创建、线程重入、过期时间设置三大逻辑，全程原子执行。