Redis Sentinel实现了Redis的高可用，其基本原理包括：Sentinel的3个定时监控任务，主观下线和客观下线，Sentinel领导者选举，和故障转移。
3个定时监控任务
1. 每隔10s，每个Sentinel节点会向主节点和从节点发送info命令获取最新的拓扑结构。
$ redis-cli -p 6481 -a abcdefg monitor | egrep '127.0.0.1:51934.*INFO'
1532419769.058192 [0 127.0.0.1:51934] "INFO"
1532419779.081816 [0 127.0.0.1:51934] "INFO"
1532419789.089331 [0 127.0.0.1:51934] "INFO"
1532419799.118555 [0 127.0.0.1:51934] "INFO"
$ netstat -atunlp | grep 51934
tcp 0 0 127.0.0.1:51934 127.0.0.1:6481 ESTABLISHED 23418/redis-sentine
tcp 0 0 127.0.0.1:6481 127.0.0.1:51934 ESTABLISHED 24055/redis-server
2. 每隔2s，每个Sentinel节点会向Redis数据节点的__sentinel__:hello频道发送该Sentinel节点对于主节点的判断以及当前Sentinel节点的信息。另外每个Sentinel节点会订阅一组事件频道(如+sdown频道，发布主观下线的消息)，共享Sentinel节点间的事件。
$ redis-cli -p 6481 -a abcdefg monitor | egrep '127.0.0.1:51934.*PUBLISH'
1532420062.524075 [0 127.0.0.1:51934] "PUBLISH" "__sentinel__:hello" "127.0.0.1,26481,2e1df3bfaad006ad90295492eef2bc9b923abbf1,4,sfmaster,127.0.0.1,6481,4"
1532420064.531796 [0 127.0.0.1:51934] "PUBLISH" "__sentinel__:hello" "127.0.0.1,26481,2e1df3bfaad006ad90295492eef2bc9b923abbf1,4,sfmaster,127.0.0.1,6481,4"
1532420066.617168 [0 127.0.0.1:51934] "PUBLISH" "__sentinel__:hello" "127.0.0.1,26481,2e1df3bfaad006ad90295492eef2bc9b923abbf1,4,sfmaster,127.0.0.1,6481,4"
1532420068.667024 [0 127.0.0.1:51934] "PUBLISH" "__sentinel__:hello" "127.0.0.1,26481,2e1df3bfaad006ad90295492eef2bc9b923abbf1,4,sfmaster,127.0.0.1,6481,4"
$ redis-cli -p 26479 -a abcdefg subscribe +sdown
...
1) "message"
2) "+sdown"
3) "master sfmaster 127.0.0.1 6480"
$ redis-cli -p 26480 -a abcdefg subscribe +odown
...
1) "message"
2) "+odown"
3) "master sfmaster 127.0.0.1 6480 #quorum 2/2"
3. 每隔1s，每个Sentinel节点会向主节点，从节点，其余Sentinel节点发送一条ping命令做心跳检测，确认这些节点是否可达。
$ redis-cli -p 6481 -a abcdefg monitor | egrep '127.0.0.1:39042.*PING'
1532421426.017054 [0 127.0.0.1:39042] "PING"
1532421427.034552 [0 127.0.0.1:39042] "PING"
1532421428.049429 [0 127.0.0.1:39042] "PING"
1532421429.079257 [0 127.0.0.1:39042] "PING"
主观下线和客观下线
1. 主观下线
每个Sentinel节点间隔1s对主节点，从节点，其它Sentinel节点发送ping命令做心跳检测，当这些节点超过down-after-milliseconds没进行有效回复时，Sentinel节点就会对该节点做不可达判定，该行为叫主观下线。
2. 客观下线
当Sentinel主观下线的节点是主节点时，该Sentinel节点会通过sentinel is-master-down-by-addr命令，向其它Sentinel节点询问对主节点的判断，当超过<quorum>个Sentinel节点认为主节点有问题时，该Sentinel节点会做客观下线决定。
从主观下线到客观下线的过程，Redis没有使用什么一致性算法，仅依据gossip协议在有效时间范围内收到其它Sentinel节点的确认即可。
领导者Sentinel节点选举
某Sentinel节点对主节点做客观下线后，需要选举出领导者进行故障转移工作，Redis使用了Raft算法实现领导者选举，大致思路如下。
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)了，那么它将成为领导者。
4. 若此过程没有选举出领导者，将进入下一轮选举。
故障转移
选举出的领导者Sentinel节点负责故障转移，具体步骤如下。
1. 在从节点中找出一个合适节点作为新的主节点。
2. 领导者Sentinel节点会对选出来的从节点执行slaveof no one命令，让其成为主节点。
3. 领导者Sentinel节点会向剩余的从节点发送命令，让它们成为新主节点的从节点，复制规则和参数parallel-syncs有关。
4. Sentinel节点集合会将原来的主节点在配置文件中更新为从节点，当其恢复后命令它去复制新的主节点。
若感兴趣可关注订阅号”数据库最佳实践”(DBBestPractice).
