Redis哨兵机制-你不得不了解的知识点

末蓝、 2023-07-06 06:30 12阅读 0赞

## 内容概要 ##

*  理解Redis哨兵原理
 *  能够配置Redis哨兵

## 一、Redis哨兵 ##

**Redis 主从复制的缺点**：没有办法对 master 进行动态选举（master宕机后，需要重新选举master），需要使用 Sentinel 机制完成动态选举。

### 什么是Redis哨兵机制？ ###

> 哨兵(sentinel) 是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel) 进程,这些进程使用流言协议(gossipprotocols)来接收关于Master是否下线的信息,并使用投票协议(agreement protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master **(raft算法)** 。

Redis 的哨兵模式到了 2.8 版本之后才有的。  
Sentinel (哨兵)进程是用于 **监控 Redis 集群中 Master主服务器工作的状态**；  
在 Master 主服务器发生故障的时候，可以实现 Master 和 Slave 服务器的切换，保证系统的高可用（ HA ）；

**Redis的哨兵(sentinel) 系统用于管理多个 Redis 服务器,该系统执行以下三个任务:**

*  **监控( Monitoring )** : 哨兵( sentinel ) 会不断地检查你的 Master 和 Slave 是否运作正常。
 *  **提醒( Notification )** ：当被监控的某个 Redis 节点出现问题时, 哨兵( sentinel ) 可以通过 API 向管理员或者其他应用程序发送通知。
 *  **自动故障迁移( Automatic failover )** ：当一个 Master 不能正常工作时，**哨兵( sentinel )** 会开始一次**自动故障迁移**操作。

每个哨兵(sentinel) 会向其它哨兵(sentinel)、master、slave 定时发送消息,以确认对方是否“活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(所谓的"**主观认为宕机**" Subjective Down,简称sdown).  
若“哨兵群”中的多数sentinel,都报告某一master没响应,系统才认为该master"**彻底死亡**"(即:客观上的真正down机,Objective Down,简称odown),通过一定的vote算法(raft算法),从剩下的slave节点中,选一台提升为master,然后自动修改相关配置。

虽然哨兵(sentinel) 释出为一个单独的可执行文件 redis-sentinel ,但实际上它只是一个运行在特殊模式下的 Redis 服务器，你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动哨兵(sentinel)。

哨兵(sentinel) 的一些设计思路和zookeeper非常类似。

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

### 哨兵模式配置 ###

实现步骤:

1.  **拷贝到etc目录**  
    `cp sentinel.conf /usr/local/redis/etc`
2.  **修改sentinel.conf配置文件**

# 哨兵sentinel监控的redis主节点的 ip port
    # master-name 可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。
    # quorum 当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点失联了
    # sentinel monitor <master-name> <master ip> <master port> <quorum>
    sentinel monitor mymaster 192.168.137.6 6379 1
    #后台运行
    daemonize yes

1.  **其它配置项说明**
    
    `sentinel.conf`

# 哨兵sentinel实例运行的端口 默认26379
    port 26379
    # 哨兵sentinel的工作目录
    dir /tmp
    # 哨兵sentinel监控的redis主节点的 ip port
    # master-name 可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。
    # quorum 当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点失联了
    # sentinel monitor <master-name> <ip> <redis-port> <quorum>
    sentinel monitor mymaster 127.0.0.1 6379 1
    # 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供密码
    # 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码,无密码可忽略此配置
    # sentinel auth-pass <master-name> <password>
    sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
    # 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时，哨兵主观上认为主节点下线 默认30秒
    # sentinel down-after-milliseconds <master-name> <milliseconds>
    sentinel down-after-milliseconds mymaster 30000
    # 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步，这个数字越小，完成failover所需的时间就越长，但是如果这个数字越大，就意味着越 多的slave因为replication而不可用。可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
    # sentinel parallel-syncs <master-name> <numslaves>
    sentinel parallel-syncs mymaster 1
    # 故障转移的超时时间 failover-timeout 可以用在以下这些方面：
    #1. 同一个sentinel对同一个master两次failover之间的间隔时间。
    #2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
    #3.当想要取消一个正在进行的failover所需要的时间。
    #4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了
    # 默认三分钟
    # sentinel failover-timeout <master-name> <milliseconds>
    sentinel failover-timeout mymaster 180000
    # SCRIPTS EXECUTION
    #配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员。
    #对于脚本的运行结果有以下规则：
    #若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10
    #若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。
    #如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。
    #一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。
    #通知型脚本:当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等），将会去调用这个脚本，这时这个脚本应该通过邮件，SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时，将传给脚本两个参数，一个是事件的类型，一个是事件的描述。
    #如果sentinel.conf配置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentinel无法正常启动成功。
    #通知脚本
    # sentinel notification-script <master-name> <script-path>
    sentinel notification-script mymaster /var/redis/notify.sh
    # 客户端重新配置主节点参数脚本
    # 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息。
    # 以下参数将会在调用脚本时传给脚本:
    # <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
    # 目前<state>总是“failover”,
    # <role>是“leader”或者“observer”中的一个。
    # 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的
    # 这个脚本应该是通用的，能被多次调用，不是针对性的。
    # sentinel client-reconfig-script <master-name> <script-path>
    sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

1.  **通过 redis-sentinel 启动哨兵服务**
    
    `./redis-sentinel sentinel.conf`

**注意：**

1.  当启动哨兵模式之后，如果你的master服务器宕机之后，哨兵自动会在从redis服务器里面 投票选举一个master主服务器出来；这个主服务器也可以进行读写操作！
2.  如果之前宕机的主服务器已经修好，可以正式运行了。那么这个服务器只能进行读的操作，会自动跟随由哨兵选举出来的新服务器！
3.  大家可以进入./redis-cli，输入`info replication`，查看你的状态信息；

![20200217005240956.png][]

### 哨兵Sentinel总结 ###

#### 1. Sentinel的作用 ####

1.  Master 状态监测
2.  如果Master 异常，则会进行Master-slave 转换，将其中一个Slave作为Master，将之前的Master作为Slave
3.  Master-Slave切换后，master\_redis.conf、slave\_redis.conf和sentinel.conf的内容都会发生改变，即master\_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换

#### 2. Sentinel的工作方式: ####

1.  每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令。
2.  如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 `down-after-milliseconds` 选项所指定的值， 则这个实例会被 Sentinel 标记为 **主观下线**。
3.  如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。
4.  当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为 **客观下线**。
5.  在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令 。
6.  当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次 。
7.  若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。 若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。

--------------------

#### 心跳检测 ####

在命令传播阶段，从服务器默认以每秒一次的频率，向主服务器发送命令：

`REPLCONF ACK <replication_offset>` //replication\_offset是从服务器当前的复制偏移量。

**心跳检测的作用:**

*  检测主服务器的网络连接状态；
 *  辅助实现min-slaves选项；
 *  检测命令丢失。

1.  检测主从服务器的网络连接状态

通过向主服务器发送 `INFO replication` 命令，可以列出从服务器列表，可以看出从最后一次向主发送命令距离现在过了多少秒。

localhost:6377> info replication
    # Replication
    role:master
    connected_slaves:2
    slave0:ip=127.0.0.1,port=6379,state=online,offset=110180,lag=0 # 刚刚发送过REPLCONF ACK 命令
    slave1:ip=127.0.0.1,port=6378,state=online,offset=110180,lag=1 # 1秒之前发送过REPLCONF ACK 命令
    master_replid:55c2177dd69fc21dbea4e9f8a3f4fb0ee948855d
    master_replid2:a80967516d1b0821c315fd2eb550f2ff0597010c
    master_repl_offset:110313
    second_repl_offset:25348
    repl_backlog_active:1
    repl_backlog_size:1048576
    repl_backlog_first_byte_offset:11612
    repl_backlog_histlen:98702

lag的值应该在0或1之间跳动，如果超过1则说明主从之间的连接有故障。

1.  辅助实现min-slaves选项

Redis可以通过配置防止主服务器在不安全的情况下执行写命令；

min-slaves-to-write 3
    min-slaves-max-lag 10

上面的配置表示：从服务器的数量少于3个，或者三个从服务器的延迟（lag）值都大于或等于10秒时，主服务器将拒绝执行写命令。这里的延迟值就是上面 INFO replication 命令的lag值。

1.  检测命令丢失

如果因为网络故障，主服务器传播给从服务器的写命令在半路丢失，那么当从服务器向主服务器发送 `REPLCONF ACK <replication_offset>` 命令时，主服务器将发觉从服务器当前的复制偏移量少于自己的复制偏移量，然后主服务器就会根据从服务器提交的复制偏移量，在复制积压缓冲区里面找到从服务器缺少的数据，并将这些数据重新发送给从服务器。

主服务器向从服务器补发缺失数据这一操作的原理和 **部分重同步操作** 的原理非常相似，它们的区别在于：补发缺失数据操作在主从服务器没有断线的情况下执行，而部分重同步操作则在主从服务器断线并重连之后执行。

如果对于 **部分重同步操作** 不了解的同学，可以参考笔者写的 [Redis-主从复制原理][Redis-] 这篇文章。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RhdXJ1c183Yw_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200217003957994.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RhdXJ1c183Yw==,size_16,color_FFFFFF,t_70
[20200217005240956.png]: https://img-blog.csdnimg.cn/20200217005240956.png
[Redis-]: https://blog.csdn.net/taurus_7c/article/details/104034580