Redis分布式锁高并发下饿死请求的根本原因是续期机制与过期时间不匹配、客户端异常未释放锁，且重试无退避和超时兜底；须用随机退避、总等待超时、Lua原子删锁，单节点自动续期锁比Redlock更稳。
Redis分布式锁为什么会在高并发下饿死某个请求
根本原因是锁的续期机制和过期时间设计不匹配，加上客户端异常退出后锁未释放，导致后续请求反复抢不到锁。典型表现是日志里一堆 SETNX failed 或 ERR NOAUTH（其实是锁被别人占着但没续上），而某个请求卡在 while (tryLock() == false) 里一直轮询。
关键不是“加锁失败”，而是“失败后没退避+没兜底超时”。常见错误是用固定间隔重试，比如每100ms试一次，结果200个请求全挤在同一毫秒窗口撞 SETNX，Redis单线程反而成了瓶颈。
- 必须给重试加随机退避：比如
Thread.sleep((long)(50 + Math.random() * 150)) - 客户端本地记录锁申请开始时间，总等待超过
lockTimeout（比如3s）就直接放弃，避免无限卡住 - 不要依赖
DEL手动删锁——得用 Lua 脚本保证“判断+删除”原子性，否则可能删掉别人刚续上的锁
Redlock算法在实际业务中是否真能防饥饿
不能。Redlock 的设计目标是容错，不是公平性或低延迟。它要求多数节点成功才算加锁成功，但网络抖动时，部分节点响应慢会导致整体加锁耗时飙升，反而加剧饥饿——尤其当你的 Redis 集群跨机房部署时，一个节点 RTT 到 200ms，5 节点里 3 个要等齐，光网络就吃掉 400ms+。
真实业务里，99% 的场景用单节点带自动续期的锁更稳。Redlock 带来的复杂度（时钟漂移校验、各节点时间同步、失败回滚逻辑）远大于收益。
- 如果必须用 Redlock，请把
quorum设为(nodes.length / 2) + 1后再减1，容忍一个节点临时失联 - 每次尝试加锁前，先用
TIME命令比对各节点时间差，超 50ms 直接跳过该节点 - 永远不要在 Redlock 成功后，再用
EXPIRE去设过期时间——Redlock 自身已含 TTL，重复设置会覆盖原值
如何用 Lua 脚本实现带续期的可重入锁
可重入的核心是记录持有者标识（比如 clientID:threadID）和重入次数，而不是简单存个布尔值。续期操作必须检查当前锁是否为自己所持，否则变成“帮别人续命”。
典型错误是把续期逻辑写在客户端：先 GET 锁值，再判断，再 EXPIRE——这三步非原子，中间锁可能已被别人抢走并修改。
- 加锁脚本里用
SET key value EX seconds NX，value 固定为clientID:threadID:count - 续期脚本用
EVAL执行 Lua：先GET，匹配 clientID，再EXPIRE，不匹配直接返回 0 - 解锁脚本必须用同一段 Lua：判断 value 是否一致，一致才
DEL，否则返回失败——这是防误删的唯一可靠方式
示例续期 Lua：
if redis.call("GET", KEYS[1]) == ARGV[1] then return redis.call("EXPIRE", KEYS[1], ARGV[2]) else return 0 end
业务代码里怎么安全地调用带续期的锁
最容易被忽略的是“锁生命周期和业务执行周期不一致”。比如你设了 30s 过期，但某次数据库慢查询卡了 35s，锁自动过期，后面的操作就裸奔了。
正确做法是：锁对象本身要持有续期任务句柄，业务执行期间持续心跳；一旦业务完成或异常，立即停续期+主动解锁。
- 不要在 try 块外启动续期线程——try 失败时锁根本没拿到，续期会污染数据
- 续期间隔建议设为
lockExpire / 3（比如 30s 锁，每 10s 续一次），留出网络和 GC 波动余量 - 捕获
InterruptedException或TimeoutException后，必须调用unlock()，且 unlock 内部要判断锁是否还属于自己（靠 Lua 脚本返回值）
真正难的不是写对脚本，而是让每个业务方法都记得在 finally 里 stopRenewal() + unlock()。漏掉一次，就可能埋下一个定时锁饥饿炸弹。
