Redis分布式锁续期不能只靠SETEX，因其仅支持单次设过期时间，业务超时会导致锁提前释放、并发冲突；必须用Lua脚本原子校验token并续期，且看门狗需与业务线程强绑定、及时退出。
Redis分布式锁续期为什么不能只靠 SETEX？
因为 SETEX 只能设一次过期时间，锁持有者在业务执行中若超时，锁会提前释放，导致其他节点误入临界区。真实场景里，一个支付核验可能耗时 3–8 秒，而你设的 5 秒过期时间根本不够——这不是锁没用，是没配“看门狗”。
续期必须满足三个条件：仅锁的持有者能续、续期操作原子、续期失败要可感知。直接用 EXPIRE 不安全：它不校验 value，A 拿到锁后崩溃，B 重抢成功，此时 A 的续期线程若还在跑，就会把 B 的锁又续上。
所以必须用 Lua 脚本封装「判断 value 是否匹配 + 设置新过期时间」两个动作，让 Redis 一次性执行。
用 Lua 脚本实现安全续期的最小可行代码
核心逻辑：读取当前 key 的 value，比对是否等于客户端唯一标识（如 UUID），相等才执行 EXPIRE，否则返回 0 表示续期失败。
if redis.call("get", KEYS[1]) == ARGV[1] then
return redis.call("expire", KEYS[1], ARGV[2])
else
return 0
end
调用时传入：KEYS[1] 是锁 key（如 "order:lock:123"），ARGV[1] 是当前客户端的随机 token（不是固定字符串！），ARGV[2] 是新过期秒数（比如 30）。
常见错误：
- 用固定字符串当 token（所有实例用同一个值，续期失去身份校验）
- 在 Lua 里用
redis.call("set", ...)替代expire（会覆盖 value，破坏锁持有者身份） - 没检查脚本返回值，续期失败也不告警，导致锁静默失效
看门狗线程怎么启动和退出才不翻车？
看门狗本质是一个后台线程（或协程），定时（比如每 10 秒）尝试续期，但它不是无脑循环——必须和业务线程强绑定。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
关键设计点：
- 锁获取成功后才启动看门狗，且把 token 和 key 存进当前线程上下文（如
ThreadLocal或 contextvar） - 业务执行结束（无论正常 return 还是抛异常），必须显式调用
unlock()，里面除了删 key，还要中断看门狗线程（如设置标志位 +interrupt()） - 看门狗每次续期前先检查业务线程是否还存活（
isAlive()或检查中断状态），避免业务已结束但续期还在跑
漏掉退出逻辑的后果很直接：JVM 进程里残留一堆空转的看门狗线程，CPU 白白占用，还可能在锁已释放后继续续期，干扰下一轮加锁。
Redission 的 watchdogTimeout 到底在控制什么？
如果你用 Redission，它的自动续期默认每 10 秒触发一次，续期时间为 lockWatchdogTimeout（默认 30 秒）。这个值不是“锁总时长”，而是每次续期后重置的 TTL。
注意两个易混淆点：
-
lockWatchdogTimeout必须大于业务最大预期耗时，但不宜过大（比如设成 3600），否则锁泄漏后要等很久才自动释放 - 它和你调用
tryLock(waitTime, leaseTime, TimeUnit)中的leaseTime冲突：如果指定了leaseTime > 0，watchdog 就不会启动，锁到期即销毁，不再续期
换句话说：想用看门狗，就别传 leaseTime；想精确控制锁生命周期（比如强制 5 秒后不管业务完没完都释放），那就关掉 watchdog，自己处理超时逻辑。
最麻烦的其实是锁重入场景——多个嵌套加锁时，watchdog 续的是最外层锁的 TTL，内部锁的释放不减计数，也不影响续期节奏。这点在调试时容易误判为“续期没生效”。
