Redis 哨兵模式（Sentinel Mode）

哨兵模式是在主从模式基础上增加了哨兵机制，主从模式解决了读写分离，但缺乏自动容错，哨兵模式在主从基础上，增加了高可用性。

1. 核心作用

• 高可用性：当 Master 节点故障时，自动完成主从切换，保证服务持续可用。
• 读多写少适用：多个 Slave 分担读请求，Master 负责写请求。

---

2. 故障检测机制

• 主观下线（SDown）

  • Sentinel 每秒向节点发送 PING。
  • 若在 down-after-milliseconds 内未收到有效回复，判定该节点主观下线。

• 客观下线（ODown）

  • 当一个 Sentinel 判断 Master SDown 后，会向其他 Sentinel 确认。
  • 若超过配置的 quorum （最低投票数，默认是 2）数量的 Sentinel 一致认为 Master 下线，则判定为客观下线。

---

3. Leader Sentinel 选举

• 使用 Raft 算法选举一个 Leader Sentinel 来执行故障转移：

  1. 所有节点初始为 Follower（追随者，只接收并响应其他节点的投票或心跳，不主动发起选举。）。
  2. 若超时未收到心跳，节点转为 Candidate（候选者，主动发起投票，竞选成为 Leader Sentinel。） 并发起投票。
  3. 获得多数票的 Candidate 成为 Leader Sentinel。
  4. Leader （领导者）负责组织故障转移。

---

4. 新 Master 的选择规则

Leader Sentinel 在从节点中选择新的 Master，优先级如下：

1. 排除 SDown/ODown 的节点。
2. 优先选择 slave-priority （从节点优先级，Redis 从节点配置参数，用来指定该 Slave 在故障转移时的优先级；如果设置为 0，表示该 Slave 永远不会被提升为 Master）最大的节点。
3. 若无优先级节点，则选择复制偏移量最大的节点（数据最完整）。
4. 若仍有冲突，则选择 run_id（运行ID，每个 Redis 实例启动时都会生成一个唯一的run_id） 最小的节点（更稳定，越早启动的实例，run_id 越小，通常启动时间早、运行时间长、状态稳定，从而保证选出的主节点更加可靠和稳定。）。

---

5. 故障转移流程

1. 将选中的 Slave 升级为新的 Master。
2. 其他 Slave 节点重新配置为复制新 Master。
3. 更新 Sentinel 配置文件和 Master/Slave 配置文件。
4. 向客户端返回新的 Master 地址，保证写请求正常进行。