四. 检测下线状态
对于Redis的Sentinel中关于下线有两个不同的概念：(1)主观下线(Subjectively Down， 简称 Sdown) 指的是单个 Sentinel 实例对服务器做出的下线判断，此时不会进行故障转移。(2) 客观下线（Objectively Down， 简称 Odown）指的是多个 Sentinel 实例在对同一个服务器做出 Sdown 判断，此时目标sentinel会对主服务器进行故障转移。本篇具体详细介绍。
4.1 检测主观下线状态
默认情况下，Sentinel会以每秒一次的频率向所有与它创建命令连接的实例(包括主、从、其他sentinel在内)发送ping命令，并通过实例返回的ping命令回复来判断实例是否在线。例如：有二个sentinel服务，共同监视一主二从的redis服务。(1) sentinel服务将向sentine2、主服务master、从服务slave1和slave2发送ping命令。(2) sentine2服务将向sentine1、主服务master、从服务slave1和slave2发送ping命令。实例对于ping命令的回复可以分为两种情况：
(1) 有效回复: 实例返回 +pong 、 -loading、 -masterdown三种回复的其中一种。
(2)无效回复: 实例返回上面三种回复之处的其它回复，或者在指定时限内没有返回任何回复。在Sentinel.conf配置文件中的down-after-milliseconds选项指定了Sentinel判断实例进入主观下线所需的时间长度。
4.1.1主观下线时长选项的作用范围
用户设置down-after-milliseconds选项的值，不仅会被sentinel用来判断主服务器的主观下线状态，还会被用于判断主服务器下的所有从服务器，以及同样监视主服务器的其他sentinel的主观下线状态。
-- 例如用户向sentinel设置以了下配置：
sentinel monitor master 127.0.0.1
sentinel down-after-milliseconds master
这里的master是主服务器的名称， 端口默认6379 ，2代表sentinel集群中有2个sentinel认为master 状态下线时，才能真正认为该master已经不可用了(也就是客观下线，下面会讲)。这50000毫秒不仅会成为sentinel判断master进入主观下线的标准，还会判断所有从库、其它sentinel进入主观下线的标准。
4.1.2 多个sentinel设置的主观下线时长可能不同
对于多个sentinel共同监视同一个主服务器时，这些sentinle在配置文件sentinle.conf中所设置的down-after-milliseconds值也可能不同，因此当一个sentinel将主服务器判断为主观下线时，其它sentinel可能仍然会认为主服务器处于在线状态。只有全部的sentine都判断进入了主观下线状态时，才会认为主master进入了主观下线状态。
4.2 检查客观下线状态
当sentinel将一个主服务器判断为主观下线之后，为了确认这个主服务器是否真要下线，会向同样监视这一主服务器的其它sentinel进行询问，其它sentinel回复已下线之后，sentinel就会将主服务器从主观判定为客观下线，并对主服务器执行故障转移操作。客观下线条件只适用于主服务器。
客观判断是：sentinel向其它sentinel发送sentinel is-master-down-by-addr命令进行互相交流之后，得出主服务器下线判断。 只要一个 Sentinel 发现某个主服务器进入了客观下线状态， 这个 Sentinel 就可能会被其他 Sentinel 推选出， 并对失效的主服务器执行自动故障迁移操作。
4.2.1 is-master-down-by-addr命令用来判断是否客观下线
命令格式：sentinel is-master-down-by-addr ip port current runid
分别代表主观下线的主服务器ip址址，端口号, sentinel当前的配置纪元用于选举领头羊sentinel, runid可以是*或者sentinel的运行ID。
--例如一个sentinel向其它sentinel发送以下命令：
sentinel is-master-down-by-addr 127.0.0.1 *
最后一个参数：*代表命令仅仅用于检测主服务器客观下线状态。而sentinel的运行ID则用于选举领头羊。当接收的sentinel收到其它sentinel回复的命令时，会取出命令中包含的参数，来检查主服务器是否已下线，然后向源sentinel返回一条信息。该信息包括三个参数：
(1) down_state: 检查主服务器的结果，1代表已下线，2代表未下线。
(2) leader_runid: 如果是* 用于检测主服务器下线状态。如果是runid则是局部领头sentinel的运行ID，用于选举领头sentinel。
(3) leader_epoch: 目标sentinel的局部领头sentinel的配置纪元。
例如返回: 1 * 1 。说明其它sentinel也同意主服务器下线。接收sentinel将统计其他sentinel同意主服务器下线的数量，当这一数量达到配置指定的数量时，就会客观下线，进行故障转移。
例如: sentinel monitor master 127.0.0.1 6379 2 配置是指包括当前sentinel在内，只要总共有两个sentinel 服务认为主服务器已经进入下线状态，那么当前sentinel就将主服务器判断为客观下线。
五. 选举领头sentinel
当一个主服务器被判断为客观下线时，监视这个下线主服务器的各个sentinel会进行协商，选择出一个领头sentinel，并由领头sentinel对下线主服务器执行故障转移操作，关于Redis选举领头sentinel规则和方法就不在述说，请看"redis设计与实现"书籍。
六.故障转移
选举产生领头sentinel之后，领头sentinel将对已下线的主服务器执行故障转移，操作包括三个步骤：
(1) 在已下线的主服务器属下的所有从服务器中，挑选出一个从服务器，并将其转换为主服务器。挑选是经过了严格的一项一项的过滤(如过滤从库下线的，5秒内没有回复领头sentinel的info命令的，与以下线的主服务器连接断开超过down-after-milliseconds *10 毫秒的。这些通通都删除)，之后选出最优的从服务器。向这个从服务器发送slaveof no one命令，将这个从服务器转换为主服务器。
(2) 让已下线主服务器属下的所有从服务器改为复制新的主服务器。领头sentinel向已下线的主服务和所有从服务器(除了新的主服务)发送slaveof 命令，让它们复制新的主服务器。
(3) 将已下线的主服务器设置为从服务器。当已下线的主服务器重新上线时，sentinel就会向它发送slaveof命令，让它成为从服务。
七 sentinel上下二篇原理总结：
对于sentinel的高可用，用了二篇来介绍了sentinel服务、主服务、从服务、其它sentinel服务的原理关系。知识点比较多，下面再总结下：
(1) sentinel只是一个运行在特殊模式下的redis服务器，它使用了和普通模式不同的命令表，以及区别与普通模式下使用的命令不同。
(2) sentinel会读入指定的配置文件(sentinel.conf)，为每个要监视的主服务器创建相应的实例结构，并创建连向主服务器的命令连接和订阅连接，其中命令连接用于向主服务器发送命令请求，订阅连接则用于接收指定频道的消息。
(3) sentinel通过向主服务器发送info命令来获得主服务器属下所有从服务器的地址信息，并为这些从服务器创建相应的实例结构，以及连向这些从服务器的命令连接和订阅连接。
(4) 一般情况下，sentinel以每10秒一次的频率向被监视的主服务器和从服务器发送info命令，当主服务器处于下线状态，或者sentinel正在对主服务器进行故障转移操作时，sentinel向从服务器发送info命令的频率会改为1秒一次。
(5)对于监视同一个主服务器和从服务器的多个sentinel来说，它们会以每2秒一次的频率，通过向被监视的_sentinel_:hello频道发送消息来向其他sentinel宣告自己的存在。
(6)每个sentinel也会从_sentinel_:hello中频道中接收其他sentinel发来的信息，并根据这些信息为其他sentinel创建相应的实例结构，以及命令连接。
(7) sentinel只会与主服务器和从服务器创建命令连接和订阅连接，sentinel与sentinel之间则只创建命令连接。
(8) sentinel以每秒一次的频率向实例(包括主，从，其它sentinel)发送ping命令，并根据实例对ping命令的回复来判断实例是否在线，当一个实例在指定的时长中连续向sentinel发送无效回复时，sentinel会将这个实例判断为主观下线。
(9)当sentinel将一个主服务器判断为主观下线时，它会向同样的监视这个主服务器的其他sentinel进行询问，看它们是否同意这个主服务器已经进入主观下线状态。
(10)当sentinel收集到足够多的主观下线投票之后，它会将主服务器判断为客观下线，并发起一次针对主服务器的故障转移操作。