哨兵机制是Redis数据库提供的一种高可用性解决方案。它由一个或多个特殊的Redis服务器（称为哨兵）组成，这些服务器不执行数据存储功能，而是专注于监控和管理其他Redis服务器（主节点和从节点）。
为什么需要哨兵机制？
下线判断：
哨兵机制通过主观下线和客观下线，确保了在主节点真正出现问题时能够及时进行故障转移，同时减少了因网络波动或哨兵自身问题导致的误判。这种设计提高了Redis集群的稳定性和可用性，确保了即使在主节点发生故障的情况下，也能快速恢复服务，减少对业务的影响。
主观下线：哨兵实例通过 PING 命令检测到主节点或从节点在规定时间内没有响应时，该哨兵会将其标记为主观下线，但由于网络波动、服务器压力等原因，单个哨兵可能会错误地将一个实际上仍然在线的节点判断为下线，对于从节点，哨兵可以直接将其标记为主观下线，因为从节点的下线通常不会影响整个集群的服务。但对于主节点，则需要更加谨慎。
客观下线：通过引入多个哨兵实例组成哨兵集群，可以减少单个哨兵因网络问题或自身状况不佳导致的误判。多个哨兵共同决策，提高了判断的准确性。它们采用“少数服从多数”的原则，即当有 N 个哨兵实例时，至少需要 N/2 + 1 个实例判断主节点为主观下线，才能将主节点标记为客观下线，一旦主节点被标记为客观下线，哨兵集群将启动故障转移流程，选择新的主节点，并重新配置从节点。
选新主库：
当主节点被标记为“客观下线”后，哨兵集群将开始故障转移过程，哨兵集群中的所有哨兵实例将进行选举，选择一个领头哨兵来执行故障转移操作。首先判断从库的网络状态，如果其网络总是断连，那么其不能成为主库，然后依次按照从库优先级，从库复制进度与从库id号的顺序对剩余从库进行筛选，最优的为新主库。
领头哨兵：
当主节点被多个哨兵节点检测为主观下线后，哨兵节点会向其他哨兵节点询问该主节点的状态，如果足够多的哨兵节点认为主节点客观下线，则触发领头哨兵选举。
每个哨兵节点都可以在检测到主节点客观下线后发起选举。哨兵节点A发起选举时，会做以下事情：
- 增加自己的纪元（epoch）值。
- 将自己的状态设置为LEADING，表示正在尝试成为领头哨兵。
- 向其他哨兵节点发送SENTINEL is-master-down-by-addr命令，请求它们投票。
其他哨兵节点收到投票请求后，会根据以下规则进行投票：
- 在每个纪元内，每个哨兵节点只能投一次票。
- 如果哨兵节点没有给其他哨兵节点投过票，并且请求中的纪元值大于或等于自己的纪元值，那么它会投赞成票。
- 哨兵节点将投票结果发送回发起选举的哨兵节点A。
哨兵节点A收集投票，如果它获得了大多数哨兵节点的支持，则成为领头哨兵，如果没有哨兵节点获得足够的票数，则在一段时间后，哨兵节点可以尝试重新发起选举。而一旦哨兵节点A成为领头哨兵，它会向其他哨兵节点发送通知，告知它们领头哨兵的身份，避免其他哨兵节点再次发起选举。
领头哨兵负责选择新的主节点并执行主从切换，在故障转移期间，如果领头哨兵失败，其他哨兵节点将重新开始选举过程。
到此这篇连接redis哨兵模式（redis哨兵模式连接命令）的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章，希望大家都能在编程的领域有一番成就！版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/haskellbc/22407.html