Redis哨兵机制详解

Redis 哨兵机制详解

定义及主要功能

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

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

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

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

目前采用的是sentinal 2版本，sentinal 2相对于 sentinal 1版本来说，重写了很多代码，主要是让故障迁移的机制和算法变得更加健壮和简单

哨兵的核心知识

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

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

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

majority = 1 
configuration: quorum = 1

master宕机，s1 和 s2中只要有一个哨兵认为master 宕机就可以执行切换，同时s1和s2会选举出来一个sentinal来执行故障转移同时这个时候，需要majority,也就是大多数哨兵都是运行的，2个哨兵的majority就是2，2个哨兵都运行着，就可以允许执行故障转移，但是如果是整个m1 和 s1运行的机器宕机了，那么哨兵就只有一个了，此时就没有majority来允许执行故障转移，虽然另外一台机器还有一个R1,但是故障转移不会执行

经典的3节点哨兵集群

Configuration: quorum  = 2
majority = 2

如果M1所在的机器宕机了，那么三个哨兵还剩下两个，S1和S3可以一致认为master宕机，然后选举出来一个执行故障转移，同时3个哨兵的majority是2，所以还剩下的两个哨兵运行着，就可以允许故障转移