Redis sentinal模式，master挂了的 选举过程

目录

• • 🛑 Redis Sentinel 集群故障转移和选举流程
    • 1. 故障判定与仲裁 (Quorum)
    • 2. 选举领头 Sentinel（Leader Sentinel）
    • 3. 执行新的 Master 选举（Slave 选举）
    • 4. 重新配置其余节点
• 为什么需要选举 Leader Sentinel
  • 1. 避免“脑裂”（Split-Brain）与数据冲突
    • 设想没有 Leader Sentinel 的情况：
    • 选举 Leader Sentinel 的作用：
  • 2. 保证操作的一致性（多数原则）
  • 3. 简化和集中协调配置

这是一个关于 Redis Sentinel（哨兵）模式 下的主节点（Master）故障转移和选举过程的问题。

---

🛑 Redis Sentinel 集群故障转移和选举流程

首先需要澄清一点：您描述的“Redis 5 节点集群，使用哨兵模式”是一个常见的误解。

• Redis Cluster（原生集群） 自身具备去中心化的故障转移和数据分片能力，通常不需要 Sentinel。
• Redis Sentinel 模式是用于管理一个 Master-Slave 架构 的高可用方案。

根据您的描述，这是一个 1 Master + 4 Slave 的 Redis 实例，由 N 个 Sentinel 进程 组成的监控系统进行管理。

在 Master 挂掉后，新的 Master 选举和故障转移 流程完全由 Sentinel 进程 控制，Redis 数据节点（Master/Slave）本身不参与选举投票。

1. 故障判定与仲裁 (Quorum)

1. 客观下线（ODOWN）判定：
   • 当 Master 挂掉时，每一个 Sentinel 都会发现 Master 无法访问，并将其标记为主观下线（SDOWN）。
   • 为了确认 Master 确实挂了，Sentinel 需要达到一个仲裁票数（Quorum）。假设您配置了 $N$ 个 Sentinel，且 Quorum 设置为 $Q$。
   • 当 $Q$ 个或更多 Sentinel 确认 Master 确实下线时，Master 才会被标记为客观下线（ODOWN）。
   • 只有当 Master 被标记为 ODOWN 后，Sentinel 集群才会启动故障转移程序。

2. 选举领头 Sentinel（Leader Sentinel）

一旦 Master 被标记为 ODOWN，所有的 Sentinel 进程会开始竞争，选举出一个 领头 Sentinel（Leader Sentinel） 来负责执行故障转移操作。

• 选举算法： Sentinel 使用 Raft 算法 的子集来选举 Leader。
  • 每个 Sentinel 都会向其他 Sentinel 发送 SENTINEL is-master-down-for-service 命令，并附带一个请求投票。
  • 收到投票请求的 Sentinel，如果还没有投给其他人，就会回复同意。
  • 第一个获得多数票（$\lfloor N/2 \rfloor + 1$ 票，其中 $N$ 是 Sentinel 进程总数）的 Sentinel，将成为 Leader Sentinel。

3. 执行新的 Master 选举（Slave 选举）

Leader Sentinel 诞生后，它会负责从剩余的 4 个 Slave 节点中选举出一个新的 Master：

1. 过滤不合格的 Slave：
   • 首先，Leader Sentinel 会排除掉那些状态不佳或通信不正常的 Slave。
   • 然后，会排除掉那些最近与原 Master 断开时间过长的 Slave（防止数据丢失过多）。
2. Slave 优先级排序： Leader Sentinel 会根据以下几个标准对合格的 Slave 进行排序：
   • slave-priority 配置： 优先级数字最小（即最高优先级）的 Slave 会排在最前面。
   • 复制偏移量（Replication Offset）： 拥有最大复制偏移量（即数据最完整、与原 Master 同步程度最高）的 Slave 会被优先选中。
   • Run ID： 最后，如果复制偏移量也相同，则会按照 Run ID 进行字典排序。
3. 选定新 Master：
   • 排名最高的 Slave 节点 将被选中，Leader Sentinel 会向它发送 SLAVEOF NO ONE 命令，使其晋升为新的 Master。

4. 重新配置其余节点

• 剩下的 3 个 Slave 节点会被重新配置，让它们复制（Replicate）新选举出来的 Master。
• 如果原 Master 重新上线，它将以新的 Slave 身份加入集群，复制当前 Master 的数据。

总结您的场景中的选举核心：

• 谁来选： Sentinel 进程 投票选举 Leader Sentinel（使用 Raft 多数票原则）。
• 选谁当 Master： Leader Sentinel 在剩余的 4 个 Slave 中，根据优先级和数据完整度（复制偏移量）选出最好的一个来晋升。

为什么需要选举 Leader Sentinel

这是一个非常关键的问题。在 Redis Sentinel 模式中，选举 Leader Sentinel 是为了确保故障转移的原子性和一致性，防止“脑裂”（Split-Brain）等灾难性问题发生。

如果不需要选举 Leader Sentinel，而是让所有 Sentinel 都自行执行故障转移，就会出现以下严重问题：

---

1. 避免“脑裂”（Split-Brain）与数据冲突

这是最主要的原因。

设想没有 Leader Sentinel 的情况：

• 假设您有 3 个 Sentinel（S1, S2, S3）。
• 它们同时发现 Master 挂了，并决定启动故障转移。
• S1 可能选了 Slave A 当新 Master。
• S2 可能选了 Slave B 当新 Master。

结果：

• 集群中同时存在两个 Master（A 和 B），这就是脑裂。
• 客户端可能连接到 A，写入数据；其他客户端可能连接到 B，写入另一部分数据。
• 当网络恢复后，这些数据将无法合并，导致严重的数据不一致和数据丢失。

选举 Leader Sentinel 的作用：

• 单一决策者： 只有通过选举产生的 Leader Sentinel 拥有执行 SLAVEOF NO ONE（晋升 Slave）和重新配置其他节点（发送 SLAVEOF <New Master>）的权力。
• 保证原子性： Leader Sentinel 保证了在同一时间段内，只有一个新的 Master 会被选出和配置。所有节点最终都会同步到这个唯一的 Master 上，从而避免了脑裂和数据冲突。

---

2. 保证操作的一致性（多数原则）

Sentinel 的故障转移必须基于集群的共识，而不是单个节点的判断。

• 客观下线（ODOWN） 机制确保了 Master 的故障是多数 Sentinel 认可的。
• Leader 选举 机制确保了执行转移操作的权力也获得了多数 Sentinel 的认可。

如果 Master 节点只是暂时网络抖动，少数 Sentinel 错误地启动了故障转移，可能会导致不必要的切换。通过 Leader 选举（基于 Raft 多数原则），可以确保只有在多数派认可的情况下，才能进行高风险的系统变更操作。

---

3. 简化和集中协调配置

故障转移不仅仅是选一个新的 Master，还包括后续的一系列配置任务：

1. 向新 Master 发送 SLAVEOF NO ONE。
2. 向所有旧 Slave 发送 SLAVEOF <New Master IP:Port>。
3. 更新自己的配置，记录新的 Master 信息。
4. 如果旧 Master 重新上线，要通知它作为新 Master 的 Slave 启动。

如果没有一个 Leader 来集中协调这些步骤，所有 Sentinel 独立执行这些操作，很容易产生命令冲突、重复操作或遗漏步骤，使故障转移流程变得复杂且不可靠。

总结：

选举 Leader Sentinel 的根本目的，就是将执行故障转移这一关键且高风险的任务的权力，集中到集群多数 Sentinel 共同认可的唯一节点身上，以确保系统的高可用性和数据一致性。