Redis篇（十三）：Sentinel 故障转移、脑裂问题与 RedLock

一、Sentinel 故障转移全流程

Redis Sentinel 是 Redis 的高可用解决方案，负责监控主从节点、自动故障转移、通知客户端。

1.1 故障检测：主观下线与客观下线

主观下线（SDOWN）：

Sentinel 每 1 秒向主从节点发送 PING 命令 ↓ 节点超时未响应（默认 down-after-milliseconds: 5000ms） ↓ 单个 Sentinel 标记为「主观下线」

客观下线（ODOWN）：

Sentinel 向其他 Sentinel 发送 SENTINEL is-master-down-by-addr 询问 ↓ 多数 Sentinel 同意该节点已下线 ↓ 标记为「客观下线」，触发故障转移

1.2 Leader 选举：Raft 共识算法

Sentinel 集群中需要选举一个 Leader 来执行故障转移：

发现客观下线的 Sentinel 成为候选者 ↓ 候选者向其他 Sentinel 发送拉票请求 ↓ 每个 Sentinel 只有一票（可投给自己或他人） ↓ 获得半数以上票数 → 成为 Leader

Raft 算法核心：

• 候选者（Candidate）：发现客观下线的 Sentinel 发起选举
• 投票（Vote）：每个 Sentinel 只能投一票，先到先得
• 任期（Term）：每次选举递增任期号，防止旧 Leader 干扰

1.3 新主节点选择

Leader 从从节点中选择新主，进行三轮考察：

1.4 故障转移执行

① 新主节点晋升 ↓ ② 向其他从节点发送 SLAVEOF new_master 命令 ↓ ③ 向 +switch-master 频道发布新主信息 ↓ ④ 客户端订阅该频道，自动切换到新主 ↓ ⑤ 旧主节点重新上线后，Sentinel 发送 SLAVEOF 降级为从

1.5 Sentinel 典型架构

3 个 Sentinel 节点 + 1 主 + 2 从（最小高可用配置） Sentinel 节点数应为奇数，至少 3 个，避免脑裂

二、脑裂问题：成因、影响与解决方案

2.1 什么是脑裂？

脑裂场景：

主节点与所有从节点网络断开 ↓ 但主节点与客户端网络正常 ↓ 客户端继续向旧主写入数据 ↓ Sentinel 发现主节点失联，选举新主 ↓ 集群出现两个主节点（旧主 + 新主） ↓ 网络恢复后，旧主被降级为从，数据清空 ↓ 脑裂期间写入的数据全部丢失！

2.2 脑裂的影响

2.3 解决方案

方案一：min-slaves 限制（推荐）

# redis.conf# 当从节点数量少于 2 个，或复制延迟超过 10 秒时，主节点拒绝写请求min-slaves-to-write2min-slaves-max-lag10

原理：

• 脑裂发生时，旧主与从节点失联，从节点数量变为 0
• 触发 min-slaves-to-write 限制，旧主拒绝写请求
• 客户端收到错误，可将数据写入本地缓存或消息队列
• 新主上线后，数据写入新主，避免丢失

方案二：客户端降级处理

// 主节点不可写时，降级到本地缓存publicvoidwriteData(Stringkey,Stringvalue){try{redisTemplate.opsForValue().set(key,value);}catch(RedisCommandExecutionExceptione){// 主节点拒绝写入，降级到本地缓存localCache.put(key,value);// 异步同步到消息队列mqProducer.send(newCacheSyncMessage(key,value));}}

三、RedLock：多独立 Redis 实例实现分布式锁

3.1 为什么需要 RedLock？

在单机 Redis 中，分布式锁通过SET key value NX PX ttl即可实现。但在集群模式下，如果主节点宕机，从节点晋升为主节点，由于主从复制是异步的，锁数据可能丢失，导致多个客户端同时获取到锁。

RedLock（红锁）是 Redis 作者 Antirez 提出的分布式锁算法，基于多个独立的 Redis 实例构建分布式锁，即使部分实例故障，锁数据依然可靠。

3.2 RedLock 核心设计

关键要求：

• N 个完全独立、隔离的 Redis 实例（非 Cluster 节点）
• 官方推荐至少 5 个（奇数个）
• 节点之间没有任何关系（不同集群或单例部署）

⚠关键注意：Redis Cluster 节点不能用于 RedLock，因为 Cluster 节点不独立、不隔离。

3.3 RedLock 加锁流程

① 获取当前时间 t1（毫秒级时间戳） ↓ ② 依次向 N 个独立 Redis 实例发送 SET key value NX PX ttl ↓ ③ 每个实例设置加锁超时时间（远小于锁过期时间，如 10ms） ↓ ④ 统计成功加锁的实例数，获取当前时间 t2 ↓ ⑤ 成功条件：成功实例数 ≥ N/2+1 且 (t2-t1) < 锁过期时间 ↓ ⑥ 若成功：锁实际有效时间 = 过期时间 - (t2 - t1) - 时钟漂移补偿 ↓ ⑦ 若失败：向所有实例发送解锁脚本（Lua DEL）

3.4 RedLock 解锁流程

① 向所有 N 个 Redis 实例发送解锁请求 ↓ ② 使用 Lua 脚本保证原子性： "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end" ↓ ③ 即使部分实例解锁失败，锁最终也会因 TTL 过期而释放

3.5 Java 实现（Redisson）

Configconfig=newConfig();config.useRedLock().addNodeAddress("redis://192.168.0.1:7000").addNodeAddress("redis://192.168.0.2:7000").addNodeAddress("redis://192.168.0.3:7000").addNodeAddress("redis://192.168.0.4:7000").addNodeAddress("redis://192.168.0.5:7000");RedissonRedLockredLock=Redisson.create(config).getRedLock("myLock");try{booleanlocked=redLock.tryLock(10,30,TimeUnit.SECONDS);if(locked){// 执行业务逻辑}}finally{redLock.unlock();}

3.6 RedLock 的争议

RedLock 算法在社区中存在争议（Martin Kleppmann 的批评）：

实际应用建议：

• 大多数业务场景中，Redisson 的单机锁 + 看门狗已足够
• 金融级强一致性场景，建议使用 Zookeeper 或 Etcd
• RedLock 适合对可用性要求极高、可容忍轻微不一致的场景

如果本文对你有帮助，欢迎点赞 👍 + 收藏 ⭐ + 关注 🔖，你的支持是我持续创作的动力！