必须用Lua脚本原子校验value一致性后再PEXPIRE：先GET锁值，比对是否等于当前客户端唯一标识（如UUID），一致才执行PEXPIRE，否则返回0，杜绝误续他人锁。
Redis Lua脚本里怎么安全续期分布式锁？
直接用 EXPIRE 续期会出竞态：客户端A刚判断锁快过期，还没执行 EXPIRE 就被B删掉了锁。必须把「检查锁归属 + 设置新过期时间」做成原子操作——只能靠 Lua 脚本。
核心逻辑是：先用 GET 拿当前锁值（即客户端唯一标识），比对是否和自己一致；一致才 PEXPIRE，否则返回失败。不能用 SET key value EX seconds NX，因为它不检查旧值，会覆盖别人持有的锁。
- 脚本必须校验锁的 value（比如 UUID 或 client_id），不是只看 key 是否存在
- 推荐用毫秒级过期（
PEXPIRE），避免秒级精度导致临界窗口变大 - Lua 中不要用
redis.call("GET", KEYS[1]) == ARGV[1]，因为返回 nil 时比较会报错，要用if stored == ARGV[1] then
local stored = redis.call("GET", KEYS[1])
if stored == ARGV[1] then
return redis.call("PEXPIRE", KEYS[1], ARGV[2])
else
return 0
end
超时后重试时如何避免重复加锁或死锁？
重试不是无脑循环 EVAL，得配合客户端侧的「锁失效判定」和「退避策略」。Redis 本身不维护锁状态历史，超时后原锁自动消失，但客户端可能还在等响应——这时重试等于新建锁，要防止业务逻辑被重复执行。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 每次加锁必须生成全局唯一 value（如
java.util.UUID.randomUUID().toString()），不能复用固定字符串 - 重试前检查上一次锁操作是否已实际生效（例如记录本地 start time，超时后只重试未确认成功的请求）
- 首次加锁用短 TTL（如 3000ms），后续续期可延长，但重试间隔建议从 10ms 指数退避到最大 500ms
- 服务端脚本返回值必须区分：1=续期成功，0=锁不属于你，nil=key 不存在（说明锁已释放）
为什么不能在 Lua 里用 while true 做自旋重试？
Redis 是单线程执行 Lua 脚本，while true 会彻底卡住整个 Redis 实例，所有命令阻塞，这不是超时问题，是服务中断。
- Lua 脚本必须是纯计算、无阻塞、有限步数的——它没有 sleep、没有网络调用、不能依赖外部状态
- 重试逻辑必须由客户端控制，Redis 只做「这一次操作是否成功」的原子反馈
- 如果脚本运行超时（默认 5s），Redis 会强制终止并返回
(error) BUSY Redis is busy running a script，此时客户端应放弃本次操作，而非继续重试该脚本
Java/Jedis 调用续期脚本的实际参数怎么传？
Jedis 的 eval 方法要求明确分离 KEYS 和 ARGV，顺序错一个就逻辑错。锁 key 是 KEY，客户端 ID 和新过期毫秒数是 ARGV，且必须按脚本里索引顺序来。
-
KEYS[1]→ 锁的 key 名（如"lock:order:123"） -
ARGV[1]→ 当前客户端唯一标识（如"a4f2-8c9e-4b1d"） -
ARGV[2]→ 新的 PEXPIRE 毫秒数（如6000，不是 6） - 别把 client_id 放进 KEYS，Redis Cluster 不允许 KEYS 包含动态值
jedis.eval(script,
Collections.singletonList("lock:order:123"),
"a4f2-8c9e-4b1d", "6000");
真实场景中，最难的不是写对脚本，而是让客户端准确感知「锁已丢失但业务尚未回滚」这个中间态——这时候续期返回 0，但业务可能已经走到一半。这种状态需要额外借助本地标记或事务日志来兜底。 
