redis实现红锁

红锁（RedLock）的设计与实现
在N个独立Redis节点（非Cluster模式）中，当客户端在半数以上节点成功获取锁，且总耗时小于锁有效期时，才认为锁获取成功。

实现步骤详解
假设部署5个Redis节点（N=5）：

获取当前时间：记录开始时间T1（毫秒精度）

依次向所有节点申请锁：

SET lock_key valueNX PX $tt

NPC争议问题
红锁算法自诞生起就伴随着**N（网络延迟）、P（进程暂停）、C（时钟漂移）**三个核心争议，这些现实世界中的不确定因素，动摇了红锁在数学意义上的绝对安全性。

网络延迟（Network Delay）的致命时间差
问题场景：

客户端在节点A、B、C成功获取锁，总耗时48ms（小于TTL 50ms）

但由于跨机房网络波动，实际锁在节点上的有效时间存在差异：

节点A记录的锁过期时间：客户端本地时间+50ms = T+50
节点B因网络延迟，实际锁过期时间为T+52
节点C因网络拥塞，实际锁过期时间仅T+48
在时间窗口T+48到T+50之间，客户端认为锁仍有效，但节点C的锁已提前失效

后果：
其他客户端可能在此期间获取节点C的锁，导致锁状态分裂，多个客户端同时进入临界区。

进程暂停（Process Pause）的「薛定谔锁」
经典案例：/ 伪代码：获取锁后执行业务逻辑 if (redLock.tryLock()) { // 触发Full GC暂停300ms System.gc(); // 此时锁已过期，但客户端仍在写数据 updateInventory(); }

关键时间线：

T0: 获取锁（TTL=200ms）
T0+100ms: 进入GC暂停，持续300ms
T0+400ms: GC结束，继续执行业务逻辑
锁实际在T0+200ms已失效，但客户端在T0+400ms仍以为自己持有锁
数据灾难：
其他客户端在T0+200ms到T0+400ms期间可能修改数据，导致最终结果错乱。

时钟漂移（Clock Drift）的时空扭曲

连锁反应：

客户端计算锁有效期基于本地时钟（假设为T+100ms）
但节点B的时钟比实际快30秒，导致其记录的锁过期时间为T-29000ms
锁在客户端认为的有效期内提前被节点B自动释放
行业领袖的正面交锋
Martin Kleppmann（《数据密集型应用设计》作者）：

“红锁依赖的假设——『客户端能准确感知锁存活时间』，在异步分布式系统中根本无法保证。即使没有节点故障，NPC问题也会导致锁状态的不确定性。”

Antirez（Redis作者）的反驳：

"工程实践中可以通过以下手段控制风险：

使用带温度补偿的原子钟硬件
禁用NTP服务的时钟跳变调整
监控进程暂停（如GC日志分析）
为锁TTL设置冗余缓冲时间（如额外20%）"