Redis分布式锁需闭环管理生命周期：加锁用SET key value NX EX seconds保证原子性，value为唯一标识；解锁用Lua脚本校验再删；设合理过期时间并启用Watch Dog续期；高可用依赖哨兵/集群，强一致场景用RedLock。
Redis 分布式锁不是“加个 SETNX 就完事”，真正落地时，死锁、误删锁、锁提前释放等问题频发。核心不在命令本身，而在锁的生命周期管理是否闭环——从加锁原子性、持有身份校验、超时控制，到故障恢复和集群一致性，缺一不可。
加锁必须带唯一标识 + 自动过期
只用 SETNX 或分开执行 SET + EXPIRE 是危险的：前者不支持设置过期时间，后者非原子，可能键设成功但过期没设上，导致永久锁死。
- 正确写法是使用
SET key value NX EX seconds，一步完成“存在则失败 + 值写入 + 过期设定” - value 必须是全局唯一标识（如 UUID + 线程 ID），后续释放锁时靠它验证归属，避免误删
- 过期时间不能拍脑袋定，需结合业务最长耗时 + 安全冗余（建议至少比 P99 耗时多 2–3 倍）
解锁必须原子校验再删除
先 GET 再 DEL 是典型并发漏洞：GET 到自己的 value，刚要 DEL 时锁已过期，别人抢锁成功，你 DEL 的其实是别人的锁。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 必须用 Lua 脚本封装校验与删除逻辑，保证“读-判-删”不可分割
- 脚本示例：
if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end - 客户端调用该脚本时，传入锁 key 和自己加锁时写的 value，返回 1 表示删除成功，0 表示锁已被他人持有或不存在
业务执行中锁不能“静默失效”
锁过期时间短于业务实际耗时，会导致锁自动释放后别人加锁成功，原线程继续执行并释放新锁——数据错乱由此产生。
- 手动实现 Watch Dog：加锁后起守护线程，每
过期时间 / 3检查一次锁归属，若仍属自身则用EXPIRE重置过期时间 - 推荐直接用 Redisson：内置看门狗机制，默认 30 秒锁过期，每 10 秒自动续期，业务结束才停续期
- 注意：续期操作本身也需校验锁归属，防止主从切换后向旧主续期（Redisson 已处理该细节）
高可用不能只靠单实例
单点 Redis 宕机，所有锁服务瘫痪；主从异步复制下主节点崩溃未同步锁，从节点升主后锁丢失——两种情况都会引发并发失控。
- 基础保障：部署哨兵模式或 Redis Cluster，确保服务不中断
- 强一致性场景：采用 RedLock 算法，向 ≥3 个物理隔离的 Redis 实例加锁，多数（N/2+1）成功才算加锁成功
- 降级策略：锁获取失败时，可走本地限流、排队队列或业务层幂等兜底，避免雪崩
