Redis哨兵原理，我忍你很久了！

系统管理员 2023-02-14 10:53 20阅读 0赞

> redis主从复制的作用中有这么一句话“主从复制是高可用的基石”，那什么是高可用呢！高可用就是减少系统不能提供的时间，也就是常听到的以6个9为基准。实现高可用必不可少的就是哨兵和集群。本文主要介绍哨兵机制。

# 本文主要围绕如下几个方面介绍哨兵 #

*  哨兵介绍
 *  哨兵配置
 *  哨兵工作原理

# 本文实现环境 #

*  centos7.3 redis4.0
 *  redis工作目录 /usr/local/redis
 *  在虚拟机进行模拟操作

### Redis哨兵搭建以及工作流程 ###

*  本文主要围绕如下几个方面介绍哨兵
 *  本文实现环境
 *  一、什么是哨兵
 *  二、哨兵的作用
 *  二、如何配置哨兵
 *   *  1. 准备工作
     *  2. sentinel.conf配置解读
     *  3. 开始配置
 *  三、哨兵工作原理
 *   *  1. 监控工作流程
     *  2. 通知工作流程
     *  3. 故障转移原理（本文重点）
 *  四、总结

# 一、什么是哨兵 #

先简单说几句我们在配置主从复制时有一种情况就是主节点宕机了，谁来提供服务呢！

当主节点宕机后主从复制就没有存在的意义了，数据为王的时代没有了数据何谈什么高可用。

![在这里插入图片描述][20200602180028604.png]  
这个时候就横空出世了一位老大哥名叫`哨兵`，老大哥说这个问题我来帮你们处理。

既然主节点master作为老大不领你们玩了。我就从你们四个中间再挑选出来一位老大，然后你们跟着他玩。

等不带你们玩的那个老大回来后他的身份就失效了，就不在是你们的老大了。他只能跟着我挑选出来的老大玩。

上边这段对话过程就是我们配置哨兵的意义到底在哪，跟谁玩就是谁给谁数据，知道了哨兵的作用我们就在继续。

**最后我们用专业术语来解释一下什么是哨兵。**

哨兵，英文名sentinel,是一个分布式系统，用于对主从结构中的每一台服务器进行`监控`，当主节点出现故障后通过投票机制来挑选新的主节点，并且将所有的从节点连接到新的主节点上。

# 二、哨兵的作用 #

上文中我们谈到的对话过程就是哨兵的作用之一自动故障转移。

谈到作用肯定就是这个哨兵到底在工作中到底干了什么事情。我们先用比较干巴的概念描述一下，然后在下文的工作原理会一一谈到。

哨兵的三个作用`监控、通知、自动转移故障`

*  监控
    
     *  监控谁？支持主从结构的工作一个是主节点一个是从节点，那肯定就是监控这俩个了。
     *  监控主节点和从节点是否正常运行
     *  检测主节点是否存活，主节点和从节点运行情况
 *  通知
    
     *  哨兵检测的服务器出现问题时，会向其他的哨兵发送通知，哨兵之间就相当于一个微信群，每个哨兵发现的问题都会发在这个群里。
 *  自动故障转移
    
     *  当检测到主节点宕机后，断开与宕机主节点连接的所有从节点，在从节点中选取一个作为主节点，然后将其他的从节点连接到这个最新主节点的上。并且告知客户端最新的服务器地址。

这里有一个注意点，哨兵也是一台redis服务器，只是不对外提供任何服务。

配置哨兵时配置为单数。那么为什么配置哨兵服务器的数量为单数呢？带着这个疑问你会在下文看到你想要的答案。

# 二、如何配置哨兵 #

## 1. 准备工作 ##

这一章我们就开始配置哨兵，前期工作准备。下图就是咔咔的准备工作。开启8个客户端，三个哨兵、一个主节点、俩个从节点、一个主节点客户端、一个从节点客户端。  
![在这里插入图片描述][2020060222590276.png]

## 2. sentinel.conf配置解读 ##

哨兵使用的配置文件是`sentinel.conf`  
![在这里插入图片描述][20200602230522970.png]  
我们来对sentinel.conf配置信息进行解读  
![在这里插入图片描述][2020060223073993.png]  
但是大多数都是注释，这里咔咔给大家提供一个命令来过滤这些无用信息 `cat sentinel.conf | grep -v '#' | grep -v '^$'`  
![在这里插入图片描述][20200602231227309.png]

*  port 26379 ：对外服务端口号
 *  dir /tmp：存储哨兵的工作信息
 *  sentinel monitor mymaster 127.0.0.1 6379 2：监控的是谁，名字可以自定义，后边的2代表的是，如果有俩个哨兵判断这个主节点挂了那这个主节点就挂了，通常设置为哨兵个数一半加一。
 *  sentinel down-after-milliseconds mymaster 30000：哨兵连接主节点多长时间没有响应就代表挂了。后边30000是毫秒，也就是30秒。
 *  sentinel parallel-syncs mymaster 1：这个配置项是指在故障转移时，最多有多少个从节点对新的主节点进行同步。这个值越小完成故障转移的时间就越长，这个值越大就意味着越 多的从节点因为同步数据而不可用。
 *  sentinel failover-timeout mymaster 180000：在进行同步的过程中，多长时间完成算有效，系统默认值是3分钟。

## 3. 开始配置 ##

使用命令`cat sentinel.conf | grep -v '#' | grep -v '^$' > ./data/sentinel-26379.conf`把sentinel.conf过滤后的信息移到`/usr/local/redis/conf`下  
![在这里插入图片描述][20200602233117692.png]  
然后打开`sentinel-26379.conf`修改信息存放目录  
![在这里插入图片描述][20200602233517201.png]  
然后快速的复制俩个哨兵配置文件，端口为26380和26381。`sed 's/26379/26381/g' sentinel-26379.conf > sentinel-26381.conf`

![在这里插入图片描述][20200602234003569.png]

测试主从复制处于正常工作状态，启动三台redis服务器，端口分别为`6379、6380、6381`  
![在这里插入图片描述][20200603105252496.png]  
查看主节点信息，是有俩台从节点在连接着，端口分别为6380、6381。

这里有一个小小的点就是lag怎么一个是1一个是0呢！lag是延迟时间，我这里是本地测试所以会出现0的情况，使用云服务器是很少出现的。lag的值为0和1都属于正常。  
![在这里插入图片描述][20200603110003769.png]  
测试主节点添加一个hash值，`hset kaka name kaka`  
![在这里插入图片描述][20200603110423511.png]  
分别从slave1和slave2获取kaka的值，检测主从复制是否正常运行。

经过测试我们的主从结构是正常运行的。  
![在这里插入图片描述][20200603110522257.png]  
![在这里插入图片描述][20200603110529796.png]  
启动一个哨兵`redis-sentinel 26379-sentinel.conf`  
![在这里插入图片描述][20200603111642473.png]  
连接26379哨兵，主要是最后一行，监控的主节点名为mymaster，状态正常，从节点有俩个，哨兵数量为1个  
![在这里插入图片描述][20200603111958293.png]  
在来查看一下26379的哨兵配置信息，这个时候已经改动了  
![在这里插入图片描述][2020060311224332.png]  
在启动一个`26380`的哨兵，`redis-sentinel 26380-sentinel.conf`,这里注意一下最后一行多了一条信息，这个id就是我们`26379`配置文件新增的id  
![在这里插入图片描述][20200603112541269.png]  
然后我们来到哨兵26379的客户端，同样也是新增的26380哨兵的id  
![在这里插入图片描述][20200603112742926.png]  
这个时候我们在查看一下26379哨兵的配置文件，第一次查看配置文件是没有配置26380哨兵的，第二次查看时配置了26380哨兵后添加的信息。  
![在这里插入图片描述][20200603112959232.png]  
最后我们需要把哨兵客户端3启动起来，端口号为26381。启动起来之后，我们的配置信息和服务端的信息也会改动，添加哨兵26380有的信息，哨兵26381也会有。

直到这里我们对哨兵的配置就结束了，接下来我们把主节点master给宕掉  
![在这里插入图片描述][20200603114952850.png]  
等待30秒后我们来到26379哨兵的客户端，这里新增了一些信息，那么这些信息都做了什么呢！让我们细细道来。

![在这里插入图片描述][2020060311525648.png]  
这里边的信息我们先需要知道几个

*  \+sdown ：这个信息后是指三个哨兵里边有一个认为主节点宕机了
 *  \+odown：这个信息是指其他俩个哨兵去连接了一下主节点，发现确实是主节点宕机了
 *  然后发起了一轮投票，这里咔咔使用的是redis4.0，版本之间这块信息有点差异
 *  \+switch-master mymaster 127.0.0.1 6379 127.0.0.1 6380：直到这里是哨兵发起投票的结果，推选端口为6380的redis为主节点
 *  \+slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380：这里就把端口为6381与6379和新的主节点6380做了一个连接
 *  \+sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380：最后一句是端口为6379的还是没有上线，于是给踢下线

当我们在重新把6379的redis服务器上线后，就可以看到哨兵服务端响应了俩句。一句是去除6379的下线。最后一句就是重连6379到新的主节点上。  
![在这里插入图片描述][20200603142249469.png]  
![在这里插入图片描述][20200603142314795.png]  
这个时候主节点就是6380了，在6380的redis客户端设置值，检测主从复制是否正常工作。

在新的主节点6380添加list类型  
![在这里插入图片描述][20200603142752160.png]  
在6379和6381获取这个值，至此呢！我们的哨兵模式就配置完成了。  
![在这里插入图片描述][20200603142847971.png]  
![在这里插入图片描述][20200603142903992.png]

# 三、哨兵工作原理 #

配置完哨兵后，就需要对其工作原理进行解析了，只有知道其工作流程，才能对哨兵有更好的理解。

本文讲解原理没有那么干巴！让你可以把一篇技术文章当故事去看。

进入正题，哨兵作用是监控、通知、故障转移。那么工作原理也是围绕这三点来讲的。

## 1. 监控工作流程 ##

![在这里插入图片描述][20200603153429516.png]

1.  哨兵发送info指令，并且保存所有哨兵状态，主节点和从节点的信息
2.  主节点会记录redis实例的信息，主节点记录的信息跟哨兵记录的信息看起来是一样的，实际上还是有点区别哈。
3.  哨兵会根据在主节点拿到的从节点信息，给对应的从节点也发送info指令
4.  接着哨兵2来了，同样的也会改主节点发送info指令，并且建立cmd连接
5.  这个时候哨兵2也会保存跟哨兵1一样的信息，只不过是保存的哨兵信息是2个。
6.  这个时候为了每个哨兵的信息都一致它们之间建立了一个发布订阅。为了哨兵之间的信息长期对称它们之间也会互发ping命令。
7.  当再来一个哨兵3时，也会做同样的事情，给主节点和从节点发送info。并且跟哨兵1和哨兵2建立连接。

## 2. 通知工作流程 ##

Sentinel会给主从的所有节点发送命令获取其状态，并且会把信息发布到哨兵的订阅里。  
![在这里插入图片描述][20200603160407526.png]

## 3. 故障转移原理（本文重点） ##

![在这里插入图片描述][20200603163500204.png]

*  哨兵会一直给主节点发送publish sentinel ：hello，直到哨兵报出sdown，这个词这会是有不是有点熟悉了。没错就是我们上文中把主节点断开后哨兵服务端报出的信息。哨兵报出主节点sdown后还没有完，哨兵还会往内网里发布消息说明这个主节点挂了。发送的指令是`sentinel is-master-down-by-address-port`
 *  其余的哨兵接收到指令后，主节点挂了吗？让我去看看到底挂没挂。发送的信息也是hello。其余的哨兵也会发送他们收到的信息并且发送指令`sentinel is-master-down-by-address-port`到自己的内网，确认一下第一个发送`sentinel is-master-down-by-address-port`的哨兵说你说的对，这个家伙确实挂了。当所有人都认为主节点挂了后就会修改其状态为`odown`。当一个哨兵认为主节点挂了标记的是`sdown`，当半数哨兵都认为挂了其标记的状态是`odown`。这也就是配置哨兵为什么配置单数的原因。
 *  对于一个哨兵认为主节点挂了称之为主观下线，半数哨兵认为主节点挂了称之为客官下线。
 *  一旦被认为主节点客官下线后，哨兵就会进行下一步操作

> 这时哨兵已经检测到问题所在了，那么到底是那个哨兵去负责推选新的主节点呢！不能是张三也去，李四也去，王五也去，这样就乱套了、于是就需要在所有的哨兵里选出领头的，那么是如何选的呢！请看下图。

这个时候呢！五个sentinel就在一起开会了，所有的哨兵都在一个内网中，然后他们会做一件事情就是五个sentinel会同时发送指令`sentinel is-master-down-by-address-port`并且携带上自己竞选次数和runid。  
![在这里插入图片描述][20200603164854686.png]  
每个sentinel既是参选者也是投票者，每个sentinel都有一票，信封就代表自己的投票权。  
![在这里插入图片描述][20200603165131230.png]  
当sentinel1和sentinel4同时把指令发送到群里准备竞选时，sentinel2这个时候就说我先接到谁的指令就把票投给谁。假如sentinel1发的早，那么sentinel2的票就会投给sentinel1。  
![在这里插入图片描述][20200603165912284.png]  
按照这样的规则一直发起投票直到有一个sentinel的票数为总sentinel数量的一半之多。假设说是sentinel1的票数满足总哨兵数量的一半之多后，sentinel1就会当选。这个时候就进行到了下一个阶段。  
![在这里插入图片描述][20200603170155706.png]  
在上边哨兵已经选出了sentinel1为代表去所有的从节点找出一个作为主节点。这个挑选主节点不是随便拿一个是有一定的规则的。

先把不在线的干掉

![在这里插入图片描述][20200603173148510.png]  
响应慢的干掉，sentinel会给所有的redis发送信息，响应速度慢的就会被干掉  
![在这里插入图片描述][20200603173408822.png]  
与原主节点断开时间最久的干掉，这里由于演示不够用了，所有新增了一个slave5，没有任何意义哈！  
![在这里插入图片描述][20200603173831345.png]  
以上三个点都判断结束后还有salve4和slave5，就会根据优先原则来进行筛选。

*  首先会根据优先级，如果优先级一样在进行其他判断
 *  判断offset偏移量，判断数据同步性，假如说slave4的offset为90 slave5偏移量为100 那么哨兵就会认为slave4的网络是不是有问题啊！于是就会选slave5为新的主节点。那如果说是slave4和slave5的offset相同呢！还有最后一个判断
 *  最后一步就是判断runid了，也就是职场中的论资排辈了，也就说根据runid的创建时间来判断，时间早的上位。

![在这里插入图片描述][20200603174710311.png]  
选出新的主节点后就要对所有的节点发送指令了。  
![在这里插入图片描述][2020060317550042.png]

# 四、总结 #

关于哨兵的所有知识点就已经说完了，本文最重要的就是哨兵的工作原理了。我们在简单的梳理一下其工作原理。

*  首先进行监控，并且所有的哨兵同步信息
 *  哨兵向订阅里边发布信息
 *  故障转移
    
     *  哨兵发现主节点下线
     *  哨兵开启投票竞选负责人
     *  由负责人推选新的主节点
     *  新的主节点断开原主节点，并且其他的从节点连接新的主节点，原主节点上线后作为从节点连接。

以上就是咔咔对哨兵的理解，如果错误可以提出，咔咔及时改正。

[20200602180028604.png]: https://img-blog.csdnimg.cn/20200602180028604.png
[2020060222590276.png]: https://img-blog.csdnimg.cn/2020060222590276.png
[20200602230522970.png]: https://img-blog.csdnimg.cn/20200602230522970.png
[2020060223073993.png]: https://img-blog.csdnimg.cn/2020060223073993.png
[20200602231227309.png]: https://img-blog.csdnimg.cn/20200602231227309.png
[20200602233117692.png]: https://img-blog.csdnimg.cn/20200602233117692.png
[20200602233517201.png]: https://img-blog.csdnimg.cn/20200602233517201.png
[20200602234003569.png]: https://img-blog.csdnimg.cn/20200602234003569.png
[20200603105252496.png]: https://img-blog.csdnimg.cn/20200603105252496.png
[20200603110003769.png]: https://img-blog.csdnimg.cn/20200603110003769.png
[20200603110423511.png]: https://img-blog.csdnimg.cn/20200603110423511.png
[20200603110522257.png]: https://img-blog.csdnimg.cn/20200603110522257.png
[20200603110529796.png]: https://img-blog.csdnimg.cn/20200603110529796.png
[20200603111642473.png]: https://img-blog.csdnimg.cn/20200603111642473.png
[20200603111958293.png]: https://img-blog.csdnimg.cn/20200603111958293.png
[2020060311224332.png]: https://img-blog.csdnimg.cn/2020060311224332.png
[20200603112541269.png]: https://img-blog.csdnimg.cn/20200603112541269.png
[20200603112742926.png]: https://img-blog.csdnimg.cn/20200603112742926.png
[20200603112959232.png]: https://img-blog.csdnimg.cn/20200603112959232.png
[20200603114952850.png]: https://img-blog.csdnimg.cn/20200603114952850.png
[2020060311525648.png]: https://img-blog.csdnimg.cn/2020060311525648.png
[20200603142249469.png]: https://img-blog.csdnimg.cn/20200603142249469.png
[20200603142314795.png]: https://img-blog.csdnimg.cn/20200603142314795.png
[20200603142752160.png]: https://img-blog.csdnimg.cn/20200603142752160.png
[20200603142847971.png]: https://img-blog.csdnimg.cn/20200603142847971.png
[20200603142903992.png]: https://img-blog.csdnimg.cn/20200603142903992.png
[20200603153429516.png]: https://img-blog.csdnimg.cn/20200603153429516.png
[20200603160407526.png]: https://img-blog.csdnimg.cn/20200603160407526.png
[20200603163500204.png]: https://img-blog.csdnimg.cn/20200603163500204.png
[20200603164854686.png]: https://img-blog.csdnimg.cn/20200603164854686.png
[20200603165131230.png]: https://img-blog.csdnimg.cn/20200603165131230.png
[20200603165912284.png]: https://img-blog.csdnimg.cn/20200603165912284.png
[20200603170155706.png]: https://img-blog.csdnimg.cn/20200603170155706.png
[20200603173148510.png]: https://img-blog.csdnimg.cn/20200603173148510.png
[20200603173408822.png]: https://img-blog.csdnimg.cn/20200603173408822.png
[20200603173831345.png]: https://img-blog.csdnimg.cn/20200603173831345.png
[20200603174710311.png]: https://img-blog.csdnimg.cn/20200603174710311.png
[2020060317550042.png]: https://img-blog.csdnimg.cn/2020060317550042.png