Sentinel 重点

Sentienel(哨兵机制) 是Redis的高可用的解决方案，就这么一句话，使我们在面试的道路上艰难前进。

首先高可用是什么，高可用就是一个集群，少了谁都能用，即使它当时是主节点。

首先主从集群中，往往都是只有一个主节点做整个集群的核心。俗话说擒贼先擒王，如果主节点死了，那这个集群也就随着崩塌了。

那么为了放着这种情况的发生，人们开始想解决办法，既然王被擒了，那咱们投票再选出来一个不久其了，先让其当着，至于原先的王能救则救，救不了就放弃(残忍，狠心)。通过这种想法，ZAB算法诞生了。

ZAB：整个集群中会有一个王(领导者),其余都是小兵，平常都是王下达命令给小兵，小兵去做，做完了汇报，当有一半以上的小兵汇报任务做完，王会知道这个命令已经成功做完了。突然有一天王被擒住了，这时候群龙无首怎么办，小兵A自告奋勇举荐自己当新王，并拉动旁边的小兵为自己拉票。那么不光小兵A自己想当选，小兵B也想当选，而每个小兵都只有一票，所以最后肯定会有一个人胜出，但是如果双方得到的票数一样怎么办那？如果得到的一样那就重新再投一次呗。假设小兵A成功胜出成了新王，那么小兵A就开始管理整个集群组织了。而原先的王被释放了回来，这时，小兵A看了看原先的王说，你就去旁边接替我以前的职位吧！就这样小兵A成了新王，而原来的王成了小兵！！！(成功上位)

说了这么多，那么跟这个哨兵机制有什么关系那？

首先大部分的高可用最终一致性集群的机制都差多为主节点死了，就去在从节点提拔一个来当主节点

不信？？？ 比如：rabbit里面的镜像队列，mysql主从复制，zookeeper高可用等

那么哨兵机制也是这样，主服务器死了，那就从这个从节点里面选取一个成为新的主服务器。

只是哨兵机制不同的是，选取主节点的工作不是由其从节点自告奋勇得出的，而是拜托给了一个委员会，由委员会指派某个从节点产生。

然后，委员会会向每个从节点发送同步复制主服务器的命令，让其数据一致。

这是如果原先主节点上线了，委员会会告诉它，你不行了去当小兵吧。原先主节点会变成从节点加入集群。

Sentinel会成为主服务器的客户端

Sentinel不会只有一个节点，因为如果只有一个节点会产生单点故障问题。所以会由一个Sentinel集群下面我成委员会。当主服务器被判断为客观下线后，委员会会选举一个委员长，由它来代表委员会执行故障转移操作。

委员长会选取从节点数据最新的节点充当主服务器(复制偏移量最大。如果复制偏移量相同，则使用ID最小的服务器)