redis | 哨兵机制

原因：只有主库有写操作的功能，如果主库挂了，需要为保持写操作而做出努力。

这涉及到三个问题：

1. 主库真的挂了吗？
2. 该选择哪个从库作为主库？
3. 怎么把新主库的相关信息通知给从库和客户端呢？

哨兵机制

哨兵：

一个特殊模式下的redis进程

哨兵任务：

监控、选主（选择主库）和通知。

监控：

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

选主：

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

通知：

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

主观下线和客观下线

主观下线：如果哨兵发现主库或从库对 PING 命令的响应超时了，那么，哨兵就会先把它标记为“主观下线”。

对从库来说，哨兵简单地把它标记为“主观下线”就行了，因为从库的下线影响一般不太大，集群的对外服务不会间断。

误判：一般会发生在集群网络压力较大、网络拥塞，或者是主库本身压力较大的情况下

但是主库的切换需要更加谨慎，为了避免哨兵误判，选主和通知操作带来额外的计算和通信开销。

客观下线：大多数的哨兵实例，都判断主库已经“主观下线”了，主库才会被标记为“客观下线”

通常会采用多实例组成的集群模式进行部署，这也被称为哨兵集群，可以避免单个哨兵因为自身网络状况不好，而误判主库下线的情况。同时，多个哨兵的网络同时不稳定的概率较小，由它们一起做决策，误判率也能降低。

“客观下线”的标准：当有 N 个哨兵实例时，最好要有 N/2 + 1 个实例判断主库为“主观下线”，才能最终判定主库为“客观下线”

如何选定新主库

• 哨兵选择新主库的过程称为“筛选 + 打分”

除了要检查从库的当前在线状态，还要判断它之前的

网络连接状态

• 筛选：down-after-milliseconds * 10

down-after-milliseconds 是我们认定主从库断连的最大连接超时时间

如果在 down-after-milliseconds 毫秒内，主从节点都没有通过网络联系上，我们就可以认为主从节点断连了。如果发生断连的次数超过了 10 次，就说明这个从库的网络状况不好，不适合作为新主库。

sentinal.conf 文件进行配置，不在 redis.conf 中

• 打分：

1. 优先级最高的从库得分高。

通过 slave-priority 配置项，给不同的从库设置不同优先级。数字越小优先级越高。

比如有两个从库，它们的内存大小不一样，手动给内存大的实例设置一个高优先级。在选主时，哨兵会给优先级高的从库打高分，如果有一个从库优先级最高，那么它就是新主库了。如果从库的优先级都一样，那么哨兵开始第二轮打分。

1. 和旧主库同步程度最接近的从库得分高。

主库会用 master_repl_offset 记录当前的最新写操作在 repl_backlog_buffer 中的位置

而从库会用 slave_repl_offset 这个值记录当前的复制进度。

所有从库中，有从库的 slave_repl_offset 最接近 master_repl_offset，那么它的得分就最高，可以作为新主库。

1. ID 号小的从库得分高。

每个实例都会有一个 ID，这个 ID 就类似于这里的从库的编号

在优先级和复制进度都相同的情况下，ID 号最小的从库得分最高，会被选为新主库。