一.出现的背景：
Redis 主从复制模式下一旦主节点由于故障不能提供服务，需要人工将从节点晋升为主节点，同时还要通知应用方更新主节点地址，对于很多应用这种场景的这种故障处理方式是非常浪费人力的。为了提供Redis主从的高可用性，Redis从2.8版本开始提供Redis Sential（哨兵）架构来解决问题。
二.架构图：
三.Redis Sentinel的高可用方案主要介绍：
由上图可以看到Redis Sentinel是一个分布式架构，包含若干个Sentinel节点和Redis数据节点，每个Sentinel节点会对数据节点和其余Sentinel节点进行监控，当它发现节点不可达时，会对节点做下线标识，如果被标识的是主节点，它还会和其他Sentinel节点进行“协商”，当大多数Sentinel节点都认为主节点不可达时他们会选举出一个Sentinel节点来完成自动故障转移的工作，选举出新的主节点，将老的主节点降级为从节点，同时会将这个变化实时通知给Redis应用方。
四.基本实现原理：
1.执行三个定时任务用于获取及同步各端(主节点、从节点、Sentinel节点)信息：
A.每隔10秒获得主从节点信息；（通过info命令）
B.每隔2秒同步主节点及当前sentinel节点信息； （通过redis的订阅功能）
C.每隔1秒各个Sentinel节点实现同其他端之间的心跳检测；（通过ping命令）
2.下线有问题的节点:
主观下线：每个Sentinel节点会每隔1秒对主从节点及其他Sentinel节点发送ping命令做心跳检测，当这些节点超过down-after-milliseconds没有进行有效回复时Sentinel节点会对该节点做失败判定，这个行为即主观下线。（该主观下线的判定是当前一个Sentinel的判定所以也存在误判的可能，比如刚好那时的网络问题）
客观下线：当Sentinel接待主观下线的是主节点时，该Sentinel会通过sentinel is-master-down-by-addr命令其他Sentinel节点询问对主节点的判断，当超过quorum（判定主节点最终不可达所需的票数）个数时，Sentinel节点会认为该主节点确实有问题，这时Sentinel节点会做出客观下线的决定。
3.领导者Sentinel节点选举(Raft算法)用于去做故障转移的leader（即选谁去领导这次故障转移，现实中一般是谁先发现了这个故障谁就成为leader的可能性最大，而且这个选举的过程很快）。
该选举过程主要包含：
(1)每个在线的Sentinel节点都有资格成为领导者，当它确认主观下线时会向其他Sentinel节点发送sentinel is-master-down-by-addr命令，要求将自己设置为领导着。
(2)收到命令的Sentinel节点如果没同意过其他Sentinel节点的sentinel is-master-down-by-addr命令，则将统一改请求，否则拒绝。
(3)如果该Sentinel节点发现自己的票数已经大于等于max(quorum，num(sentinels)/2+1),那么它将成为领导者。（现实中一旦一个Sentinel节点获得了max(quorum，num(sentinels)/2+1) 的票数，其他Sentinel节点再去确认已经没有意义因为每个Sentinel节点只有一票）
(4)如果此过程没有选举出领导者，则将进入下一次类似这样的选举。
4.故障转移：
(1).Sentine领导者节点从从节点列表中选出一个节点作为新的主节点，选择过程如下图：
(2).Sentinel领导者节点会对第一步选出来的从节点执行slaveof no one命令让其成为主节点。
(3).Sentinel领导者节点会向剩余的从节点发送命令，并让他们成为新主节点的从节点。
(4)Sentinel节点集合将原来的主节点更新为从节点，并保持对其关注，当其回复后命令它去复制新的主节点数据。
