关于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。