Redis中的Sentinel(五)
Sentinel
检测主观下线状态
在默认情况下，Sentinel会以每秒一次的频率向所有与它创建了命令连接的实例(包括主服务器、从服务器、其他Sentinel在内)
发送PING命令，并通过实例返回的PING命令回复来判断实例是否在线。如图所示，带箭头的连线显示了Sentinel1和Sentinel2是如何向实例发送PING命令的:
- 1.Sentinel1将向Sentinel2、主服务器master、从服务器slave1和slave2发送PING命令
- 2.Sentinel2将向Sentinel1、主服务器master、从服务器slave1和slave2发送PING命令
实例对PING命令的回复可以分为以下两种情况:
- 1.有效回复:实例返回+PONG、-LOADING、-MASTERDOWN三种回复的其中一种
- 2.无效回复:实例返回+PONG、-LOADING、-MASTERDOWN三种回复之外的其他回复，或者在指定时间内没有返回任何回复
Sentinel配置文件中的down-after-milliseconds选项指定了Sentinel判断实例进入主观下线所需的时间长度:如果一个实例在down-after-milliseconds毫秒内，连续向Sentinel返回无效回复，那么Sentinel会修改这个实例所对应的实例结构，在结构的flags属性中打开SRI_S_DOWN标识，以此来表示这个实例已经进入主观下线状态。以上图展示的情况为例，如果配置文件指定Sentinel1的down-after-milliseconds选项的值为50000毫秒，那么当主服务器master连续50000毫秒都向Sentinel1返回无效回复时，Sentinel1就会将master标记为主观下线，并在master所对应的实例结构的flags属性中打开SRI_S_DOWN标识，如图所示
主观下线时长选项的作用范围
用户设置的down-after-milliseconds选项的值，不仅会被Sentinel用来判断主服务器的主观下线状态，还会被用于判断主服务器属下的所有从服务器，以及所有同样监视这个主服务器的其他Sentinel的主观下线状态。举个例子，如果用户向Sentinel设置了以下配置:
sentinel monitor master 127.0.0.1 6379 2
sentinel down-after-milliseconds master 50000
那么50000毫秒不仅会成为Sentinel判断master进入主观下线的标准，还会成为Sentinel判断master属下所有从服务器，以及所有同样监视master的其他Sentinel进入主观下线的标准。
多个Sentinel设置的主观下线时长可能不同
down-after-milliseconds选项的另一个需要注意的地方是，对于监视同一个主服务器的多个Sentinel来说，这些Sentinel所设置的down-after-milliseconds选项的值也可能不同，因此，当一个Sentinel将主服务器判断为主观下线时，其他Sentinel可能仍然会认为主服务器处于在线状态。举个例子，如果Sentinel1载入了以下配置
sentinel monitor master 127.0.0.1 6379 2
sentinel down-after-milliseconds master 50000
而Sentinel2则载入了以下配置:
sentinel monitor master 127.0.0.1 6379 2
sentinel down-after-milliseconds master 10000
那么当master的断线时长超过10000毫秒之后，Sentinel2会将master判断为主观下线，而Sentinel1却认为master仍然在线。只有当master的断线时长超过50000毫秒之后，Sentinel1和Sentinel2才会都认为master进入了主观下线状态
检查客观下线状态
当Sentinel将一个主服务器判断为主观下线之后，为了确认这个主服务器是否真的下线了，它会向同样监视这一主服务器的其他Sentinel进行询问，看它们是否也认为主服务器已经进入了下线状态(可以是主观下线或者客观下线)。当Sentinel从其他Sentinel那里接收到足够数量的已下线判断之后，Sentinel就会将从服务器判定为客观下线，并对主服务器执行故障转移
发送SENTINEL is-master-down-by-addr命令
Sentinel使用:
SENTINEL is-master-down-by-addr <ip> <port> <current_epoch> <runid>
命令询问其他Sentinel是否同意主服务器已下线，命令中的各个参数的意义如表所示
例子
- 举个例子，如果被Sentinel判断为主观下线的主服务器的IP为127.0.0.1，端口号为6379，并且Sentinel当前的配置纪元为0，那么Sentinel将向其他Sentinel发送以下命令:
SENTINEL is-master-down-by-addr 127.0.0.1 6379 0 *
接收SENTINEL is-master-down-by-addr命令
当一个Sentinel(目标Sentinel)接收到另一个Sentinel(源Sentinel)发来的SENTINEL is-master-down-by-addr 命令时,目标Sentinel会分析并取出命令请求中包含的各个参数，并根据其中的主服务器IP和端口号，检查主服务器是否已经下线，然后向源Sentinel返回一条包含三个参数的Multi Bulk回复作为SENTINEL is-master-down-by命令的回复:
1.<down_state>
2.<leader_runid>
3.<leader_epoch>
这三个参数表示的含义，如表所示
例子
举个例子。如果一个Sentinel返回以下回复作为SENTINEL is-master-down-by-addr命令的回复:
1.1
2.*
3.0
那么说明Sentinel也同意主服务器已下线
接收SENTINEL is-master-down-by-addr命令的回复
根据其他Sentinel发回的SENTIENL is-master-down-by-addr命令回复，Sentinel将统计其他Sentinel同意主服务器已下线的数量，当这一数量到达到配置指定的判断客观下线所需的数量时，Sentinel会将主服务器实例结构flags属性的SRI_O_DOWN标识打开，标识主服务器已经进入客观下线状态，如图所示
客观下线状态的判断
当认为主服务器已经进入下线状态的Sentinel的数量，超过Sentinel配置中设置的quorum参数的值，那么该Sentinel就会认为主服务器已经进入客观下线的状态。比如说，
sentinel monitor master 127.0.0.1 6379 2
那么包括当前Sentinel在内，只要总共有两个Sentinel认为主服务器已经进入下线状态，那么当前Sentinel就将主服务器判断为客观下线，又比如说，如果Sentinel在启动时载入了以下配置:
sentinel monitor master 127.0.0.1 6379 5
那么包括当前Sentinel在内，总共要有五个Sentinel都认为主服务器已经下线，当前Sentinel才会将主服务器判断为客观下线
不同Sentinel判断客观下线的条件可能不同
对于监视同一个主服务器的多个Sentinel来说，它们将主服务器判断为客观下线的条件可能也不同:当一个Sentinel将主服务器判断为客观下线时，其他Sentinel可能并不是那么认为的。比如说，对于监视同一个主服务器的五个Sentinel来说，如果Sentinel1在启动时载入了以下配置:
sentinel monitor master 127.0.0.1 6379 2
那么当五个Sentinel中有两个Sentinel认为u主服务器已经下线时，Sentinel就会将主服务器判断为客观下线。而对于载入了以下配置的Sentinel2来说
sentinel monitor master 127.0.0.1 6379 5
仅有两个Sentinel1认为主服务器已下线，并不会令Sentinel2将主服务器判断为客观下线。