- 🛑 Redis Sentinel 集群故障转移和选举流程
- 1. 故障判定与仲裁 (Quorum)
- 2. 选举领头 Sentinel（Leader Sentinel）
- 3. 执行新的 Master 选举（Slave 选举）
- 4. 重新配置其余节点
- 🛑 Redis Sentinel 集群故障转移和选举流程
- 为什么需要选举 Leader Sentinel
- 1. 避免“脑裂”（Split-Brain）与数据冲突
- 设想没有 Leader Sentinel 的情况：
- 选举 Leader Sentinel 的作用：
- 2. 保证操作的一致性（多数原则）
- 3. 简化和集中协调配置
- 1. 避免“脑裂”（Split-Brain）与数据冲突
这是一个关于 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)
- 客观下线（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。
- 每个 Sentinel 都会向其他 Sentinel 发送
3. 执行新的 Master 选举（Slave 选举）
Leader Sentinel 诞生后，它会负责从剩余的 4 个 Slave 节点中选举出一个新的 Master：
- 过滤不合格的 Slave：
- 首先，Leader Sentinel 会排除掉那些状态不佳或通信不正常的 Slave。
- 然后，会排除掉那些最近与原 Master 断开时间过长的 Slave（防止数据丢失过多）。
- Slave 优先级排序： Leader Sentinel 会根据以下几个标准对合格的 Slave 进行排序：
slave-priority配置： 优先级数字最小（即最高优先级）的 Slave 会排在最前面。- 复制偏移量（Replication Offset）： 拥有最大复制偏移量（即数据最完整、与原 Master 同步程度最高）的 Slave 会被优先选中。
- Run ID： 最后，如果复制偏移量也相同，则会按照 Run ID 进行字典排序。
- 选定新 Master：
- 排名最高的 Slave 节点 将被选中，Leader Sentinel 会向它发送
SLAVEOF NO ONE命令，使其晋升为新的 Master。
- 排名最高的 Slave 节点 将被选中，Leader Sentinel 会向它发送
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，还包括后续的一系列配置任务：
- 向新 Master 发送
SLAVEOF NO ONE。 - 向所有旧 Slave 发送
SLAVEOF <New Master IP:Port>。 - 更新自己的配置，记录新的 Master 信息。
- 如果旧 Master 重新上线，要通知它作为新 Master 的 Slave 启动。
如果没有一个 Leader 来集中协调这些步骤，所有 Sentinel 独立执行这些操作，很容易产生命令冲突、重复操作或遗漏步骤，使故障转移流程变得复杂且不可靠。
总结：
选举 Leader Sentinel 的根本目的，就是将执行故障转移这一关键且高风险的任务的权力，集中到集群多数 Sentinel 共同认可的唯一节点身上，以确保系统的高可用性和数据一致性。