（七）拿下redis哨兵模式

一.为什么需要哨兵模式

在redis的主从模式中，有多个从服务器，但是只有一个主服务器，从服务器主要给从客户端提供读数据的操作，主服务器负责实现数据更新，并将更新的数据通知到与它相连的从服务器。主服务器只有一个，那么当主服务器宕机后，该怎么办呢？这种情况下基本上redis集群的数据更新系统就无法完成任务了，这个时候就需要用到redis中的哨兵模式。

二.哨兵模式的主要任务

哨兵其实就是一个运行在特殊模式下的 Redis 进程，主从库实例运行的同时，它也在运行。

监控

监控是指哨兵进程在运行时，周期性地给所有的主从库发送 PING 命令，检测它们是否仍然在线运行。如果从库没有在规定时间内响应哨兵的 PING 命令，哨兵就会把它标记为“下线状态”；同样，如果主库也没有在规定时间内响应哨兵的 PING 命令，哨兵就会判定主库下线，然后开始自动切换主库的流程。

选主

当哨兵叫测到主库下线后，就要通过一定的规则从多个从库中选择一个作为新的主库。

通知

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

通过上面的三个任务，我们就可以清楚地认识到实现这三个任务会涉及到的三个问题：
1.主库真的下线了吗
2.如何选取主库
3.如何将新的主库的相关信息通知给从库和客户端？

三.实现流程

主观下线与客观下线

哨兵进程会使用 PING 命令检测它自己和主、从库的网络连接情况，用来判断实例的状态。如果哨兵发现主库或从库对 PING 命令的响应超时了，那么，哨兵就会先把它标记为**“主观下线”**。

如果监测到的是从库的下线，则简单标记为“主观下线”（后面的选主会用到），因为从库的下线对整个redis集群影响不大。

但是，如果检测的是主库，那么，哨兵还不能简单地把它标记为“主观下线”，开启主从切换。因为很有可能存在这么一个情况：那就是哨兵误判了，其实主库并没有故障。可是，一旦启动了主从切换，后续的选主和通知操作都会带来额外的计算和通信开销。
误判：哨兵可能遇到因在集群网络压力较大、网络拥塞，或者是主库本身压力较大的情况下没有收到来自主库的pong通知。

如何解决误判：
建立多个哨兵，即采用哨兵集群模式。
多个哨兵对主库进行判定，如果下线判定（主观下线）的哨兵比在线判定的哨兵数量多，则将这个主库标记为客观下线。

简单来说，**“客观下线”**的标准就是，当有 N 个哨兵实例时，最好要有 N/2 + 1 个实例判断主库为“主观下线”，才能最终判定主库为“客观下线”。这样一来，就可以减少误判的概率，也能避免误判带来的无谓的主从库切换。（当然，有多少个实例做出“主观下线”的判断才可以，可以由 Redis 管理员自行设定）。

选主流程

既然哨兵集群已经判定到主库已经处于客观下线状态了，此时就需要由哨兵从从库中选取新的主库。
如何选取新的主库：通过一定的筛选条件和一定的规则进行筛选+打分。

一定的筛选条件

一般情况下，我们肯定要先保证所选的从库仍然在线运行。不过，在选主时从库正常在线，这只能表示从库的现状良好，并不代表它就是最适合做主库的。在选主时，除了要检查从库的当前在线状态，还要判断它之前的网络连接状态。如果从库总是和主库断连，而且断连次数超出了一定的阈值，我们就有理由相信，这个从库的网络状况并不是太好，就可以把这个从库筛掉了。
我们知道判断当前的在线状态可以从哨兵标记的主观下线进行判定。但是我们如何判定从库之前的网络状态呢？
使用配置项： down-after-milliseconds * 10
down-after-milliseconds 是我们认定主从库断连的最大连接超时时间。如果在 down-after-milliseconds 毫秒内，主从节点都没有通过网络联系上，我们就可以认为主从节点断连了。如果发生断连的次数超过了 10 次，就说明这个从库的网络状况不好，不适合作为新主库。

一定的规则

通过三个规则进行筛选。只要其中有一个筛选出了最适合做主库的从库，就不再向后筛选。如果一次筛选没有选出最好的，继续执行后续的条件筛选。

第一轮：优先级最高的从库得分高

用户可以通过 slave-priority 配置项，给不同的从库设置不同优先级。
如果有一个从库优先级最高，那么它就是新主库了。如果从库的优先级都一样，那么哨兵开始第二轮打分。

第二轮：和旧主库同步程度最接近的从库得分高

如果选择和旧主库同步最接近的那个从库作为主库，那么，这个新主
库上就有最新的数据。
如何判断一个从库是否是最接近主库数据的库？
主从库同步时有个命令传播的过程，主库会用master_repl_offset 记录当前的最新写操作在 repl_backlog_buffer 中的位置，而从库会用 slave_repl_offset 这个值记录当前的复制进度。此时，我们想要找的从库，它的 slave_repl_offset 需要最接近 master_repl_offset。如果
在所有从库中，有从库的 slave_repl_offset 最接进master_repl_offset，那么它的得分就最高，可以作为新主库。

如果有两个都最接近主库，我们就需要进行第三次打分

第三轮：ID号小的从库得分高

（ID号唯一，一定能够选出）

每个实例都会有一个 ID，这个 ID 就类似于这里的从库的编号。目前，Redis 在选主库时，有一个默认的规定：在优先级和复制进度都相同的情况下，ID 号最小的从库得分最高，会被选为新主库。

之后，哨兵只需要将选取的主库通知到其他从库进行主从连接就可以了。