【歪里谐说】3 Redis哨兵

文章内容输出来源：拉勾教育Java高薪训练营，做者：孙里

【歪里谐说】1 JVM内存结构 https://my.oschina.net/u/4033707/blog/4444869

【歪里谐说】2 Java容器 http://www.javashuo.com/article/p-ntqliopi-vd.html

前言

你们好，下期终于来了。此次咱们来记忆下Redis中出镜率比较高的哨兵机制。

说实话哨兵机制的相关课程我已经听过好多遍了，本身也复述过，可是时间一长仍是记不住。自从我想到了这个很是贴近平常的案例，时不时的回忆一下，基本上就忘不了了。

简介

咱们像往常同样，先来回顾下相关的基本概念。

本次的概念比较多，简单分下类：

• Redis哨兵模式简介

• 执行流程

• 检测下线状态

• 哨兵领导者选举

• 故障转移

Redis哨兵模式简介

• 哨兵（Sentinel）是Redis的一个比较简单的高可用解决方案，经过配合主从模式实现。

• 哨兵是一个特殊的Redis服务器，不会进行持久化。

• 由多个哨兵实例组成集群，能够监视多组主服务器和其从服务器。

• 当主服务器进入下线状态时，哨兵能够将该主服务器下的某一从服务器升级为主服务器继续提供服务，从而保证Redis的高可用。

下图为哨兵结构图：哨兵集群 + 服务节点集群（Master主节点 + Slave从节点）。

实线部分为直接通讯，虚线部分为间接通讯。哨兵彼此之间只建立命令链接，而不建立订阅链接，由于哨兵经过订阅主服务器或从服务器，就能够感知到新的哨兵的加入，而一旦新哨兵加入后，相互感知的哨兵经过命令链接来通讯就能够了。

执行流程

• 哨兵实例启动后，每一个实例会建立两个连向服务器的网络链接。

  • 命令链接：用于向主服务器发送命令，并接收响应

  • 订阅链接：用于订阅主服务器__sentinel__:hello频道

• 执行过程当中包含三个方面的处理：检测服务下线状态、哨兵领导者选举、服务故障转移

检测下线状态

分为主观下线状态和客观下线状态。

• 主观下线状态

哨兵每秒1次向全部与它创建了命令链接的实例（主服务器、从服务器和其余哨兵）发送PING命令，如下两种状况即为主观下线（SDown）：

运行状态错误

实例在规定的毫秒（down-after-milliseconds）内返回无效回复（除了+PONG、-LOADING、-MASTERDOWN外）。

超时

实例在规定的毫秒（down-after-milliseconds）内无回复。

• 客观下线状态

当一个哨兵将一个主服务器判断为主观下线后哨兵会向同时监控这个主服务器的全部其余哨兵发送查询命令。 判断它们是否也认为主服务器下线。若是达到哨兵配置中的规定数量（Quorum数量）的哨兵实例都判断主服务器为主观下线，则该主服务器就会被断定为客观下线（ODown）。

下图为认定服务下线的整个流程：

哨兵领导者选举

当一个主服务器被断定为客观下线后，监视这个主服务器的全部哨兵会经过选举算法（Raft），选出一个哨兵的领导者(Leader) 去执行故障转移操做。

Raft协议（略）： Raft协议是用来解决分布式系统一致性问题的协议。

选举流程：

1. 某哨兵认定主服务器客观下线后，若是已经投过票给其余哨兵，在必定时间内本身就不会成为领导者。

2. 若是该哨兵还没投过票，那么它就成为候选者（Candidate）。

3. 哨兵须要完成几件事情：

（1）更新故障转移状态为start。

（2）当前周期（Epoch）加1，也就是进入新一轮投票，向其余节点发送命令（is-master-down-by-addr）请求投票。命令会带上本身的周期（Epoch） 。

（3）给本身投一票，投票信息包括leader、leader_epoch。

4. 当其它哨兵收到此命令时，经过判断周期，能够赞成或者拒绝它成为领导者。由于只接收大于本身上一次周期的请求。

5. 候选者（Candidate）会不断的统计本身的票数，直到他发现认同他成为l领导者的票数超过一半并且超过它配置的规定数量（Quorum），这时它就成为了领导者。

6. 若是出现多个领导者，则等待一段时间从新选举。

7. 其余哨兵等待领导者选出主服务器后，检测到新的主服务器正常工做后，就会去掉客观下线的标识。

8. 若是原来下线的服务器恢复了，就只能先成为从服务器，做为下次故障转移的备份。

如图所示：

故障转移

选出的哨兵领导者会对下线的主服务器执行故障转移操做，主要有四个步骤：

1. 选出新的主服务器

   会将失效主服务器（Master）的其中一个从服务器（Slave） 升级为新的主服务器（Master）。

2. 关联新的主服务器

   让失效主服务器（Master）的其余从服务器（Slave）改成复制新的主服务器（Master）。

3. 配置自动更新

   主服务器（Master）和从服务器（Slave）切换后， 主服务器（Master）的redis.conf 、从服务器（Slave）的redis.conf 和sentinel.conf 的配置文件的内容都会发生相应的改变，即， 主服务器（Master）的redis.conf配置文件中会多一行replicaof 的配置， sentinel.conf 的监控目标会随之调换。

4. 集群会向客户端返回新的主服务器地址

   当客户端试图链接失效的主服务器（Master）时，集群也会向客户端返回新主服务器（Master）的地址，使得集群可使用如今的主服务器（Master）替换失效节点。

哨兵领导者根据如下规则从客观下线的主服务器的从服务器中选择出新的主服务器。

1. 过滤掉主观下线的节点

2. 选择优先级最高的节点

   选择slave-priority最高的节点，若是有则返回，没有就继续选择。

3. 选择复制数据最多的节点

   选择出复制偏移量最大的节点，由于复制偏移量越大则数据复制的越完整，若是有就返回了，没有就继续。

4. 选择最稳定的节点（run_id）

   选择run_id最小的节点，由于run_id越小说明重启次数越少。

定时任务

类比

通过上边这么多概念的回顾，终于到了最重要的举栗子阶段。

在线教育平台在每次上课的时候为了不直播事故（直播过程当中讲师离线，没法完成直播的状况）、评估课程（考核讲师）和维护课堂秩序（禁言聊天室）等，通常都会设置课程监察人员对在线课程进行实时监控。

因此咱们想象拉勾直播的场景，把他们分为两组：

• 哨兵集群：课监组，由监听提供服务的讲师状态的课程辅导人员组成。

  包括：课程顾问姐姐、美班班-小竹子、偷学讲师课程的导师-老可乐。

• 服务器集群：讲课组，由提供授课服务的讲师组成。

  包括：应颠老师、老猫老师、还有新来的见习老师。

咱们按照这个类比从新再认识下刚才讲的概念。

课监模式简介

• 课监是直播课程的一个比较简单的高可用解决方案，经过配合主副讲师模式实现。
• 课监是一个特殊的直播人员，不会进行课程讲解。
• 由多个课监人员组成集群，能够监视多个直播课程。
• 当主讲师进入离线状态时，课监能够将该主讲师下的某一副讲师升级为主讲师继续提供授课服务，从而保证直播课程的高可用。

下图为哨兵结构图：课监组+ 授课讲师组（Master主讲师 + Slave副讲师）。

监课流程

• 课监人员上线后，每一个人员会经过两种方式监控直播课程。
  • 沟通模式（命令连接）：用于向主讲师发送消息，沟通课程中的各类问题，并接收响应
  • 关注模式（订阅连接）：关注该直播课堂房间，能够观察到其余关注者（其余课监人员）
• 监课过程当中包含三个方面的处理：检测讲师下线状态、课监领导者选举、服务故障转移。

检测下线状态

分为主观下线状态和客观下线状态。

• 主观下线状态

课监人员实时（每秒）观察全部须要被监课的直播课堂，如下两种状况即为主观下线（SDown）：

直播状态错误

讲师离岗、授课内容不符

超时

无讲师影音信号，或者严重延迟

• 客观下线状态

当一个课监人员将一个主讲师判断为主观下线后会向同时监控这个主讲师的全部其余课监人员发送询问。 判断其余人是否也认为主讲师下线。若是达到课监要求中的规定数量（Quorum数量）的课监人员都判断主讲师为主观下线，则该主讲师就会被断定为客观下线（ODown）。

课监领导者选举

当一个主讲师被断定为客观下线后，监视这个主讲师的全部课监人员会经过选举算法（Raft），选出一个课监的领导者(Leader) 去执行故障转移操做。

Raft协议（略）： Raft协议是用来解决分布式系统一致性问题的协议。

选举流程：

这个选举流程你们本身对号入座地想象一下吧（主要是我懒得写了）。要是想问为何要选课监领导者呢？你能够理解成总要有人要处理直播事故，总要对处理的过程和结果负责。可是这也算工做业绩的一方面，因此你们并不拒绝，反而会争先取得领导者角色，争取升职加薪，一步一步地走上人生巅峰。而讲师组的人也是如此，也是要争上游。不然有一次不靠谱，就只能被其余人踩在脚下，充当备胎的角色。

故障转移

选出的课监领导者会对下线的主讲师执行故障转移操做，主要有四个步骤：

1. 选出新的主讲师

   会将失效主讲师（Master）的其中一个副讲师（Slave） 升级为新的主讲师（Master）。

2. 关注新的主讲师

   让失效主讲师（Master）的其余副讲师（Slave）改成关注新的主讲师（Master）。

   这里注意下复制这个概念。Redis中是为了各个节点之间数据同步，而授课讲师之间则是为了同步讲课内容，方便在替换上位的时候能够立刻接着前任的内容继续讲。

3. 配置自动更新

   主讲师（Master）和副讲师（Slave）切换后， 他们的通信录或者说是直播课堂的人员名单和岗位角色会随之变化。能够想象成是课监人员更新后发送给他们的。

4. 课监组会向听课学员的客户端返回新的主讲师地址

   当学员试图链接失效的主讲师（Master）时，课监组也会向学员返回新主讲师（Master）的地址。

   这里注意下地址这个概念。能够理解成每一个讲师都是在网上异地参加直播活动，若是主讲师失效，那么其余人要重开新的直播房间，直播课程地址也会随之改变。因此须要课监人员及时通知学员更换。

课监领导者根据如下规则从客观下线的主讲师的副讲师中选择出新的主讲师。

1. 过滤掉主观下线的讲师

2. 选择优先级最高的讲师

   选择排名最高的讲师，好比有经验的讲师和新来的实习讲师中优先选择有经验的，若是有则返回，没有就继续选择。

3. 选择关注直播内容最多的讲师

   选择出观看时间最长，观看内容最新的讲师，由于越新越多，再接着讲时花费在沟通上的时间越少。若是有就返回了，没有就继续。

4. 选择最稳定的节点

   选择以往出现直播事故次数最少的讲师，说明讲师本人和其环境越稳定。

三个定时任务

1. 沟通模式（命令连接，10秒1次）

   用于向主讲师发送消息，沟通课程中的各类问题，并接收响应

2. 关注模式（订阅连接，2秒1次）

   关注该直播课堂房间，能够观察到其余关注者（其余课监人员）

3. 监控模式（心跳连接，每秒1次）

   实时观看直播课程，进行讲师是否下线的判断。

总结

看完上边一坨一坨的概念是否是仍是有点乱？那咱再浓缩一下吧。

其实最根本的思路就是有一群监工随时监控着另外一群人，看看被监控的那群人的头儿有没有好好干活儿。要是没有就内部先商量出一个管事儿的监工，而后这个监工再从被管着的人群里选出一个替代那个很差好干活儿的人。

好了，若是你能熟记这个模型，而后再深刻学习下真正的概念，应该就离掌握不远了。

最后感谢几位客串出场的拉勾老师和工做人员。