Redis Sentinel 是 Redis 高可用架构的关键组件，用于监控 Redis 主从结构、自动故障转移以及通知系统管理员。

当 Redis 的主节点出现故障时，Sentinel 可以自动将从节点提升为新的主节点，确保系统的可用性。

Redis Sentinel 集群选举机制主要包括定时任务、主观下线、客观下线、Sentinel 领导者选举和故障转移五个部分。

一、三个定时任务

①、每隔 10 秒：

Sentinel 向所有已知的主节点、从节点以及其他 Sentinel 发送 INFO 命令：

• 获取节点的最新状态信息，包括复制信息、拓扑结构等。

• 更新自身对整个集群的了解，发现新的从节点或 Sentinel 实例。

②、每隔 2 秒：

Sentinel 向所有主节点和从节点发送 PING 命令：

• 测试这些节点的可用性。若节点在规定时间内没有响应 PING，Sentinel 认为该节点存在问题，并可能标记为“主观下线”。
  

③、每隔 1 秒：

Sentinel 之间相互发送 PING 命令：

• 确保各个 Sentinel 实例之间的连接和通信正常。

• 如果 Sentinel 之间的连接出现问题，可能会导致“主观下线”。

二、主观下线

主观下线是 Sentinel 根据自身判断认为某个节点出现了故障。具体步骤如下：

• 当 Sentinel 无法收到某个 Redis 节点的 PING 命令响应时，它会将该节点标记为主观下线。

• 仅由一个 Sentinel 实例判断，无需其他 Sentinel 的一致同意。

三、客观下线

客观下线是在多个 Sentinel 对同一节点判定为主观下线后，共同认定该节点确实出现故障的过程：

• 多个 Sentinel 通过交换信息确认该节点已经长时间无响应，且超过设定的下线阈值。

• 当超过配置的 quorum（法定人数）时，该节点会被标记为客观下线。

四、Sentinel 领导者选举

当主节点被判定为客观下线时，需要从从节点中选择一个新的主节点，并且整个故障转移过程需要一个 Sentinel 领导者来协调：

选举流程：

• 所有 Sentinel 实例会进行一次投票，每个 Sentinel 可以投票给自己或者其他 Sentinel。

• 若某个 Sentinel 获得的票数超过法定人数 quorum，则它被选为领导者，负责执行故障转移。

投票机制：

• Sentinel 使用 Raft 算法中的部分思想来实现选举一致性。每个投票周期，每个 Sentinel 只能投一票。

• 如果在超时时间内未能选出领导者，则重新开始选举，直到成功选出领导者。

五、故障转移

故障转移是整个 Sentinel 系统的核心任务：

①、停止旧主节点的服务：

Sentinel 领导者尝试通过配置将旧的主节点从集群中剔除。

②、选择新的主节点：

从所有可用的从节点中选择一个条件最优的节点作为新的主节点。

条件包括：复制偏移量（优先选择数据最完整的节点）、从节点的优先级（slave-priority）等。

③、将其他从节点指向新的主节点：

领导者 Sentinel 会将其他从节点重新配置为新的主节点的从节点。

④、更新配置：

Sentinel 领导者通知所有 Sentinel 更新它们的配置，指向新的主节点。

⑤、通知客户端：

如果配置了通知脚本，Sentinel 会通知客户端新的主节点信息。

通过这五个步骤，Redis Sentinel 实现了对主节点故障的自动恢复和集群高可用性的保障。