哨兵机制与哨兵集群

哨兵机制与哨兵集群

哨兵机制的基本流程

​ 哨兵其实就是一个运行在特殊模式下的 Redis 进程，主从库实例运行的同时，它也在运行。哨兵主要负责的就是三个任务：监控、选主（选择主库）和通知。

• 监控

  哨兵进程在运行时，周期性地给所有的主从库发送 PING 命令，检测它们是否仍然在线运行，规定时间内没有响应则标记为“下线状态”。

• 选主

  哨兵就需要从很多个从库里，按照一定的规则选择一个从库实例，把它作为新的主库。

• 通知

​ 会把新主库的连接信息发给其他从库，让它们执行 replicaof 命令，和新主库建立连接，并进 行数据复制。同时，哨兵会把新主库的连接信息通知给客户端，让它们把请求 *** 作发到新主库 上。

主观下线和客观下线

哨兵对主库的下线判断有**“主观下线”和“客观下线”**两种。

​ 哨兵进程会使用 PING 命令检测它自己和主、从库的网络连接情况，用来判断实例的状态。如果哨兵发现主库或从库对 PING 命令的响应超时了，那么，哨兵就会先把它标记为“主观下线”。检测的是从库直接可以标记下线，因为从库下线影响不大。如果是主库则不能直接下线，因为会存在误判，主库实际没有下线，误判一般会发生在集群网络压力较大、网络拥塞，或者是主库本身压力较大的情况下。

如何减少误判

哨兵集群，避免单个哨兵因为自身网络状况不好，而误判主库下线的情况。当有 N 个哨兵实例时，最好要有 N/2 + 1 个实例判断主库为“主观下线”，才能最终判定主库为“客观下线”。

如何选定新主库？

哨兵选择新主库的过程称为“筛选 + 打分”。先按照一定的筛选条件，把不符合条件的从库去掉。然后，我们再按照一定的规则，给剩下的从库逐个打分，将得分最高的从库选为新主库。

打分三个规则分别是从库优先级、从库复制进度以及从库 ID 号，某一轮有最高分就可以选出主库。

• 从库优先级。slave-priority 配置项进行设置。
• 和旧主库同步程度最接近的从库得分高。主库会用 master_repl_offset 记录当前的最新写 *** 作在 repl_backlog_buffer 中的位置，而从库会用 slave_repl_offset 这个值记录当前的复制进度。
• ID 号小的从库得分高。

思考题：哨兵在 *** 作主从切换的过程中，客户端能否正常地进行请求 *** 作？

​ 如果客户端使用了读写分离，那么读请求可以在从库上正常执行，不会受到影响。但是由于此时主库已经挂了，而且哨兵还没有选出新的主库，所以在这期间写请求会失败，失败持续的时间 = 哨兵切换主从的时间 + 客户端感知到新主库 的时间。

​ 如果不想让业务感知到异常，客户端只能把写失败的请求先缓存起来或写入消息队列中间件中，等哨兵切换完主从后，再把这些写请求发给新的主库，但这种场景只适合对写入请求返回值不敏感的业务，而且还需要业务层做适配，另外主从切换时间过长，也会导致客户端或消息队列中间件缓存写请求过多，切换完成之后重放这些请求的时间变长。

哨兵集群：哨兵挂了，主从库还能切换吗？

基于 pub/sub 机制的哨兵集群组成

哨兵实例之间可以相互发现，要归功于 Redis 提供的 pub/sub 机制，也就是发布 / 订阅机制。哨兵向主库发送 INFO命令，可以获取从库的 IP 地址和端口。

为了实现主从切换，我们引入了哨兵；为了避免单个哨兵故障后无法进行主从切换，以及为了减少误判率，又引入了哨兵集群；哨兵集群又需要有一些机制来支撑它的正常运行。

支持哨兵集群的这些关键机制，包括：

• 基于 pub/sub 机制的哨兵集群组成过程；

• 基于 INFO 命令的从库列表，这可以帮助哨兵和从库建立连接；

• 基于哨兵自身的 pub/sub 功能，实现了客户端和哨兵之间的事件通知。

下期预告：分片集群，尽请关注