直接用setnx+定时续期不可靠，因客户端卡顿、gc或网络分区会导致续期失败而锁过期；lua脚本在redis端原子执行校验value并续期，确保互斥性。
为什么直接用 SETNX + 定时续期不可靠？
因为客户端自己维护心跳续期，一旦进程卡住、GC停顿或网络分区，续期请求发不出去，锁就提前过期，其他客户端趁虚而入，导致并发冲突。Lua 脚本在 Redis 服务端原子执行，能避免“检查锁归属 + 延长过期时间”这两步被拆开——这是自动续期可靠性的前提。
EVAL 中如何安全续期？只续自己持有的锁
续期不是无条件延长 TTL，必须先校验锁的 value（通常是唯一随机字符串）是否匹配当前客户端。否则 A 客户端误续了 B 的锁，等于主动破坏互斥性。
推荐脚本逻辑：
- 用
GET拿当前锁值，与传入的lock_value比较 - 相等才执行
EXPIRE，返回 1；不等返回 0 - 不使用
GETSET或SET ... XX，它们无法同时完成校验和续期
示例脚本（保存为 renew_lock.lua）：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
if redis.call("GET", KEYS[1]) == ARGV[1] then
return redis.call("EXPIRE", KEYS[1], tonumber(ARGV[2]))
else
return 0
end
调用方式：redis-cli --eval renew_lock.lua my:lock , "abc123" 30
客户端怎么配合 Lua 实现“自动”续期？
自动 ≠ 完全无感，而是由客户端在持有锁期间启动一个独立的心跳协程/线程，定期调用上述 Lua 脚本。关键点：
- 续期间隔建议设为锁 TTL 的 1/3～1/2（如 TTL=30s，每 10s 续一次），留出网络和执行余量
- 心跳任务必须可取消：一旦业务逻辑执行完、或检测到锁已丢失（脚本返回 0），立即停止续期
- 不要在主线程阻塞等待续期结果；失败时应记录日志，但不中断业务流程（续期失败≠立刻释放锁，只是失去保障）
- 若用 Java，
Redisson的RLock.lock(...)默认开启看门狗机制，底层就是类似逻辑；自行实现时需注意Netty线程模型与定时任务线程池的隔离
哪些情况会让续期 Lua 失效？
脚本本身没问题，但现实环境会绕过它：
- Redis 主从切换期间，从库升主瞬间丢失所有键（尤其未开启
min-replicas-to-write），原锁凭空消失 - 客户端时间不同步：本地生成的锁 value 带时间戳用于防重放，但若系统时钟回拨，可能误判锁过期
- 脚本超时：
lua-time-limit默认 5 秒，续期脚本虽简单，但若 Redis 正在执行慢查询或内存紧张，可能被强制中断，返回ERROR BUSY - 锁 key 被手动
DEL或被 LRU 淘汰（不建议对锁 key 设置volatile过期以外的淘汰策略）
真正难处理的是主从不一致场景，单靠 Lua 无法解决，需要结合 Redlock 或更严格的共识协议——但这已经超出“自动续期”的范畴了。
