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 服务的高可用性。