- 🛑 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 共同认可的唯一节点身上,以确保系统的高可用性和数据一致性。