Redis哨兵模式原理

哨兵模式是一种特殊的模式，它是一个独立的进程，作为进程，它可以独立运行，在保证Redis主从复制的基础上增加了监听节点状态的功能，当master节点故障时，能自动完成主备切换，只不过仍然不能横向扩容。

哨兵模式原理的关键点是定时任务+Raft算法。
第一个定时任务是每隔10秒，每个Sentinel节点会向主节点和其从节点发送info命令获取最新的节点拓扑结构，如下图所示：

第二个定时任务是每隔两秒，每个Sentinel节点会向Redis节点的_sentinel_:hello频道上发送该Sentinel节点对于主节点的判断以及当前Sentinel节点的信息，同时每个Sentinel节点也会订阅该频道来了解其他Sentinel信息以及它们对于主节点的判断，如下图所示：

第三个定时任务是每隔一秒，每个Sentinel节点会向其他Sentinel节点以及Redis的主从节点发送ping命令做一次心跳检测，来确认这些节点是否可达，如下图所示：
 

主观下线：通过上面的第三个定时任务，如果某个节点超过down-after-milliseconds没有进行回应，那么Sentinel节点就会对该节点做失败判定。

客观下线：当Sentinel主观下线的节点是主节点时，该Sentinel节点会通过sentinel is-master-down-by-addr命令向其他Sentinel节点询问对主节点的判断，当超过<quorum>个数时，那么Sentinel节点就认为该主节点有问题，这时会对主节点进行客观下线。

当判断Master节点客观下线时，这时Sentinel节点之间会通过Raft算法来选举出一个Master节点，Raft算法详细解释如下（也可查看http://thesecretlivesofdata.com/raft/）：
Raft是一个实现分布式一致性的协议，在Raft中有三个状态，分别是Follower（跟随）、Candidate（候选）、Leader。所有节点开始的状态都是Follower，如果处于follower状态的节点没有接收到处于Leader状态的节点的心跳，那么他会变成Candidate状态，然后该节点会从其他节点请求投票，如果他得到了大多数节点的票，那么他的状态将升级为Leader，这个阶段叫领导者选举阶段。

领导者选举之后，系统所有的改变都先通过领导者，每一个改变会被当做一个实体记录进节点的Log中，一开始的时候是不会更新节点数据的，因为这个Log实体并没有提交，为了能提交这个Log实体，它会首先复制到他的从节点，等到大部分从节点反馈已经写入了这个Log实体之后，主节点才会提交，然后更新节点值，然后通知从节点，由此他们达到了一致性，这个过程叫Log Replication。

在领导者选举中，有两个超时时间控制着选举过程，一个叫election timeout（选举超时），它是节点从Follower状态变为Candidate状态的等待时间，是一个150ms到300ms的随机时间，当这个超时时间完了之后，有个节点会从Follower变成Candidate状态并开始选举过程，首先给自己投票，再发送投票请求给其他从节点，如果接收到请求的节点至今还未给其他节点投票，那么就投票给这个节点，然后投完票的这个节点重置它的election timeout，如果Candidate状态的节点得到了大多数节点的票，那么他的状态将升级为Leader。在升级成Leader之后，主节点会复制Log实体并在几个时间间隙内发送到从节点，这个时间叫做heartbeat timeout（心跳超时）。有种情况是如果在这个election timeout完了之后，有两个节点状态同时变为Candidate，他们收到的票数也是一致的情况下，那么又开始重新选举直到有一个胜出者。