redis主从复制--------哨兵机制

哨兵的介绍

sentinel，中文名是哨兵，

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

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

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

（1）故障转移时，判断一个master node是宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题
（2）即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的，那就很坑爹了

哨兵的基础知识

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

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

数量为quorum的哨兵认为节点宕机了 那么节点就宕机了。数量为majority的哨兵来进行选举对应的Master节点。

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

   如果哨兵集群仅仅部署了个2个哨兵实例，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个哨兵都运行着，就可以允许执行故障转移

哨兵进行主备切换时候出现的数据丢失问题

• 异步复制导致的数据丢失

        因为Master节点的数据要异步进行同步到slave节点上，如果在复制的过程中Master就宕机了，就会出现数据丢失的问题。

• 集群脑裂导致的数据丢失

       脑裂的问题就是在数据集群的状态下，当Master节点的机器因为网络的原因（各种原因吧），有quorum数量的数量的机器认为Master已经宕机了，然后开始重新选举产生一个Master节点。旧的Master节点处于一个假死的状态。Client可以正常的连接Master，可以继续向Master进行写入数据，不会向新的Master节点进行输入数据。等网络恢复（或者什么别的原因）。旧的的Master重新回归集群的时候。旧的Master成为了一个新的Slave，会重新复制新的Master上的数据。但是新的Master上的数据就会缺少。

哨兵主备切换时候数据丢失的问题解决方案

min-slaves-to-write 1
min-slaves-max-lag 10

这两个的配置的意思是：要求至少有1个slave，数据复制和同步的延迟不能超过10秒，如果说一旦所有的slave，数据复制和同步的延迟都超过了10秒钟，那么这个时候，master就不会再接收任何请求了。

上面两个配置可以减少异步复制和脑裂导致的数据丢失

哨兵集群的自动发现机制

        哨兵互相之间的发现，是通过redis的pub/sub系统实现的，每个哨兵都会往__sentinel__:hello这个channel里发送一个消息，这时候所有其他哨兵都可以消费到这个消息。并感知到其他的哨兵的存在。每隔两秒钟，每个哨兵都会往自己监控的某个master+slaves对应的__sentinel__:hello channel里发送一个消息，内容是自己的host、ip和runid还有对这个master的监控配置，每个哨兵也会去监听自己监控的每个master+slaves对应的__sentinel__:hello channel，然后去感知到同样在监听这个master+slaves的其他哨兵的存在。每个哨兵还会跟其他哨兵交换对master的监控配置，互相进行监控配置的同步。

Save--->Master的选举机制

  如果集群中的Master认为宕机了。哨兵的集群会进行重新选择一个新的Master，选择Master的原则有以下几个：

1. 与Master断开的时长 
2. 按照slave的优先级进行排序，选择优先级高的。
3. 如果优先级相同，看从主节点中复制的数据量（也就是offset的值的大小）
4. 如果以上两个值相等话，就选择一个 runid比较的一个值

哨兵的工作方式

       1. 每个Sentinel 以每秒钟一次的频率向它所知的主服务器、从服务器以及其他 Sentinel 实例发送一个 PING 命令

        2. 如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 那么这个实例会被 Sentinel 标记为主观下线。 一个有效回复可以是： +PONG 、 -LOADING 或者-MASTERDOWN 。

        3. 如果一个主服务器被标记为主观下线， 那么正在监视这个主服务器的所有 Sentinel 要以每秒一次的频率确认主服务器的确进入了主观下线状态。

        4. 如果一个主服务器被标记为主观下线， 并且有足够数量的 Sentinel （至少要达到配置文件指定的数量）在指定的时间范围内同意这一判断， 那么这个主服务器被标记为客观下线。

       5. 在一般情况下， 每个 Sentinel 会以每10 秒一次的频率向它已知的所有主服务器和从服务器发送 INFO 命令。 当一个主服务器被 Sentinel 标记为客观下线时， Sentinel 向下线主服务器的所有从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次
       6. 当没有足够数量的 Sentinel 同意主服务器已经下线， 主服务器的客观下线状态就会被移除。 当主服务器重新向 Sentinel 的 PING 命令返回有效回复时， 主服务器的主观下线状态就会被移除。