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