ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花

红锁(RedLock)是Redis官方提出的分布式锁算法，由Redis作者Salvatore Sanfilippo(antirez)于2014年设计，旨在解决传统单节点Redis锁在分布式环境中的可靠性问题，尤其针对主从复制场景下的锁丢失风险。

一、核心背景与问题

传统单节点Redis锁通过SET key value NX PX ttl命令实现，但存在致命缺陷：

• 主节点宕机时，若从节点尚未同步锁数据，主从切换会导致锁丢失
• 单点故障直接导致整个锁服务不可用

红锁通过多节点冗余+多数派共识机制，彻底解决这些问题。

二、核心设计思想

红锁借鉴分布式一致性算法(Paxos/Raft)的多数派原则，核心思路：

部署N个完全独立的Redis主节点(通常为5个，奇数个)，客户端必须在超过半数(N/2+1)节点上成功加锁，才算真正获得锁。

这样即使部分节点故障(≤N/2-1)，锁服务仍能正常运行，且不会出现锁丢失问题。

三、完整工作流程

1. 加锁流程 🔒

2. 解锁流程 🗝️

1. 向所有Redis节点发送解锁命令：EVAL "if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end" 1 key UUID
2. 无论节点是否加锁成功，都必须发送解锁命令，确保清理所有可能的残留锁

3. 锁续期 ⏳

• 加锁成功后，客户端需在锁过期前完成业务操作
• 若操作超时，可通过向成功加锁的节点发送续期命令延长锁有效期
• 续期失败时应立即放弃操作并解锁

四、部署与配置要求

1. 节点数量：推荐5个独立Redis主节点(奇数)，确保多数派(3个)能形成有效共识
2. 节点独立性：无主从复制关系，完全独立运行物理上分布在不同服务器/机房，避免单点故障
3. 客户端实现：必须使用相同的key和UUID向所有节点申请锁加锁超时时间应远小于锁的TTL，防止网络延迟导致误判

五、红锁 vs 单节点Redis锁

六、优缺点分析

优点 ✅

1. 高可用性：容忍部分节点故障，锁服务持续可用
2. 安全性：多数派原则确保不会出现锁丢失或重复获取问题
3. 分布式一致性：借鉴Paxos/Raft思想，提供更强的一致性保障

缺点 ⚠️

1. 部署成本高：需要多个独立Redis节点，运维复杂度增加
2. 性能开销大：多次网络往返，延迟高于单节点锁
3. 时钟同步要求：节点间时钟偏差过大会导致锁有效性判断错误，需配置NTP服务同步时间
4. 存在争议：分布式系统专家对红锁的安全性存在学术争议，需结合业务场景评估

七、适用场景

1. 核心业务：支付、订单、库存等对数据一致性要求极高的场景
2. 高可用需求：需要避免单点故障导致业务中断的系统
3. 跨区域部署：分布式系统中节点分布在不同机房/地区的场景

八、Java实现示例(Redisson)

// 1. 创建5个独立Redis客户端
Config config1 = new Config();
config1.useSingleServer().setAddress("redis://192.168.1.1:6379");
RedissonClient client1 = Redisson.create(config1);

// 同理创建client2, client3, client4, client5...

// 2. 获取各节点锁对象
RLock lock1 = client1.getLock("myLock");
RLock lock2 = client2.getLock("myLock");
RLock lock3 = client3.getLock("myLock");
RLock lock4 = client4.getLock("myLock");
RLock lock5 = client5.getLock("myLock");

// 3. 创建红锁
RedissonRedLock redLock = new RedissonRedLock(lock1, lock2, lock3, lock4, lock5);

// 4. 加锁(最多等待100秒，自动释放30秒)
boolean isLocked = redLock.tryLock(100, 30, TimeUnit.SECONDS);
if (isLocked) {
    try {
        // 执行业务逻辑
        processOrder();
    } finally {
        // 5. 解锁
        redLock.unlock();
    }
}

九、关键注意事项

1. 时间同步：所有Redis节点和客户端必须通过NTP服务同步时间，误差控制在50ms以内
2. 锁超时设置：TTL应根据业务实际耗时设置，避免过短导致锁提前释放，过长导致死锁风险
3. 失败处理：加锁失败时必须立即解锁所有节点，防止残留锁影响其他客户端
4. 网络分区：需处理网络分区导致的节点通信失败，避免误判锁状态
5. 性能优化：可通过异步请求多个节点提高加锁效率，减少延迟

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花