//
Redis开发与运维学习笔记---(17)
//
Redis Sentinel实现原理---(一)
前面的文章讲述了redis sentinel可以实现对redis master的可用性监控和故障转移，今天从原理上来理解这个过程,sentinel的实现原理分为三个定时任务、主观下线和客观下线、sentinel领导者选举以及故障转移4个部分，今天来看前两个部分。
三个定时监控任务
Redis Sentinel通过三个定时监控任务完成对各个节点的发现和监控。
任务一：
每隔10s，每隔sentinel节点会向主节点和从节点发送info命令，获取最新的拓扑结构。
sentinel通过对info节点的结果解析，就能找到响应的从节点。这个info的定时任务，它的具体作用有如下三个方面：
a、通过向主节点执行info命令，获取从节点的信息。
b、当有新的从节点加入时，都可以立刻感应出来
c、节点不可达或者故障转移之后，可以通过info命令实时更新节点的拓扑信息
任务二：
每隔2s，每隔sentinel节点会向redis数据节点的__sentinel__:hello频道上发送该sentinel节点对于主节点的判断以及当前sentinel节点的信息。同时每隔sentinel节点也会订阅该频道，来了解其他sentinel节点以及他们对主节点的判断，所以这个定时任务可以在sentinel节点之间交换主节点的状态，作为后面客观下线以及领导者选举的依据。
任务三：
每隔1s，每隔sentinel节点会向主节点，从节点，其余sentinel节点发送一条ping命令做一次心跳检测，来确认这些节点当前是否可达，实现对每隔节点的监控，这个定时任务是节点失败判断的重要依据。
主观下线和客观下线
先看主观下线
监控过程中的第3个定时任务ping，如果在down-after-milliseconds没有收到有效的回复，sentinel节点就会对该节点做失败判断，这个行为叫做主观下线，主观下线是sentinel作出的判断，存在误判的可能。
再看客观下线
当sentinel主观下线的节点时主节点时，该sentinel节点会通过sentinel is-master-down-by-addr命令向其他sentinel节点询问对主节点的判断，当超过<quorum>个数的sentinel节点人为主节点确实有问题，这时该sentinel节点会作出客观下线的决定，也就是说，当大部分sentinel节点都对主节点的下线做了同意的判定，那么这个判定就是客观的。
这里对is-master-down-by-addr命令做个介绍，该命令使用方法如下：
代码语言：javascript复制sentinel is-master-down-by-addr ip port current_epoch runid其中：
IP指主节点IP，PORT指主节点端口，
current_epoch指当前配置纪元(纪元请参考raft算法)，
runid，当其为*时，作用是sentinel节点直接交换对主节点下线的判定。当runid等于当前sentinel节点的runid时，作用是当前sentinel节点希望目标sentinel节点同意自己成为领导者。该命令的返回值包含3个参数：
down_state：目标sentinel对主节点的下线判断，1
是下线，0是在线
leader_runid：当leader_runid等于*时，代表返回结果是用来做主节点是否不可达，当leader_runid等于具体的runid时，代表目标节点同意runid成为领导者。
leader_epoch:领导者纪元(纪元请参考raft算法)
时间原因，下篇文章，我们将详细展开领导者sentinel节点选举过程和故障转移过程。
