⭐ 题目日期：

阿里 - 2024/8/21

📝 题解：

在 Redis 主从架构中，分布式锁的实现会面临主从异步复制导致的数据不一致风险，这可能破坏锁的互斥性和安全性。以下是主从部署对分布式锁的影响及应对策略：

---

1. 主从异步复制的核心问题

Redis 主从复制是异步的，主节点写入数据后，从节点可能未及时同步锁信息。当主节点宕机时，从节点晋升为新主，可能导致以下问题：

场景示例：

1. 客户端 A 在主节点成功获取锁 lock:1（写入主节点内存）。
2. 主节点在同步锁信息到从节点前宕机。
3. 从节点晋升为新主节点，但新主节点上无 lock:1。
4. 客户端 B 向新主节点申请锁 lock:1，成功获取，导致锁互斥性失效（A 和 B 同时持有锁）。

---

2. 主从架构下的锁风险

问题	原因	后果
锁丢失	主节点未同步锁到从节点，主宕机后从节点无锁信息。	多个客户端同时持有锁，互斥失效。
脑裂（Split Brain）	网络分区导致主从分离，客户端可能向旧主和新主同时获取锁。	锁状态不一致，资源竞争。

---

3. 解决方案

(1) RedLock 算法（推荐）

Redis 官方提出的 RedLock 算法通过在多个独立 Redis 节点上获取锁，降低主从异步复制的风险。
实现步骤：

1. 客户端向 5 个独立 Redis 节点（非主从关系）依次请求锁。
2. 若多数节点（≥3）成功获取锁，且总耗时小于锁的过期时间，则锁获取成功。
3. 锁的有效期需覆盖网络延迟和时钟漂移（例如初始超时时间为 10 秒，实际有效期为 10 秒 - 获取锁的总耗时）。

优点：容忍少数节点故障，降低主从切换风险。
缺点：实现复杂，需部署多个独立节点，性能较低（需多次网络通信）。

(2) 使用强一致性存储

对锁的可靠性要求极高的场景（如金融交易），可选择基于 Raft/Paxos 协议的分布式系统（如 ZooKeeper、etcd），它们通过强一致性保证锁的互斥性，但性能低于 Redis。

(3) 业务层容错

• 幂等性设计：即使锁失效导致资源重复操作，业务逻辑需保证结果正确（如订单去重）。
• 锁续期（Watchdog）：客户端持有锁时，定期续期（如 Redisson 的看门狗机制），防止锁因主从切换而过期。

---

4. Redis 主从架构下的锁优化实践

(1) 配置参数优化

• min-slaves-to-write：主节点需至少同步到 N 个从节点后才响应写操作（牺牲可用性换一致性）。
• min-slaves-max-lag：限制从节点同步延迟时间（如 10 秒），避免主节点写入高延迟的从节点。

(2) 结合哨兵（Sentinel）或集群模式

• 哨兵模式：通过哨兵监控主节点状态，主宕机时自动切换从节点为新主，需结合 RedLock 增强锁可靠性。
• 集群模式：数据分片存储，分布式锁需绑定到特定哈希槽，仍需配合 RedLock 使用。

---

5. 示例：Redisson 的 RedLock 实现

// 配置多个独立 Redis 节点（非主从）
Config config1 = new Config();
config1.useSingleServer().setAddress("redis://node1:6379");
RedissonClient client1 = Redisson.create(config1);

Config config2 = new Config();
config2.useSingleServer().setAddress("redis://node2:6379");
RedissonClient client2 = Redisson.create(config2);

// 创建 RedLock
RLock lock1 = client1.getLock("lock_key");
RLock lock2 = client2.getLock("lock_key");
RedissonRedLock redLock = new RedissonRedLock(lock1, lock2);

// 获取锁（需多数节点成功）
redLock.lock();
try {
    // 执行业务逻辑
} finally {
    redLock.unlock();
}

---

6. 主从架构下的选择建议

场景	推荐方案
对锁可靠性要求高	RedLock 算法 + 多独立节点
对性能要求高	单节点 Redis + 主从容灾（接受极低概率的锁失效）
强一致性需求	ZooKeeper/etcd
已部署 Redis 集群	结合集群分片与 RedLock 增强可靠性

---

总结

Redis 主从架构下的分布式锁存在锁丢失和脑裂风险，核心矛盾在于异步复制与一致性的不可兼得（CAP 定理）。

• 常规场景：可接受极低概率的锁失效时，使用主从架构 + 锁续期机制。
• 关键场景：需通过 RedLock 算法或强一致性存储（如 ZooKeeper）确保锁的可靠性，但需权衡实现复杂度和性能成本。
• 终极方案：根据业务需求，在一致性、可用性、分区容忍性之间找到平衡点。