Redis 哨兵搭建与原理详解

末蓝、 2023-07-25 09:12 15阅读 0赞

# Redis 哨兵搭建与原理详解 #

咱们在上一节搭建了主从复制（[Redis 主从复制架构搭建与原理][Redis]）来提高redis整体的性能，基于主从复制的架构我们可以分析，如果是slave服务器出现宕机那么当前slave则不提供服务，对整个redis服务影响不大，但是当master节点宕机后，整个redis服务就会随之而然崩溃，我们希望在redis主从复制环境下如果master宕机后，有slave可以站出来顶替master的位置，不会对整个服务造成影响，从而提升我们redis服务的**高可用**。我们可以搭建redis哨兵来帮我们监控整个redis服务。

![\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zPBrNjzH-1586788981998)(media/43.png)\]][img-zPBrNjzH-1586788981998_media_43.png]

## 1.1 redis哨兵简介 ##

redis哨兵（Redis Sentinel）是独立一个分布式系统，用于提高redis主从复制环境下的高可用。哨兵可以监控master与slave的一些状态信息，并根据状态信息判断此服务器是否存活，如发现master不可用后，内部使用投票机制会在slave之间选举出一个较为适合的slave节点作为master节点，其他slave连接新的master节点继续提供服务，来保证整个redis的高可用。

## 1.2 搭建哨兵 ##

### 1.2.1 哨兵配置详解 ###

*  **配置master信息**

sentinel monitor <master-name> <ip> <port> <quorum>

*  master-name 为此master取个名字
 *  ip：master节点的ip
 *  port：master节点的端口
 *  quorum：票数，当master出现故障后，只要有quorum个哨兵（sentinel）认为此master出现故障那么就认为此master真的出现故障了（客观下线），重新推选新的master，一般设置为：哨兵数量/2+1。

示例：

sentinel monitor mymaster 127.0.0.1 6379 2

*  **设置哨兵等待心跳的响应时间**

sentinel down-after-milliseconds <master-name> <times>

*  master-name：指定master名称
 *  times：每台哨兵会定期发送心跳检查redis节点以及其他哨兵节点，如果times毫秒没有接收到回应，那么就主观认为这台redis机器出现故障（默认30s），单位毫秒

示例：

sentinel down-after-milliseconds mymaster 30000

*  **设置新master最多能同时处理几个slave的同步**

sentinel parallel-syncs <master-name> <nums>

*  master-name：指定master名称
 *  nums：当master宕机后，哨兵会发布投票来选举新的master，当新的master选举出来后，其他的slave需要连接新的master进行数据同步，nums代表最多有几台slave来同时同步数据，一般设置为1个，让slave一台一台慢慢同步，如果设置过大则会造成新master压力很大。默认是1台

示例：

sentinel parallel-syncs mymaster 1

*  **设置哨兵切换master节点时的超时时间**

sentinel failover-timeout <master-name>  <times>

*  master-name：master的名称
 *  times：设置切换master节点的最大超时时间，默认为3分钟，单位为毫秒。

示例：

sentinel failover-timeout mymaster 180000

*  **设置master连接密码**

sentinel auth-pass <master-name> <password>

*  master-name：master服务器名称
 *  password：master服务器的密码

示例：

sentinel auth-pass mymaster admin

*  出现故障时执行的脚本（一般测试时使用）

sentinel notification-script <name> <path>

*  是否允许执行sentinel set

sentinel deny-scripts-reconfig yes

### 1.2.1 搭建哨兵环境 ###

准备好3台redis（一主二从）、3台哨兵

哨兵完整配置文件：

port 26379				# 哨兵端口
    
    dir /tmp				# 数据存放位置(如:日志)
    
    sentinel monitor mymaster 127.0.0.1 6379 2	
    
    sentinel down-after-milliseconds mymaster 30000
    
    sentinel parallel-syncs mymaster 1
    
    sentinel failover-timeout mymaster 180000
    
    sentinel deny-scripts-reconfig yes

陆续配置26380、26381哨兵节点。（**其他哨兵配置文件全部保持一致，只是端口换了**）

6379.conf（主）：

bind 0.0.0.0
    port 6379
    #logfile "6379.log"
    dir "/root/redis-4.0.11/data"
    dbfilename "drum-6379.rdb"
    
    daemonize no
    appendonly yes
    appendfsync everysec
    appendfilename "appendonly-6379.aof"

6380.conf（从）：

bind 0.0.0.0
    port 6380
    #logfile "6380.log" 
    dir "/root/redis-4.0.11/data"
    dbfilename "drum-6380.rdb"
    
    daemonize no
    appendonly yes
    appendfsync everysec
    appendfilename "appendonly-6380.aof"
    slaveof 127.0.0.1 6379		# 连接master

6381.conf：

bind 0.0.0.0
    port 6381
    #logfile "6381.log"
    dir "/root/redis-4.0.11/data"
    dbfilename "drum-6381.rdb"
    
    daemonize no
    appendonly yes
    appendfsync everysec
    appendfilename "appendonly-6381.aof"
    slaveof 127.0.0.1 6379		# 连接master

完整配置：

![在这里插入图片描述][20200417084310675.png_pic_center]  
启动顺序：master—>slave—>哨兵

## 1.3 哨兵工作原理 ##

哨兵工作原理分为三个步骤：

1）当哨兵启动时需要监控master与slave的状态，并且保证哨兵集群能够正常通信。我们把这个阶段称为**哨兵监控阶段**

2）当哨兵发现master或者slave出现故障时，当前哨兵会通知其他哨兵，其他哨兵挨个发送ping命令来到出故障的redis节点，如果redis节点没有响应则哨兵集群认为此节点出现故障，我们把这个阶段称为**哨兵通知阶段**

3）当哨兵集群已经发现某个节点出现故障时，如果是slave节点则直接剔除，如果是master节点出现故障，那么需要在多个slave中推选出一个新的master节点，我们把这个阶段称为**故障转移阶段**

### 1.3.1 哨兵监控 ###

在哨兵监控阶段，主要完成三件事情：

1）监控master与slave的状态。

2）哨兵集群中保持正常的通信。

3）不同的哨兵节点之间通过数据的发布/订阅进行数据同步。

![\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LtLWVuJe-1586788981999)(media/44.png)\]][img-LtLWVuJe-1586788981999_media_44.png]

哨兵启动后会做如下事情：

1）info：哨兵启动每间隔10秒钟会向所有的master与slave节点发送info指令来获取信息，当有新的slave加入哨兵可以立马察觉到，获取到信息之后将信息保存到当前的哨兵节点中，同时也可以检测master与slave的状态。

2）ping：哨兵节点启动之后每隔1秒钟会向其他哨兵节点发送ping心跳，来检测其他哨兵节点是否正常。

3）pub/sub：每个哨兵节点每隔2秒钟会在一个指定的频道发布当前节点保存的master信息，其他哨兵节点都会订阅该频道获取消息。

### 1.3.2 哨兵通知 ###

哨兵通知阶段会每隔一秒ping一下master与slave，如果得不到响应则会认为当前redis节点出现故障，哨兵通知主要是监控到master或slave出现问题之后进行的处理。

哨兵监控slave：

![\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-F48ZUMF0-1586788981999)(media/45.png)\]][img-F48ZUMF0-1586788981999_media_45.png]

在哨兵集群中，如果有某一台哨兵节点发现某台slave节点出现故障后，那么则会在哨兵集群中发布消息，其他哨兵接收到消息之后，将此slave剔除。并将此节点标记为`sdown`，等到下次slave重新回复哨兵时，哨兵则会把此slave添加进主从复制，并将此节点标记为`-sdown`

哨兵监控master：

![\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YAZ8wBto-1586788981999)(media/46.png)\]][img-YAZ8wBto-1586788981999_media_46.png]

在哨兵集群中，如果有某一台哨兵节点发现某台Master节点出现故障后，当前哨兵节点会认为此master节点出现故障，此时当前哨兵标记此master节点为`+sdown`，当前哨兵标记master状态为**主观下线**（即：单个哨兵认为此master节点有问题，有可能是网络抖动问题。）如果后续其他哨兵节点也发现master出现故障（ping没有回应），直至数量大于等于哨兵配置文件中的quorum（票数）时，那么哨兵集群认为此master出现故障，标记为`odown状态`，此时master标记为**客观下线**。

### 1.3.3 故障转移 ###

#### 1.3.3.1 leader选举 ####

如果主节点被标记为客观下线之后，就要在哨兵集群中选出一个哨兵节点来完成后面的故障转移工作，每个哨兵节点都能成为这个领导者（leader），选举流程如下：

1）在master节点被标记为客观下线时，哨兵节点会向其他哨兵节点发送`is-master-down-by-addr`命令，表明自己想成为leader来处理master的故障转移。

2）当其它哨兵节点收到此命令时，可以同意或者拒绝它成为领导者；

3）当如果票数大于哨兵集群总数量的一半时将成为领导，如果没有大于，则继续开始下一轮选举（票数累加）。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0JiMTUwNzAwNDc3NDg_size_16_color_FFFFFF_t_70_pic_center]

#### 1.3.3.2 故障转移 ####

哨兵在哨兵监控时就已经保存了master与slave的信息，选举出leader哨兵之后，哨兵要开始进行master与slave的故障转移了。在众多的slave直接推选出一个slave充当master节点。

选举master流程如下：

1）首先过滤已经下线的slave节点

2）优先级高的推选为master节点，默认都为100（在 info Replication组，可查看优先级：slave\_priority参数）

3）推选出复制偏移量（offset）最大的节点（offset大，意味着和原master节点的数据最相近）

4）推选出run\_id最小的节点。

当故障转移后，需要更新当前的主从状态。

更新状态如下：

1）被选举出来的新master将执行`slaveof no one`，断开与原master的连接，并在其他slave的配置文件上加上`slaveof`命令。

2）将已经剔除的主节点设置为新主节点的从节点，后续恢复正常时，将其变为从节点，并在其配置文件中加上`slaveof`命令。

[Redis]: https://blog.csdn.net/Bb15070047748/article/details/105499756
[img-zPBrNjzH-1586788981998_media_43.png]: /images/20230528/3b7a7ad296d04f93849c6e817acd54e8.png
[20200417084310675.png_pic_center]: /images/20230528/1d9f39a53e3347e5885cb5960d680e09.png
[img-LtLWVuJe-1586788981999_media_44.png]: /images/20230528/a9b92943f9d24c89a0aedb32cb249c57.png
[img-F48ZUMF0-1586788981999_media_45.png]: /images/20230528/68aa187ce5f840bdbd05ef540fefd515.png
[img-YAZ8wBto-1586788981999_media_46.png]: /images/20230528/fd8935576dc547c090f034eed7680a06.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0JiMTUwNzAwNDc3NDg_size_16_color_FFFFFF_t_70_pic_center]: /images/20230528/84e69fd90444413f91347eacc9496ca3.png