Redis 脑裂（Split-Brain）

Redis 脑裂（Split-Brain）

• [一、Redis 脑裂的定义与本质](#一、Redis 脑裂的定义与本质)
• • [1.1 什么是 Redis 脑裂？](#1.1 什么是 Redis 脑裂？)
  • [1.2 Redis 的 CAP 原则](#1.2 Redis 的 CAP 原则)
• 二、脑裂发生的条件与架构影响
• • [2.1 哪些架构模式可能脑裂？](#2.1 哪些架构模式可能脑裂？)
• 三、哨兵模式脑裂分析
• • [3.1 Sentinel 的核心机制](#3.1 Sentinel 的核心机制)
  • [3.2 哨兵脑裂标准流程](#3.2 哨兵脑裂标准流程)
  • • 初始状态
    • 网络分区发生
    • [分区 A（少数派 Sentinel）](#分区 A（少数派 Sentinel）)
    • [分区 B（多数派 Sentinel）](#分区 B（多数派 Sentinel）)
  • [3.3 哨兵模式防止脑裂的数据保护机制](#3.3 哨兵模式防止脑裂的数据保护机制)
  • • [防线 1：Sentinel 多数派裁决](#防线 1：Sentinel 多数派裁决)
    • [防线 2：客户端访问路径](#防线 2：客户端访问路径)
    • [防线 3：脑裂恢复与数据同步](#防线 3：脑裂恢复与数据同步)
  • [3.4 哨兵脑裂追问](#3.4 哨兵脑裂追问)
• [四、Cluster 模式脑裂分析](#四、Cluster 模式脑裂分析)
• • [4.1 Cluster 的一致性单位](#4.1 Cluster 的一致性单位)
  • [4.2 Cluster 脑裂流程](#4.2 Cluster 脑裂流程)
  • • 初始状态
    • 网络分区
    • [分区 A（少数派 Master）](#分区 A（少数派 Master）)
    • [分区 B（多数派 Master）](#分区 B（多数派 Master）)
  • [4.3 Cluster 防止脑裂机制](#4.3 Cluster 防止脑裂机制)
  • [4.4 Cluster 脑裂恢复](#4.4 Cluster 脑裂恢复)
• [五、Redis 脑裂防护策略](#五、Redis 脑裂防护策略)
• • [5.1 通用原则](#5.1 通用原则)
  • [5.2 脑裂发生后的挽救流程](#5.2 脑裂发生后的挽救流程)
• [六、哨兵 vs Cluster 脑裂对比](#六、哨兵 vs Cluster 脑裂对比)
• [七、Redis 脑裂核心结论](#七、Redis 脑裂核心结论)
• 八、追问与回答

---

一、Redis 脑裂的定义与本质

1.1 什么是 Redis 脑裂？

Redis 脑裂（Split-Brain） 是指：

在网络分区场景下，多个节点同时认为自己是合法主节点，并对外提供写服务，从而导致数据分叉的现象。

⚠️ 必须满足的 4 个条件：

1. 网络分区（不是节点宕机）

2. 节点仍然存活（节点未下线）

3. 存在自动主从切换机制（Failover）

4. 写请求可能进入不同分区

❌ 缺一条就不是脑裂，可能只是主从不可用或数据延迟。

1.2 Redis 的 CAP 原则

Redis 面对网络分区时的真实行为：

• 优先保证多数派可用性（Availability）

• 少数派数据丢失（Consistency 让步）

脑裂不是 bug，而是分布式系统在网络分区下遵循 CAP 的必然结果。

---

二、脑裂发生的条件与架构影响

2.1 哪些架构模式可能脑裂？

架构模式	是否可能脑裂	原因说明
单机 Redis	❌	无分布式，无法切主
主从（无哨兵）	❌	无自动 Failover，主节点挂了从节点不会主动升主
哨兵模式	✅	Sentinel 判主 + 网络分区 → 可能出现两个 Master
Cluster 模式	✅	多 Master + 投票机制 → Slot 可能短暂出现两个 Master

🔑 核心结论：脑裂只可能发生在有自动主从切换机制的分布式架构。

---

三、哨兵模式脑裂分析

3.1 Sentinel 的核心机制

Redis Sentinel 做三件事：

1. 监控（Monitoring）：定期 PING 主从节点

2. 判活（Detection）：

   • SDOWN（主观下线）：单个 Sentinel 判定主不可达

   • ODOWN（客观下线）：多数 Sentinel 判定主不可达

3. 选主（Failover）：从 Slave 中选出新的 Master 并通知所有 Sentinel

注意 ：哨兵自身是分布式系统，脑裂的裁决权在 多数派 Sentinel。

3.2 哨兵脑裂标准流程

初始状态

Sentinel: S1 S2 S3
Redis:    M  +  S1 S2

网络分区发生

分区 A：M + S1
分区 B：S2 + S3

分区 A（少数派 Sentinel）

• Master M 仍存活

• S1 可访问 M

• Sentinel 数量不足 → 无法判 ODOWN

• ✅ 不会触发切主

分区 B（多数派 Sentinel）

• 连接不上 M

• S2 + S3 达成 ODOWN → 触发 Failover

• 从 Slave 中选出新 Master（M'）

结果：短时间内存在两个 Master（M vs M'），即物理脑裂。

3.3 哨兵模式防止脑裂的数据保护机制

防线 1：Sentinel 多数派裁决

• 只有多数派 Sentinel 才能执行 Failover

• 少数派无法合法切主

• ✅ 防止少数派节点成为"非法主节点"

防线 2：客户端访问路径

• 客户端通过 Sentinel 查询 Master

• Sentinel 只返回多数派 Master（M'）

• 客户端自动写入正确 Master

• ⚠️ 客户端不要直连 Redis IP，否则可能写入少数派 Master

防线 3：脑裂恢复与数据同步

1. 网络恢复后，旧 Master 检测自己已被剔除

2. 自动降级为 Slave

3. 丢弃脑裂期间写入的数据

4. 全量同步新 Master

🔑 结论：少数派写入数据一定丢，但逻辑上一致性最终保证。

3.4 哨兵脑裂追问

1. "分区 A 写入的数据会丢吗？" → 会，少数派写入必丢

2. "为什么不会出现客户端同时写两边？" → 客户端必须通过 Sentinel，多数派控制 Master 返回

3. "如果 Sentinel 少数派先切主，会怎样？" → 不会切主，Failover 需要多数派裁决

---

四、Cluster 模式脑裂分析

4.1 Cluster 的一致性单位

• Cluster 不以节点为单位，而以 Slot（16384 个） 为单位

• 每个 Slot 同一时刻只能有一个合法 Master

这与哨兵模式不同，哨兵以节点为单位裁决。

4.2 Cluster 脑裂流程

初始状态

M1   M2   M3

网络分区

分区 A：M1
分区 B：M2 + M3

分区 A（少数派 Master）

• 无投票权

• 不触发选主

• 少数派拒绝写 → 返回 CLUSTERDOWN

分区 B（多数派 Master）

• 判定 M1 FAIL

• 从 Slave 中选 M1' 为新 Master

物理上 M1 vs M1' 存在两个 Master，但逻辑上只有多数派 M1' 被承认。

4.3 Cluster 防止脑裂机制

1. Master 多数派写控制

   • 少数派 Master 拒绝写操作 → 返回 CLUSTERDOWN

2. configEpoch（版本号）裁决

   • Failover 时 epoch +1

   • epoch 大的配置才是权威

   • 所有节点必须服从

3. 客户端 Slot 强制路由

   • 客户端访问任意节点 → 获取 Slot → Master 映射

   • 写入旧 Master → 返回 MOVED → 自动更新路由

4.4 Cluster 脑裂恢复

• 旧 Master 发现 epoch 落后 → 降级为 Slave

• 丢弃少数派写入的数据

• 全量同步多数派 Master

---

五、Redis 脑裂防护策略

5.1 通用原则

1. 奇数裁决节点

   • Sentinel：3 / 5

   • Cluster Master：3 / 5 / 7

   避免平票，保证 Failover 多数派裁决

2. 写保护阈值

   Sentinel 模式

   min-slaves-to-write 1
   min-slaves-max-lag 10

   👉 主节点如果发现 Slave 不够，拒绝写

   ---

   Cluster 模式

   cluster-require-full-coverage yes

   👉 Slot 不完整直接拒写

3. 客户端访问规则

   • 必须通过 Sentinel / Cluster 客户端

   • 禁止硬编码 IP

5.2 脑裂发生后的挽救流程

1. 阻断少数派写入

2. 等网络恢复

3. 以 epoch 最大 Master 为准

4. 强制全量同步

5. 清理残留旧 Master 写入的数据

⚠️ 少数派数据无法挽回，只能保证服务和主从关系恢复。

---

六、哨兵 vs Cluster 脑裂对比

维度	Sentinel	Cluster
裁决者	Sentinel 多数派	Master 多数派
一致性单位	节点	Slot
写路由	客户端问 Sentinel	客户端自动 MOVED
少数派写入行为	可能暂时可写，但客户端不会写入	拒绝写 (CLUSTERDOWN)
脑裂复杂度	中	高
工程推荐规模	中小型	大型分布式

---

七、Redis 脑裂核心结论

1️⃣ 脑裂只发生在网络分区 + 自动选主

2️⃣ Redis 永远选择"多数派可用"

3️⃣ 物理上可能有两个 Master

4️⃣ 逻辑上只承认一个

5️⃣ 少数派写入一定丢

6️⃣ Sentinel 用"哨兵多数派"

7️⃣ Cluster 用"Master 多数派 + epoch"

8️⃣ 客户端不是随机写

9️⃣ 防脑裂靠配置，不靠运气

🔟 脑裂不是 bug，是 CAP 的代价

---

八、追问与回答

1. 脑裂和节点宕机区别？

   • 节点宕机是 Failover 正常行为，脑裂是网络分区导致多数派与少数派出现主节点分裂。

2. 少数派写入的数据怎么办？

   • 会丢失，恢复后以多数派 Master 为准。

3. 哨兵和 Cluster 的裁决机制差异？

   • Sentinel 以节点为单位，多数派裁决 Master

   • Cluster 以 Slot 为单位，多数 Master + epoch 决策

4. 客户端为什么不能直连 IP？

   • 直连少数派可能写入非法 Master，导致数据丢失或不一致

5. 如何防止脑裂？

   • 奇数裁决节点、写保护、客户端访问规则、保证网络可靠性

---