RedLock（红锁）面试结构化回答
是什么
单机Redis+主从的分布式锁有缺陷：客户端在master拿到锁，锁还没同步到slave，master宕机，slave升级新主，锁直接丢失，多个客户端同时获取锁，破坏互斥性。
RedLock是Redis作者提出的多节点分布式锁算法，目的解决主从切换丢锁问题。
关键点：5个完全独立的Redis主节点，不能有主从复制关系，依靠多数派（quorum）机制，不是Raft/Paxos一致性算法。
完整加锁流程（N=5）
- 记录加锁开始时间戳T1
- 向5个独立Redis节点 并行发起加锁，命令依旧是
SET key 唯一值 NX EX；每个节点请求设置很短超时，防止卡死在故障节点。 - 统计成功加锁节点数量，必须大于半数，也就是至少3个节点加锁成功；同时，整个加锁消耗的总时间，必须小于锁过期时间。两个条件同时满足才算拿到锁。
- 锁真实有效时间 = 设置的TTL − 加锁耗时。
- 如果加锁失败，立刻向全部5个节点执行Lua脚本释放锁，清理残留锁。
释放锁
向所有节点执行Lua脚本释放锁，校验value是自己的才删除，不管该节点之前加锁成功还是失败。
RedLock存在的争议与缺陷（面试重点）
-
强依赖系统时钟
如果节点发生时钟跳变（NTP时间校正），锁会提前过期失效，破坏互斥性。
-
无法解决客户端GC停顿、网络延迟问题
就算红锁拿到锁，如果客户端发生长时间FullGC、网络阻塞，业务没跑完锁过期，其他客户端依旧能拿到锁；红锁解决不了客户端侧停顿问题，也没有生成单调递增的防篡改fencing令牌，无法给下游资源做校验。
-
运维成本很高
需要维护5套独立Redis实例，资源消耗大；性能下降，一次加锁要和多节点网络交互。
著名辩论：分布式专家Martin Kleppmann质疑RedLock的安全性；Redis作者认为它适合"追求效率，允许极小概率出错"场景，绝对强一致性场景不要用RedLock。
线上实践结论
- 绝大多数业务线上几乎不用RedLock。
- 如果业务可以容忍极小概率锁失效，直接用单机Redis + Redisson（看门狗续期），简单好用。
- 如果要求绝对不能出现并发问题，放弃Redis，选用 Zookeeper / Etcd，基于一致性协议实现分布式锁。
总结
RedLock想用多节点多数派解决单机主从切换丢锁，但本身依赖系统时间，有安全漏洞，运维成本高；工程实践很少落地，强一致性场景优先用ZK/Etcd。
面试记忆点：5个独立主节点、半数成功、时钟漂移缺陷、不能解决客户端GC停顿、线上很少用。