Redis哨兵架构基础

1. 哨兵的介绍

   sentinel ， 中文是哨兵。

   哨兵是redis 集群架构中非常重要的一个组件，主要功能如下：

   （1）集群监控：负责监控reidis master 和slave 进程是否正常工作；

   （2）消息通知：如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员；

   （3）故障转移：如果master node挂掉了，会自动转移到slave node上；

   （4）配置中心：如果故障转移发生了，通知client 客户端新的master 地址；

   哨兵本身也是分布式的作为一个哨兵集群去运行，互相协同工作；

   （1）故障转移时， 判断一个master node宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题；

   （2）即使部分哨兵节点挂了，哨兵集群还是能正常工作的，因为如果 一个作为高可用机制重要组成部分的故障转移系统本身是单点的，那就坑爹了；目前采用的是sentinel 2 版本，sentinel2 相对于 sentinel 1 来说，重写了很多代码，主要是让故障转移的机制和算法变得更加健壮和简单。

2. 哨兵的核心知识

   （1）哨兵至少需要3个实例，来保证自己的健壮性；

   （2）哨兵+redis 主从的部署架构，是不会保证数据0丢失的，只能保证redis 集群的高可用性；

   （3）对于哨兵+redis主从这种负责的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练；

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

   哨兵集群必须部署2个以上节点，如果哨兵集群仅仅部署了2个哨兵实例，quorum=1

   M1 R1

   S1 S2

   Configuration：quorum = 1 (哨兵节点只要1个认为宕机就可以进行切换了)

   master 宕机，s1 和 s2 中只要有一个哨兵认为宕机就可以进行切换，同时s1和s2中会选举出一个哨兵来进行故障转移，同时这个时候，需要majority，也就是大多数哨兵都是运行的，2个哨兵的majority就是2，2个哨兵都运行这，就可以允许执行故障转移，但是整个M1和S2运行的机器宕机了，那么哨兵只有1个了，此时就没有majority来允许执行故障转移，虽然另外一台机器还有一个R1，但是故障转移不会执行；(更多细节weixin 关注 “SpringForAll社区”)

4. 经典的3节点哨兵集群

       M1
   
       S1
   

   R2 R3

   S2 S3

   Configuration：quorum = 2 majoiry

   如果M1所在机器宕机了，那么3个哨兵还剩下2个，S2和S3可以一致认为master 宕机，然后选举一个来执行故障转移；同时3个哨兵的majoiry = 2 ， 所以还剩下2个哨兵运行着，就可以进行故障转移。