Redis 的 Red Lock 是什么？你了解吗？

RedLock红锁面试结构化回答是什么单机Redis主从的分布式锁有缺陷客户端在master拿到锁锁还没同步到slavemaster宕机slave升级新主锁直接丢失多个客户端同时获取锁破坏互斥性。RedLock是Redis作者提出的多节点分布式锁算法目的解决主从切换丢锁问题。关键点5个完全独立的Redis主节点不能有主从复制关系依靠多数派quorum机制不是Raft/Paxos一致性算法。完整加锁流程N5记录加锁开始时间戳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停顿、线上很少用。