Redis 分布式锁入门：SET NX EX 与谁该解锁
知识背景
单机 synchronized 无法跨 JVM；分布式锁让多个服务实例互斥访问共享资源（库存、订单、定时任务抢跑）。Redis 因高性能常被用作锁存储；最简实现是 SET key value NX EX ttl（原子占坑 + 过期防死锁）。
生产环境还可选 Redisson、或 etcd/Zookeeper 等强一致协调服务，按业务对正确性要求选型。
知识详解与通俗解释
1. 正确姿势：一条命令原子完成
分两步 SETNX + EXPIRE 若中间进程崩溃会留下无过期的锁，别人永远进不来。SET lock:order:1 uuid NX EX 30 在单节点 Redis 上实现「不存在则设置，并 30 秒过期」。
2. value 为什么要唯一？
解锁时不能只 DEL lock，可能 误删别人的锁（自己的锁过期后，别人已抢到锁）。
安全做法：Lua 脚本原子地「GET 比较 value 再 DEL」，只有持有者能释放。
3. 续期与 Redlock
业务执行超过 TTL需要 看门狗续期（如 Redisson）；多主 Redlock 讨论较多，需读官方与社区对边界条件的分析，不要想当然「多节点就绝对安全」。
4. 与 DB 事务的关系
分布式锁不替代数据库唯一约束；防重 + 幂等 往往要 DB 唯一索引 / 状态机 兜底，锁只是减少冲突窗口。
通俗说：锁像厕所occupied牌；要带名字（uuid），走时只撕自己的牌；牌要自动过期防止人跑了牌还在。
总结
- SET NX EX 原子加锁；Lua 解锁 防误删。
- 注意 TTL、续期、单点 Redis 故障 与业务超时匹配。
- 高价值资金类场景要评估 是否需更强一致 的实现与 DB 约束。