Redis 哨兵搭建与原理详解

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

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

完整配置：

启动顺序：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）不同的哨兵节点之间通过数据的发布/订阅进行数据同步。

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

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：

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

哨兵监控master：

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