Sentinel-哨兵机制

Redis中采用了主从库模式，如果从库挂了，客户端可以继续向主库或其他从库发送请求，进行相关的操作，但是如果主库发生故障了，那就直接会影响到从库的同步，因为从库没有相应的主库可以进行数据复制操作了。如果Redis在半夜出现故障，还需要运维手动切换，人工运维的成本太高。所以我们必须有一个高可用方案来抵抗节点故障，当故障发生时可以自动进行从主切换，程序可以不用重启，运维可以继续睡大觉，仿佛什么事也没发生一样。Redis 官方提供了这样一种方案 —— Redis Sentinel(哨兵)。

主从模式下，如果主库挂了就会导致写服务中断，就需要运行一个新的主库，势必会涉及到三个问题：

• 主库真的挂了吗？
• 选择哪个从库作为主库？
• 怎么把新主库的相关信息通知到从库和客户端。

哨兵机制的基本流程

哨兵机制就是：由一个或多个 Sentinel实例(instance)组成的Sentinel系统(system)可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。

从下面这张图中我们能看到主节点挂掉了，原先的主从复制也断开了，客户端和损坏的主节点也断开了。从节点被提升为新的主节点，其它从节点开始和新的主节点建立复制关系。客户端通过新的主节点继续进行交互。Sentinel 会持续监控已经挂掉了主节点

所以哨兵机制主要负责以下三个任务：

• 监控：周期性地给所有的主从库发送PING命令，检测它们是否仍然在线运行。如果从库没有在规定时间内响应哨兵的PING命令，哨兵就会把它标记为“下线状态”；同样，如果主库也没有在规定时间内响应哨兵的PING命令，哨兵就会判定主库下线，然后开始自动切换主库的流程；
• 选主：主库挂了以后，哨兵就需要很多从库，按照一定的规则选择一个从库实例，把它作为新的主库；
• 通知：在执行通知任务时，哨兵会把新主库的连接信息发给其他从库，让它们执行replicaof命令，和新主库建立连接，并进行数据复制。同时，哨兵会把新主库的连接信息通知给客户端，让它们把请求操作发到新主库上；

哨兵对主库的下线判断有“主观下线”和“客观下线”两种。那么，为什么会存在两种判断呢？它们的区别和联系是什么呢？

主观下线和客观下线

在默认情况下，Sentinel会以每秒一次的频率向所有与它创建了命令连接的实例(包括主 服务器、从服务器、其他Sentinel在内)发送PING命令，并通过实例返回的PING命令回复来 判断实例是否在线。

Sentinel配置文件中的down-after-milliseconds选项指定了Sentinel判断实例进入主观下线 所需的时间长度:如果一个实例在down-after-milliseconds毫秒内，连续向Sentinel返回无效回 复，那么Sentinel会修改这个实例所对应的实例结构，在结构的flags属性中打开 SRI_S_DOWN标识，以此来表示这个实例已经进入主观下线状态。

实例对PING命令的回复可以分为以下两种情况:

• 有效回复:实例返回+PONG、-LOADING、-MASTERDOWN三种回复的其中一种;
• 无效回复:实例返回除+PONG、-LOADING、-MASTERDOWN三种回复之外的其他 回复，或者在指定时限内没有返回任何回复;

如果检测到的是从库，哨兵简单的标记为主观下线即可，从库的下线影响不会太大；如果检测的是主库，不能简单的标记为主观下线就开启主从切换，因为一旦主库没有故障，哨兵误判就会带来不必要的计算和通信开销。

为了避免误判，哨兵机制一般会采用多个实例组成的服务器集群的模式进行部署，引入多个哨兵实例一起判断，就可以避免单个哨兵因为自身网络不好而误判主库下线的情况，因为多个哨兵同时不稳定的概率较小，一起做决策可以降低误判率，哨兵集群判断的逻辑如下图所示：

客观下线：
当有N个哨兵实例时，最好要有N/2 + 1个实例判断主库为“主观下线”，才能最终判定主库为“客观下线”。这样一来，就可以减少误判的概率，也能避免误判带来的无谓的主从库切换。（当然，有多少个实例做出“主观下线”的判断