Redis Sentinel哨兵模式

精选原创

Anabelle 2023-03-23 15:46:36 ©著作权

©著作权归作者所有：来自51CTO博客作者Anabelle的原创作品，请联系作者获取转载授权，否则将追究法律责任

一、Sentinel哨兵

在 Redis 主从复制模式中，因为系统本身不具备自动恢复的功能，所以当主服务器（master）宕机后，需要手动把一台从服务器（slave）切换为主服务器。在这个过程中，不仅需要人为干预，而且还会造成一段时间内服务器处于不可用状态，同时数据安全性也得不到保障，因此主从模式的可用性较低，不适用于线上生产环境。
从而Redis Sentinel 哨兵模式就应用而生了，它弥补了主从模式的不足。Sentinel 通过监控的方式获取主机的工作状态是否正常，当主机发生故障时， Sentinel 会自动进行 Failover（即故障转移），并将其监控的从机提升主服务器（master），从而保证了系统的高可用性。

参考官网：https://redis.io/docs/manual/sentinel/

二、Sentinel哨兵能做什么？

官方对于sentinel哨兵作用说明：

主从监控：监控主从redis库运行是否正常
消息通知：哨兵可以将故障转移的结果发送给客户端
故障转移：如果Master异常，则会进行主从切换，将其中一个Slave作为新Master
配置中心：客户端通过连接哨兵来获得当前Redis服务的主节点地址

三、Redis Sentinel架构

在实际生产情况中，Redis Sentinel 是集群的高可用的保障，为避免 Sentinel 发生意外，它一般是由 3～5 （至少三个）个节点组成，这样假如个别节点宕机，整个集群仍然可以正常运转。其结构图如下所示：

Redis Sentinel哨兵模式_redis

上述配置说明：

3个哨兵：会自动监控和维护集群，不会存放数据，只是作为监控
一台master主机，两台slave从机，最基本的主从复制，还是基于上一节的环境，用于数据读取和存放

哨兵主要有两个重要作用：

第一：哨兵节点会每隔一段时间对每个 Redis 节点发送PING命令，并通过 Redis 节点的回复来判断其运行状态。
第二：当哨兵监测到主服务器发生故障时，会自动在从节点中选择一台将机器，并其提升为主服务器，然后使用 PubSub 发布订阅模式，通知其他的从节点，修改配置文件，跟随新的主服务器。

上图中多个哨兵之间也存在互相监控，这就形成了哨兵集群，现在对该模式的工作过程进行讲解，介绍如下：

1) 主观下线

主观下线，适用于主服务器和从服务器。如果在规定的时间内(配置参数：down-after-milliseconds)，Sentinel 节点没有收到目标服务器的有效回复，则判定该服务器为“主观下线”。比如 Sentinel1 向主服务发送了PING命令，在规定时间内没收到主服务器PONG回复，则 Sentinel1 判定主服务器为“主观下线”。

2) 客观下线

客观下线，只适用于主服务器。 Sentinel1 发现主服务器出现了故障，它会通过相应的命令，询问其它 Sentinel 节点对主服务器的状态判断。如果超过半数以上的 Sentinel 节点认为主服务器 down 掉，则 Sentinel1 节点判定主服务为“客观下线”。

3) 投票选举

投票选举，所有 Sentinel 节点会通过投票机制，选举出某个哨兵作为为领头节点去做 Failover（故障转移）操作。被选出的哨兵节点则按照一定的规则在所有从节点中选择一个最优的作为主服务器，然后通过发布订功能通知其余的从节点（slave）更改配置文件，跟随新上任的主服务器（master）。至此就完成了主从切换的操作。

对上流程总结如下：
Sentinel 负责监控主从节点的“健康”状态。当主节点挂掉时，自动选择一个最优的从节点切换为主节点。客户端来连接 Redis 集群时，会首先连接 Sentinel，通过 Sentinel 来查询主节点的地址，然后再去连接主节点进行数据交互。当主节点发生故障时，客户端会重新向 Sentinel 要地址，Sentinel 会将最新的主节点地址告诉客户端。因此应用程序无需重启即可自动完成主从节点切换。

四、案例演示

这里案例遵循第三章节的架构图来进行，主从复制的redis集群还是上一个章节的环境，生产环境上三个哨兵应该是放在三台服务器构建的集群，但是由于电脑内存不足，故而将三个哨兵集群部署到了6397这个redis机器上了。

4.1.在redis解压后/opt目录下默认的sentinel.conf文件重点参数项说明

文件名sentinel.conf如下图所示：

Redis Sentinel哨兵模式_客户端_02

sentinel.conf 文件配置内容如下：

常用参数：

参数	含义
bind	服务监听地址，用于客户端连接，默认本机地址
daemonize	是否以后台daemon方式运行
protected-mode	安全保护模式
port	端口
logfile	日志文件路径
pidfile	pid文件路径
dir	工作目录
sentinel monitor <master-name> <ip> <redis-port> <quorum>	设置要监控的master服务器； quorum表示最少有几个哨兵认可客观下线，同意故障迁移的法定票数。
sentinel auth-pass <master-name> <password>	master设置了密码，连接master服务的密码

其他参数，可以暂时不配置，默认即可：

sentinel down-after-milliseconds <master-name> <milliseconds>：	指定多少毫秒之后，主节点没有应答哨兵，此时哨兵主观上认为主节点下线
sentinel parallel-syncs <master-name> <nums>	表示允许并行同步的slave个数，当Master挂了后，哨兵会选出新的Master，此时，剩余的slave会向新的master发起同步数据
sentinel failover-timeout <master-name> <milliseconds>	故障转移的超时时间，进行故障转移时，如果超过设置的毫秒，表示故障转移失败
sentinel notification-script <master-name> <script-path>	配置当某一事件发生时所需要执行的脚本
sentinel client-reconfig-script <master-name> <script-path>	客户端重新配置主节点参数脚本

4.2.本次案例演示哨兵sentinel文件通用配置

由于机器硬件关系，我们的3个哨兵都同时配置进入到6379同一台机器中去，

在6379机器的/myredis目录下创建：sentinel26379.conf，内容如下：

bind 0.0.0.0
daemonize yes
protected-mode no
port 26379
logfile "/myredis/sentinel26379.log"
pidfile /var/run/redis-sentinel26379.pid
dir /myredis
sentinel monitor mymaster 192.168.42.132 6379 2
sentinel auth-pass mymaster 123456

在6379机器的/myredis目录下创建：sentinel26380.conf，内容如下：

bind 0.0.0.0
daemonize yes
protected-mode no
port 26380
logfile "/myredis/sentinel26380.log"
pidfile /var/run/redis-sentinel26380.pid
dir "/myredis"
sentinel monitor mymaster 192.168.42.132 6379 2
sentinel auth-pass mymaster 123456

在6379机器的/myredis目录下创建：sentinel26381.conf，内容如下：

bind 0.0.0.0
daemonize yes
protected-mode no
port 26381
logfile "/myredis/sentinel26381.log"
pidfile /var/run/redis-sentinel26381.pid
dir "/myredis"
sentinel monitor mymaster 192.168.42.132 6379 2
sentinel auth-pass mymaster 123456

参考如下图：

Redis Sentinel哨兵模式_服务器_03

4.3.先启动一主二从3个redis实例，测试正常的主从复制

这里需要对master主机6379后续可能会变成从机，需要设置访问新主机的密码，请设置masterauth项访问密码为123456，不然后续可能报错master_link_status:down，如下图：

Redis Sentinel哨兵模式_客户端_04

启动三部真实机器实例并连接，注意防火墙，三台机器使用的端口一定要允许访问，切记，这里需要互相连接，并且能够实现主从复制才可以。

4.4.启动3个哨兵，完成监控

哨兵的启动有两种方式，任选其一即可，如下图：

Redis Sentinel哨兵模式_redis_05

本次案例，启动三台哨兵的命令如下：

redis-sentinel sentinel26379.conf --sentinel
redis-sentinel sentinel26380.conf --sentinel
redis-sentinel sentinel26381.conf --sentinel

4.5.启动3个哨兵监控后再测试一次主从复制

这里一定要确定没有问题才可以：查看master6379

Redis Sentinel哨兵模式_服务器_06

查看slave 6380

Redis Sentinel哨兵模式_redis_07

查看slave 6381

Redis Sentinel哨兵模式_redis_08

4.6.测试在6379master主机宕机后的哨兵模式的处理能力

1.手动关闭6379主机，模拟master宕机，如下图：

Redis Sentinel哨兵模式_服务器_09

2.先查看两台从机数据读取是否正常，会发现刚开始查看数据的时候，会报错：

查看6380

Redis Sentinel哨兵模式_客户端_10

查看6381

Redis Sentinel哨兵模式_服务器_11

等会再次分别查看6380、6381数据已经恢复

Redis Sentinel哨兵模式_客户端_12

Redis Sentinel哨兵模式_服务器_13

遇到两个问题

Error：Server closed the connection：这个是因为当原来的master断开后，sentientl哨兵需要隔一段时间ping不同的时候，才会进行投票选出新的master，这个需要一定的时间
Error：Broken pipe : 其实当该异常产生的时候，对于服务端来说，并没有多少影响。因为可能是某个客户端突然中止了进程导致了该错误，这个异常是客户端读取超时关闭了连接,这时候服务器端再向客户端已经断开的连接写数据时就发生了broken pipe异常！（不一定会出现）

3.会从剩下的2台机器上选出新的master

查看这里6380变成新的master

Redis Sentinel哨兵模式_客户端_14

查看这里6381依然是salve

Redis Sentinel哨兵模式_客户端_15

这里涉及到了投票新选的机制，查看6380的sentinel日志如下：

Redis Sentinel哨兵模式_redis_16

查看6381的sentinel日志如下：

Redis Sentinel哨兵模式_客户端_17

查看6379的sentinel日志如下：

Redis Sentinel哨兵模式_客户端_18

4.之前down机的master主机6379重启回来，这时候谁将会是新master？会不会双master冲突

不会冲突，当6379重启连接后，6379从master降级变成了slave，6380依然是master，但是6381还是slave，只不过换了个新老大6380(从6379变为了6380)

查看新启动的6379，如下图：

Redis Sentinel哨兵模式_redis_19

4.7.对比配置文件前后的变化

由于在4.6章节，进行了master的自动切换，redis的配置文件的内容，在运行期间会被sentinel动态进行更改，Master-Slave切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换。

查看sentinel26379.conf，发现配置信息中监控信息由192.168.42.132变为了192.168.42.134也就是新的master主机的ip

Redis Sentinel哨兵模式_redis_20

查看老的master 6379的配置文件如下：

Redis Sentinel哨兵模式_客户端_21

查看新上位的master 6380的配置文件如下：

Redis Sentinel哨兵模式_客户端_22

4.8.其他说明

在生产环境都是不同机房的不同服务器，很少出现3个哨兵全挂掉的情况，但是需要保持几台配置哨兵的服务器的软硬件配置保持一致，其次哨兵可以同时监控多个master，一行一个

五、哨兵模式运行流程和选举原理

当一个主从配置中的master宕机失效之后，sentinel可以选举出一个新的master用于自动接替原master的工作，主从配置中的其他redis服务器自动指向新的master同步数据。一般建议sentinel采取奇数台，防止某一台sentinel无法连接到master导致误切换。下面说明哨兵模式的运行流程和故障切换的原理：

5.1.三个哨兵监控一主二从，正常运行中

这里主要是上述的环境，主从复制正常，能成功的设置哨兵监控即可。

5.2.SDown主观下线(Subjectively Down)

SDOWN(主观不可用)是单个sentinel自己主观上检测到的关于master的状态，从sentinel的角度来看，如果发送了PING心跳后，在一定时间内（默认30s）没有收到合法的回复，就达到了SDOWN的条件。需要注意的是sentinel在配置文件中的down-after-milliseconds设置了判断主观下线的时间长度，如下图：

Redis Sentinel哨兵模式_redis_23

所谓主观下线（Subjectively Down，简称 SDOWN）指的是单个Sentinel实例对服务器做出的下线判断，即单个sentinel认为某个服务下线（有可能是接收不到订阅，之间的网络不通等等原因）。主观下线就是说如果服务器在[sentinel down-after-milliseconds]给定的毫秒数之内没有回应PING命令或者返回一个错误消息，那么这个Sentinel会主观的(单方面的)认为这个master不可以用了。

sentinel down-after-milliseconds <masterName> <timeout>

表示master被当前sentinel实例认定为失效的间隔时间，这个配置其实就是进行主观下线的一个依据，master在多长时间内一直没有给Sentine返回有效信息，则认定该master主观下线。也就是说如果多久没联系上redis-servevr，认为这个redis-server进入到失效（SDOWN）状态。

5.3.ODown客观下线(Objectively Down)

ODOWN需要一定数量的sentinel，多个哨兵达成一致意见才能认为一个master客观上的确是已经宕掉，在sentinel.conf配置文件中，如下：

Redis Sentinel哨兵模式_服务器_24

四个参数含义：

masterName：是对某个master+slave组合的一个区分标识(一套sentinel可以监听多组master+slave这样的组合)
ip：ip地址
port：端口
quorum：该参数是进行客观下线的一个依据，法定人数/法定票数，含义是至少有quorum个sentinel认为这个master有故障才会对这个master进行下线以及故障转移。因为有的时候，某个sentinel节点可能因为自身网络原因导致无法连接master，而此时master并没有出现故障，所以这就需要多个sentinel都一致认为该master有问题，才可以进行下一步操作，这就保证了公平性和高可用。