主题切换
Redis分布式锁
一、落地使用场景
- 库存扣减（秒杀/商品下单）：分布式多实例并发，防止商品超卖。
- 定时任务防重复执行：集群部署定时任务，避免多节点同时执行同一任务。
- 接口幂等、重复请求拦截：拦截重复订单提交，保证请求只处理一次。
- 跨库事务串行化：分布式多数据源更新，串行执行避免数据错乱。
二、原生SET NX EX简易分布式锁原理
1. 加锁
SET lockKey 唯一标识 NX EX 过期时间- NX：Key不存在才写入，实现互斥特性。
- EX：主动设置过期时间，规避死锁。
- Value 存储当前线程唯一ID，用于解锁校验，防止误删其他线程的锁。
2. 解锁
必须使用 Lua脚本 解锁，保证判断+删除两步原子执行。先校验Value与当前线程标识一致，再执行删除。 不使用Lua会出现：判断通过后锁提前过期，进而误删其他线程的锁。
三、为什么必须设置过期时间
- 防止死锁：服务宕机、代码异常导致解锁逻辑无法执行，过期后Redis自动删除锁，避免锁永久占用。
- 应对JVM卡死、网络中断等异常场景，兜底释放锁资源。
四、锁有效期管控两种方案
- 预估业务耗时：过期时间设置为接口历史最大执行时长的1.5倍，实现简单，适用于常规短耗时业务。
- 看门狗续期（Redisson自动实现）： 默认加锁时长30s，后台定时任务每10s（剩余时长1/3）执行Lua脚本续期。业务正常执行则持续刷新过期时间，业务执行完毕手动解锁，看门狗停止工作。
五、Redisson分布式锁四大核心特性
1. 原子性
加锁、判断、续期、解锁全部通过Lua脚本实现。Redis单线程执行脚本，天然保证原子性，规避分步执行带来的异常问题。
2. 可重入锁
底层基于Hash数据结构实现：key=锁名，field=线程唯一ID，value=重入计数
- 同一线程重复加锁：计数加1。
- 重复解锁：计数减1，计数归0才真正删除锁。 解决嵌套方法重复加锁引发的死锁问题。
3. 自动看门狗续期
加锁成功后启动后台定时任务，按照规则自动续期，无需人工维护锁过期时间。
4. 主从一致性：RedLock红锁（AP/CP选型）
RedLock原理
部署多台独立Redis节点（无主从关系），客户端必须在半数+1节点上加锁成功，才算整体获锁成功；释放锁时逐个节点执行解锁操作，避免单节点宕机丢失锁。
CAP取舍
- 普通主从锁（主+从）：AP 可用性优先。主节点宕机，从节点自动晋升保证服务可用；但锁数据未同步至从节点，会出现锁失效，牺牲一致性。
- RedLock红锁：CP 一致性优先。过半节点加锁成功才算获锁，保证锁数据强一致；若集群半数以上节点故障，则加锁失败，牺牲部分可用性。
六、CAP & AP/CP 补充说明
- CAP理论：分布式系统无法同时满足一致性(C)、可用性(A)、分区容错性(P)。网络环境下分区容错(P)必然存在，系统只能在C和A之间二选一。
- AP（可用性优先）：代表为普通Redis主从锁，故障后服务仍可用，无法保证锁强一致性。
- CP（一致性优先）：代表为RedLock、Zookeeper临时节点锁，优先保证数据一致，集群大面积故障时服务不可用。
七、原生SET锁缺陷 & Redisson优化对比
| 原生setnx锁短板 | Redisson解决方案 |
|---|---|
| 需手动编写Lua脚本，易出错 | 内置Lua脚本，开箱即用 |
| 不支持可重入，嵌套加锁会产生死锁 | 基于Hash结构+计数，实现可重入 |
| 过期时间难以精准把控，业务超时易导致锁提前释放 | 看门狗机制自动续期 |
| 主从切换易出现锁丢失 | RedLock红锁保障多节点锁一致性 |
八、面试高频问题解析
问：Redis原生分布式锁如何实现，为什么要用Lua解锁？
答： 使用SET key value NX EX 命令加锁，value存线程ID。解锁必须用Lua脚本，保证判断和删除原子执行，防止锁过期后误删其他线程的锁。
问：分布式锁为什么一定要设置过期时间？
答： 防止服务宕机、代码异常等场景下无法正常解锁，造成死锁，依靠过期时间自动释放锁。
问：什么是看门狗，作用是什么？
答： 是Redisson的自动续期机制，加锁后定时刷新锁的过期时间，解决业务执行时长不确定、锁提前过期的问题，业务结束后自动停止续期。
问：Redisson如何实现可重入锁？
答： 底层使用Hash结构，以线程ID作为field，搭配重入计数器。同一线程多次加锁计数累加，多次解锁计数递减，计数归零才删除锁。
问：普通Redis主从锁和RedLock红锁有什么区别，对应CAP哪种选择？
答： 普通主从锁是AP架构，优先可用性，主从切换可能丢失锁；RedLock是CP架构，优先一致性，需过半节点加锁成功，集群多数故障则无法加锁。