redis2.6高可用方案【2】

SDOWN and ODOWN

已经简要地提及本文档中的Redis Sentinel涉及两个不同的关闭概念，一个被称为Subjectively Down condition（SDOWN），由本地哨兵实例发出关闭实例的条件。另一种是Objectively Down condition (ODOWN)即有足够数量的Redis Sentinel发出了SDOWN并从其他的Sentinel获得SENTINEL is-master-down-by-addr命令作为返回状态。

从Sentinel的角度来看，SDOWN 条件就是在设定时间内未收到有效的PING请求回复，而这个时间长度是由配置文件中的is-master-down-after-milliseconds参数确定的。

下面列出的是有效的PING请求回复：

• +PONG
• -LOADING error
• -MASTERDOWN error

任何其他答复（或无应答）被视为无效。

请注意SDOWN的判定无效超时答复的时间由全局配置中确定，例如，如果设置间隔为30000毫秒（30秒），我们收到可接受的PING回复在29秒时，该实例将被视为工作。

ODOWN判定仅适用与master。对于其他类型的实例Sentinel不需要任何协议，所以的ODOWN状态不会到达slave和其他sentinel。

每一个Sentinel的行为如下描述。对于由多个Sentinel构成的分布式系统的行为只是每一个Sentinel实例执行规则的结果（The complete behavior of Sentinel as a distributed system composed of multiple Sentinels only results from this rules followed by every single Sentinel instance）。以下是第一组规则。在这个文件的过程中，将添加更多的规则，在适当的部分。

Sentinel Rule #1:每个Sentinel每秒发送PING到每个已知的master、slave和Sentinel实例。

Sentinel Rule #2:判定实例处于Subjectively Down (SDOWN) 状态，如果最后一次PING答复是down-after-milliseconds参数设定的时间间隔以前。有效的PING答复：+PONG, -LOADING, -MASTERDOWN.

Sentinel Rule #3:每个哨兵是能够回复命令SENTINEL is-master-down-by-addr<ip> <port>.如果这个命令的回复是true并且指定的地址是一个master实例的，那么这个master判定处于SDOWN状态。

Sentinel Rule #4:当一个master处于SDOWN条件时，而且每一个Sentinel仍然在监听这个master，需要每秒使用SENTINEL is-master-down-by-addr命令来确认是否处于此状态。

Sentinel Rule #5:如果一个master满足SDOWN条件时，并且有足够的Sentinel认同master处于此状态，并且在5秒之前回复了SENTINEL is-master-down-by-addr，那么master就可以被标记为Objectively Down (ODOWN)。

Sentinel Rule #6:每间隔10秒，每个Sentinel将发送INFO请求到所有的已知master和slave。如果master处于ODOWN状态，它的slave将被要求每一秒应答INFO请求，而不是每隔10秒。

Sentinel Rule #7:如果sentinel收到的第一个INFO回复是slave发出的而非预期的mater，sentinel将更新检测配置以INFO的输出日志作为master的检测报告替代。所以可以安全的启动针对slave的sentinel。