哨兵机制是Redis数据库提供的一种高可用性解决方案。它由一个或多个特殊的Redis服务器（称为哨兵）组成，这些服务器不执行数据存储功能，而是专注于监控和管理其他Redis服务器（主节点和从节点）。
为什么需要哨兵机制？
- 防止数据服务中断
如果Redis的主数据库（主节点）出现问题，比如服务器死机或者网络连接断开，那么客户端就无法从该数据库读取或写入数据了，而哨兵会监控主节点，一旦发现主节点无法访问，它会自动将一个从数据库（从节点）升级为新的主数据库，这样客户端就可以继续读写数据，不会因为主节点的故障而中断服务。
- 自动化处理
如果没有哨兵，当主节点出问题时，就需要人工去检查问题，然后手动将一个从节点升级为主节点，这个过程可能很慢，而且容易出错，哨兵可以自动完成这个过程，不需要人工干预，这样可以快速恢复服务，并且减少错误的发生。
- 避免单点故障
如果只有一个主节点，那么这个主节点就是一个单点故障点，一旦它出问题，整个服务就会受到影响，而哨兵可以监控多个节点，包括主节点和从节点，即使一个节点出问题，哨兵也可以通过其他节点来恢复服务，这样就不会因为单个节点的故障而导致整个服务瘫痪。
下线判断：
哨兵机制通过主观下线和客观下线，确保了在主节点真正出现问题时能够及时进行故障转移，同时减少了因网络波动或哨兵自身问题导致的误判。这种设计提高了Redis集群的稳定性和可用性，确保了即使在主节点发生故障的情况下，也能快速恢复服务，减少对业务的影响。
主观下线：哨兵实例通过 PING 命令检测到主节点或从节点在规定时间内没有响应时，该哨兵会将其标记为主观下线，但由于网络波动、服务器压力等原因，单个哨兵可能会错误地将一个实际上仍然在线的节点判断为下线，对于从节点，哨兵可以直接将其标记为主观下线，因为从节点的下线通常不会影响整个集群的服务。但对于主节点，则需要更加谨慎。
客观下线：通过引入多个哨兵实例组成哨兵集群，可以减少单个哨兵因网络问题或自身状况不佳导致的误判。多个哨兵共同决策，提高了判断的准确性。它们采用"少数服从多数"的原则，即当有 N 个哨兵实例时，至少需要 N/2 + 1 个实例判断主节点为主观下线，才能将主节点标记为客观下线，一旦主节点被标记为客观下线，哨兵集群将启动故障转移流程，选择新的主节点，并重新配置从节点。
选新主库：
当主节点被标记为"客观下线"后，哨兵集群将开始故障转移过程，哨兵集群中的所有哨兵实例将进行选举，选择一个领头哨兵来执行故障转移操作。首先判断从库的网络状态，如果其网络总是断连，那么其不能成为主库，然后依次按照从库优先级，从库复制进度与从库id号的顺序对剩余从库进行筛选，最优的为新主库。
领头哨兵：
当主节点被多个哨兵节点检测为主观下线后，哨兵节点会向其他哨兵节点询问该主节点的状态，如果足够多的哨兵节点认为主节点客观下线，则触发领头哨兵选举。
每个哨兵节点都可以在检测到主节点客观下线后发起选举。哨兵节点A发起选举时，会做以下事情：
- 增加自己的纪元（epoch）值。
- 将自己的状态设置为LEADING，表示正在尝试成为领头哨兵。
- 向其他哨兵节点发送SENTINEL is-master-down-by-addr命令，请求它们投票。
其他哨兵节点收到投票请求后，会根据以下规则进行投票：
- 在每个纪元内，每个哨兵节点只能投一次票。
- 如果哨兵节点没有给其他哨兵节点投过票，并且请求中的纪元值大于或等于自己的纪元值，那么它会投赞成票。
- 哨兵节点将投票结果发送回发起选举的哨兵节点A。
哨兵节点A收集投票，如果它获得了大多数哨兵节点的支持，则成为领头哨兵，如果没有哨兵节点获得足够的票数，则在一段时间后，哨兵节点可以尝试重新发起选举。而一旦哨兵节点A成为领头哨兵，它会向其他哨兵节点发送通知，告知它们领头哨兵的身份，避免其他哨兵节点再次发起选举。
领头哨兵负责选择新的主节点并执行主从切换，在故障转移期间，如果领头哨兵失败，其他哨兵节点将重新开始选举过程。