Redis Sentinel主从高可用方案简析

一、Sentinel介绍

Sentinel是redis的高可用性（HA）解决方案: 由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进行下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。

二、Sentinel的主从原理

Redis提供的sentinel（哨兵）机制，通过sentinel模式启动redis后，自动监控master/slave的运行状态，基本原理是：心跳机制+投票裁决

• 监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
• 提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
• 自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。

 

 

 

假设这时s1下线，s2、 s3、 s4停止对s1的复制，sentinel系统会察觉到s1下线；s1下线时长超过用户设定的下线时长限制，sentinel就会开始故障转移操作；

 

 

 

1、sentinel系统会挑选s1下的从服务器，并将它设置为新的主服务器（master）；

• 如何选出新的master？

一、使用如下条件筛选备选node：

1）、删除列表中处于下线或者断线状态的服务器【S_DOWN,O_DOWN,DISCONNECTED】，这样可以保证列表中剩余的服务器都是正常在线的。

2）、删除列表中最近5秒内没有回复领头sentinel的INFO命令的服务器，保证列表中剩余的服务器都是最近成功进行通信的。

3）、删除列表中与原master服务器断开超过down-after-milliseconds*10毫秒的从服务器，保证剩余的服务器没有过早跟主服务器断开连接的。或者说是剩下的从服务器保存的数据是最新的。

4）、Slave priority不等于0（这个是在配置文件中指定，默认配置为100）。

二、从备选node中，按照如下顺序选择新的master

1）、选出优先级比较高的服务器；

2）、较大的replication offset（每个slave在与master同步后offset自动增加）；

3）、较小的runid（每个redis实例，都会有一个runid,通常是一个40位的随机字符串,在redis启动时设置，重复概率非常小）

4）、如果以上条件都不足以区别出唯一的节点，则会看哪个slave节点处理之前master发送的command多，就选谁。

2、sentinel会给s1下的其他服务器，发送新的复制指令，让他们follow新的主服务器；当所有服务器都开始follow新的主服务器，故障转移成功；

 

 

3、sentinel也会配置s1也follow新的主服务器，当s1重新上线时，s1直接follow新主服务器；

 

 

三、主观下线和客观下线

redis sentinel关于被监控的redis实例出现不响应的判断，内部有两种不同的概念：主观下线和客观下线

主观下线(SDOWN)：

当只有单个sentinel实例对redis实例做出无响应的判断，此时进入主观判断，不会触发自动故障转移等操作。

一个服务器必须在 master-down-after-milliseconds 毫秒内， 一直返回无效回复才会被 Sentinel 标记为主观下线。并在主服务器实例的flags属性中打开【SRI_S_DOWN】标识.

不同的sentinel节点，对主观下线的判断时长可以不一样，主要看自己的节点配置。

客观下线(ODOWN) ：

多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断， 并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后， 得出的服务器下线判断。 （一个 Sentinel 可以通过向另一个 Sentinel 发送 SENTINEL is-master-down-by-addr 命令来询问对方是否认为给定的服务器已下线）如果达到配置要求的数量(sentinel的启动配置参数)反馈，则可以标识为客观下线。flags标识为【SRI_O_DOWN】

从主观下线状态切换到客观下线状态并没有使用严格的法定人数算法（strong quorum algorithm）， 而是使用了流言协议： 如果 Sentinel 在给定的时间范围内， 从其他 Sentinel 那里接收到了足够数量的主服务器下线报告， 那么 Sentinel 就会将主服务器的状态从主观下线改变为客观下线。 如果之后其他 Sentinel 不再报告主服务器已下线， 那么客观下线状态就会被移除。

客观下线条件只适用于主服务器： 对于任何其他类型的 Redis 实例， Sentinel 在将它们判断为下线前不需要进行协商， 所以从服务器Slave或者其他 Sentinel 永远不会达到客观下线条件。

客观下线状态的判断条件

sentinel monitor master 127.0.0.1 6379 2 那么有两个sentinel认为主服务器已经下线状态，当前的sentinel就可以认为主服务器客观下线了。

不同的sentinel判断客观下线的条件可能不同

1、sentinel monitor master 127.0.0.1 6379 2 两个sentinel认为主服务器已经下线状态，当前的sentinel就可以认为主服务器客观下线了。

2、sentinel monitor master 127.0.0.1 6379 5 两个sentinel认为主服务器已经下线状态，并不会将主服务器客观下线，只有5个sentinel认为主服务器已经下线了，当前的sentinel才可以认为主服务器客观下线了。

四、选取领头的sentinel

当sentinel发现主库客观下线时候会进行【领头sentinel】选举进行故障恢复，其选举算法采用Raft算法，其设计思想类似与zookpeer的选举机制的zab比较类似，所有在线的sentinel都可以参与选举，都有机会被选为领头的sentinel。选举过程大体如下：

1、 发现主库客观下线的哨兵节点（这里称为A）向每个哨兵节点发送命令【SENTINEL is-master-down-by-addr】,并且命令中包含自己的运行ID（runid），要求对方选举自己为领头哨兵（leader）；

2、 如果目标哨兵没有选举过其他人，则同意将A选举为领头哨兵；回复一条命令，回复中的leader_runid参数和leader_epoch参数，分别记录了领头sentinel的运行ID和配置纪元；

3、 如果A发现有超过半数且超过quorum参数值的哨兵节点同意选自己成为领头哨兵，则A哨兵成功选举为领头哨兵。

4、 Sentinel设置局部领头Sentinel的规则是先到先得，最先向目标sentinel发送设置的源sentinel将成为领头sentinel，而之后接受到的所有设置请求会被拒绝；

5、当有多个哨兵节点同时参与领头哨兵选举时，出现没有任何节点当选可能，此时每个参选节点等待一个随机时间进行下一轮选举，直到选出领头哨兵。