关于redis的哨兵

 　　之前有说到redis的主从分离架构以实现提高redis的高水平扩展能力，但是单单是这样的主从架构是存在着一些问题的：

　　master（主）节点挂了会发生什么？

　　master挂了，那么master下的从节点同样的处于不可用状态了。即master那一片都挂了。因为slave（从）节点不能再接收到新的数据

　　slave节点挂了会怎么样？

　　如果是一个slave节点挂了，那么还有其他的slave节点对外提供服务，不至于所有的请求都发向后台的数据库中导致数据库压力突然增大。

　　redis进程挂掉了会怎么样？

　　这就比较厉害了，进程挂掉了redis就没用了，有的时候redis进程挂掉了，而你有恰好没有给redis设置数据的持久化，redis可能会丢失较多的数据，除此外这台机器的这个进程的redis肯定也不能对外提供服务了。带来的问题就和前面两个一样的了，如果是master的进程，同master节点挂了；如果是slave的进程，同slave节点挂了。

　　解决办法：

　　哨兵，对zookeeper有了解的话会很容易理解这个机制，在这里简要的说明一下哨兵的工作。这里以zookeeper来做哨兵模式的讲解。首先zookeeper是一个分布式锁的服务，根据CPA理论，在分布式系统中，系统只能达到CAP理论中的两个要求，无法满足全部三个。

　　这个不难理解。C：数据的一致性，P：数据的分区容错性，A:数据的可用性。zookeeper实现的主要是CAP中的一致性（C）和分区容错性（P）不过你就算姑且认为zookeeper主要实现的是一致性（C）也ok，zookeeper在A方面的确不算强调的地方。同时由于zookeeper的非高可用性，zookeeper被认为不适合作为服务发现的系统。当然并非说zookeeper不能用，只是他的可用性不算好而已。zookeeper实现其强一致性还依靠于其树状的文件式的结构，拿到一个节点创建一个文件等于拿到一个锁，并拒绝其他人获取这个锁。其他想获取这个锁的人需要等待并排队，同时监听（watcher 机制）当前锁是否被释放，如果监听的锁释放且当前等待之前没有其他的等待者，那么获取这个锁。并执行需要的操作。

　　回到哨兵机制：哨兵是为了保证主从架构的可用性。在需要监听的进程的机器下开一个哨兵进程，哨兵进程会监视主进程，如master节点是否挂掉了之类的，并且记录其信息，根据信息判断监视的节点是否真的挂了，挂掉了的话就要重新选举master节点，以求保证高可用性。那么这和zookeeper又有什么关系呢？

　　　　前面有提到，因为zookeeper的强一致性，zookeeper提供的信息通常都是准确的，且是当前状态最正确的（分布式系统中），那么哨兵将它监视的节点的内容存放到zookeeper的一个节点下就能保证其他节点一直无法在这个节点下写内容，只有当哨兵主动删除这个节点时其他节点才有机会向这个节点写内容。什么时候哨兵会主动删除节点？当哨兵觉得它监听的进程处于挂掉状态的时候，。

　　　　接下来说一下redis中的哨兵：

redis集群架构中的哨兵主要功能：

1. 集群监控，负责监控redis master和slave进程是否正常工作
2. 消息通知，如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员
3. 故障转移，如果master node挂掉了，会自动转移到slave node上
4. 配置中心，如果故障转移发生了，通知client客户端新的master地址

 

关于哨兵   再讲

（1）哨兵至少需要3个实例，来保证自己的健壮性
（2）哨兵 + redis主从的部署架构，是不会保证数据零丢失的，只能保证redis集群的高可用性
（3）对于哨兵 + redis主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练

为什么redis哨兵集群只有2个节点无法正常工作？

哨兵集群必须部署2个以上节点

如果哨兵集群仅仅部署了个2个哨兵实例，quorum=1

+----+ 　　  +----+
| M1 |---------| R1 |
| S1 |　　    | S2 |
+----+　　   +----+

Configuration: quorum = 1

master宕机，s1和s2中只要有1个哨兵认为master宕机就可以还行切换，同时s1和s2中会选举出一个哨兵来执行故障转移

同时这个时候，需要majority，也就是大多数哨兵都是运行的，2个哨兵的majority就是2（2的majority=2，3的majority=2，5的majority=3，4的majority=2），2个哨兵都运行着，就可以允许执行故障转移

但是如果整个M1和S1运行的机器宕机了，那么哨兵只有1个了，此时就没有majority来允许执行故障转移，虽然另外一台机器还有一个R1，但是故障转移不会执行

3节点哨兵集群

　　   +----+
　　　| M1 |
　　　| S1 |
　　　+----+
　　　　|
+----+     |　 +----+
| R2 |----+----| R3 |
| S2 |    　　 | S3 |
+----+ 　　   +----+

Configuration: quorum = 2，majority

如果M1所在机器宕机了，那么三个哨兵还剩下2个，S2和S3可以一致认为master宕机，然后选举出一个来执行故障转移

同时3个哨兵的majority是2，所以还剩下的2个哨兵运行着，就可以允许执行故障转移。

好了现在关于redis的主从节点切换的哨兵差不多讲了一些。但是哨兵带来的问题还是很烦人的。。

　　由于哨兵集群通常监视的是分布式系统的集群，哨兵自然也是分布式，那就会带来CAP的问题：

　这里指的CAP是哨兵与其他系统之间的CAP还有切换前的master与切换后的master数据不一致，并非哨兵之间的CAP。