Redis Sentinel如何实现高可用？

Redis Sentinel 通过以下核心机制实现高可用：

1. 监控（Monitoring）

Sentinel 集群会持续监控主节点（Master）和从节点（Slave）的状态：

• 定期发送 PING 命令检测节点是否存活（默认每 10 秒向主/从节点发送 INFO 命令，每 2 秒通过 Pub/Sub 交换节点信息）。
• 若主节点在 down-after-milliseconds 时间内无响应，单个 Sentinel 会标记其为主观下线（SDOWN）。
• 当超过 quorum 数量的 Sentinel 都认为主节点 SDOWN 时，主节点会被标记为客观下线（ODOWN），触发故障转移。

2. 自动故障转移（Automatic Failover）

当主节点 ODOWN 后，Sentinel 集群通过以下步骤完成故障转移：

• 选举领导者 Sentinel：使用 Raft 算法在 Sentinel 集群中选举一个领导者，负责执行故障转移（避免多个 Sentinel 同时操作导致混乱）。
• 选择新主节点：从存活的从节点中按优先级（slave-priority 配置）、复制偏移量（优先偏移量大的）、运行 ID（优先小的）选出最优从节点。
• 提升新主节点：领导者 Sentinel 向选中的从节点发送 SLAVEOF NO ONE 命令，将其提升为新主节点。
• 重新配置从节点：命令其他从节点通过 SLAVEOF <新主IP:端口> 指向新主节点，同步数据。
• 更新配置：所有 Sentinel 更新自身记录的主节点信息，并通过 Pub/Sub 通知客户端新主节点的地址。

3. 客户端透明切换

客户端连接 Sentinel 集群获取主节点地址（而非直接连接固定主节点）。当主节点切换后：

• Sentinel 会通过 Pub/Sub 频道（如 +switch-master）广播新主节点信息。
• 客户端监听该频道，检测到主节点变更后，自动重新连接新主节点，无需人工干预。

关键设计要点

• 集群部署：建议至少 3 个 Sentinel 实例（奇数个，避免平票），避免因网络分区导致的“脑裂”问题。
• Quorum 机制：通过 sentinel monitor <master-name> <ip> <port> <quorum> 配置，只有超过 quorum 数量的 Sentinel 确认主节点下线，才触发故障转移，减少误判。
• 持久化支持：Sentinel 会将最新的主/从节点配置写入 sentinel.conf，确保重启后状态恢复。

通过以上机制，Redis Sentinel 实现了主节点故障时的自动发现、自动切换和客户端透明访问，保障了 Redis 服务的高可用性。