Redis哨兵模式部署

概述

Redis Sentinel（哨兵或哨岗）为Redis提供了高可用解决方案。Sentinel实例可以监视任意多个主节点以及这些主节点属下的所有从节点，并在被监视的主节点进入下线状态时自动将下线主节点属下的从节点升级为新的主节点，然后由新的主节点替代已经下线的主节点并继续处理后续的命令请求。

这意味着使用Sentinel可以部署一套Redis，在没有人为干预的情况下去应付各种各样的失败事件。Redis Sentinel同时提供了一些其他的功能，比如监控、通知、为客户端提供配置等。

哨兵架构由两部分组成，哨兵节点和数据节点：

• 哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的Redis节点，不存储数据。

• 数据节点：主节点和从节点都是数据节点。

Sentinel有以下功能：

• 监控Monitoring：哨兵节点不断地检查用户的主从实例是否按照预期在工作。

• 通知Notification：如果被监控的Redis实例有问题，哨兵节点可以通过一个API来通知系统管理员或者其他应用程序。

• 自动故障转移Automatic Failover：如果一个主节点没有按照预期工作，哨兵节点会启动故障转移过程，把一个从节点提升为主节点，重新配置其他的从节点并使用新的主节点，使用Redis服务的应用程序在连接的时候也会被通知使用新的主节点地址。

• 配置提供者Configuration Provider：哨兵节点为客户端提供服务来源，对于指定的服务，客户端连接到Sentinel来寻找当前主节点的地址。当发生故障转移时，哨兵节点将报告新的主节点地址。

哨兵架构

哨兵节点最少三台并且必须为单数。这个与其他分布式框架（如Zookeeper）类似，如果是双数，在“选举”的时候就会出现平票的情况，所以必须是三台或三台以上的单数。

三个Sentinel实例应该放在独立的物理机电脑或虚拟机中，也就是在不同的物理机中或者在不同的可用区域上执行的虚拟机中。

Sentinel+Redis分布式系统在失败期间并不能确保写入请求被保存，因为Redis使用异步复制。有很多部署Sentinel的方式把写入限制在特定的时间窗口内，当然也有其他不安全的部署方式。

如果因为在开发环境或者生产环境中通过了测试而没有设置安全的高可用，那么就可能会因为一个错误的配置而导致主机宕机，以至不能继续提供正常的服务。

配置文件

Redis源码中包含一个名为sentinel.conf的文件，它是一个可以用来配置Sentinel的示例配置文件。一个典型的最小配置文件如下：

port 26379
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1

sentinel monitor

sentinel monitor配置项如下：

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

以上面的配置文件为例：Redis Sentinel监控一个名为mymaster的主节点，地址是127.0.0.1，端口号是6379，并且有两个仲裁机器。除了quorum参数，其他参数的意思都很明确：

• quorum是指同意主节点不可用所需的Sentinel的数量。

• quorum在检测到失败后投票时使用。为了执行故障转移，Sentinel实例中的一个需要被选定为领导者leader并且被授权进行操作，由大多数Sentinel实例进行投票。

如果有5个Sentinel实例，其中一个主节点quorum被设置为2，就会出现如下情况：

• 同时有两个Sentinel实例同意主节点不可用，其中的一个将会尝试开始故障转移。

• 如果至少有三个Sentinel实例同意主节点是可用的，那么故障转移就会被授权并开始执行。

在实际工作中，这意味着在失败时如果大多数的Sentinel实例没有同意，那么Sentinel永远不会开始故障转移。

其他Sentinel选项

其他的Sentinel选项基本都是以下格式：

sentinel <option-name> <master-name> <option-value>

以上面配置文件为例：

• down-after-milliseconds：当一个Redis实例失去联系（要么不回复我们的请求，要么回复一个错误）超过了这个指定的时间（以毫秒为单位），就可以认为这个Redis实例挂掉了。

• parallel-syncs：设置从节点的数量，这些从节点在一次故障转移过后可以使用新的主节点进行重新配置。数量越少，完成故障转移过程花费的时间越多。如果从节点为旧的数据提供服务，那么我们或许不想让所有的从节点都使用主节点进行重新同步。复制进程对于从节点来说大部分是非阻塞式的，不过还有一个时刻它会停下来去从主节点加载数据。可以通过将这个值设为1来保证每次只有一个从节点处于不能处理命令请求的状态。

部署

配置主从模式

本文主要为了演示，所以主从和哨兵服务都在同一台机器。推荐还是放在不同的物理机上，否则可能会因为错误的配置而导致服务宕机，从而无法继续提供正常的服务。

首先参照官网教程安装redis。

创建如下目录：

$ mkdir -p redis-master/conf redis-slave1/conf redis-slave2/conf

下载redis.conf至redis-master/conf 、redis-slave1/conf和redis-slave2/conf目录下

进入redis-maste目录，执行命令，启动master节点：

$ redis-server conf/redis.conf

slave节点配置文件加入如下配置：

# slave1 port改为6380，slave1 port改为6381
port 6380
replicaof 127.0.0.1 6379
# 如果主节点有密码
masterauth password

进入redis-slave1和redis-slave2目录，执行命令，启动slave节点：

$ redis-server conf/redis.conf

配置哨兵模式

创建如下目录：

$ mkdir -p redis-sentinel/conf

下载sentinel.conf至redis-sentinel/conf目录下，文件名分别为sentinel-26379.conf、sentinel-26380.conf、sentinel-26381.conf, 修改如下配置：

# pid文件对应26379~26381
pidfile "/var/run/redis/redis-sentinel-26379.pid"

sentinel monitor mymaster 127.0.0.1 6379 2

如果主节点设置了密码，还需加入如下配置：

sentinel auth-pass mymaster <password>

启动Sentinel服务：

$ redis-sentinel conf/sentinel-26379.conf
$ redis-sentinel conf/sentinel-26380.conf
$ redis-sentinel conf/sentinel-26381.conf

询问Sentinel关于主节点的状态

检查主节点的监控是否正常：

$ docker exec -it redis-sentinel-26379 /bin/bash
root@ef8018273b93:/data# redis-cli -p 26379
127.0.0.1:26379> SENTINEL master mymaster
 1) "name"
 2) "mymaster"
 3) "ip"
 4) "192.168.118.128"
 5) "port"
 6) "6379"
 ...
 35) "quorum"
 36) "2"
 37) "failover-timeout"
 38) "180000"
 39) "parallel-syncs"
 40) "1"
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_tilt_since_seconds:-1
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
# 出现如下信息，说明当前1主2从3哨兵，所有节点状态正常
master0:name=mymaster,status=ok,address=192.168.118.128:6379,slaves=2,sentinels=3

出现如上信息，说明监控主节点正常。

故障转移测试

直接杀死master服务，检查Sentinel的日志，可以看到：

26638:X 11 Dec 2024 16:37:15.456 * +sentinel-address-switch master mymaster 172.17.0.1 6379 ip 192.168.118.128 port 26381 for 924c83e89cb4f40c643bfd9029200bb3f9b71406
26638:X 11 Dec 2024 16:37:15.460 * Sentinel new configuration saved on disk
26638:X 11 Dec 2024 16:37:36.070 # +sdown slave 172.22.0.1:6379 172.22.0.1 6379 @ mymaster 172.17.0.1 6379
26638:X 11 Dec 2024 16:37:43.086 # +sdown master mymaster 172.17.0.1 6379
26638:X 11 Dec 2024 16:37:43.139 # +odown master mymaster 172.17.0.1 6379 #quorum 2/2
26638:X 11 Dec 2024 16:37:43.140 # +new-epoch 2
26638:X 11 Dec 2024 16:37:43.140 # +try-failover master mymaster 172.17.0.1 6379
26638:X 11 Dec 2024 16:37:43.142 * Sentinel new configuration saved on disk
26638:X 11 Dec 2024 16:37:43.142 # +vote-for-leader 77d629ca66128d00796c715bf5efb92c7205c856 2
26638:X 11 Dec 2024 16:37:43.146 * 9f09a3df829515f43e56acc183ef8614bf24993b voted for 77d629ca66128d00796c715bf5efb92c7205c856 2
26638:X 11 Dec 2024 16:37:43.147 * 924c83e89cb4f40c643bfd9029200bb3f9b71406 voted for 77d629ca66128d00796c715bf5efb92c7205c856 2
26638:X 11 Dec 2024 16:37:43.198 # +elected-leader master mymaster 172.17.0.1 6379
26638:X 11 Dec 2024 16:37:43.198 # +failover-state-select-slave master mymaster 172.17.0.1 6379
26638:X 11 Dec 2024 16:37:43.259 # +selected-slave slave 192.168.118.128:6380 192.168.118.128 6380 @ mymaster 172.17.0.1 6379
26638:X 11 Dec 2024 16:37:43.259 * +failover-state-send-slaveof-noone slave 192.168.118.128:6380 192.168.118.128 6380 @ mymaster 172.17.0.1 6379
26638:X 11 Dec 2024 16:37:43.343 * +failover-state-wait-promotion slave 192.168.118.128:6380 192.168.118.128 6380 @ mymaster 172.17.0.1 6379
26638:X 11 Dec 2024 16:37:43.353 * Sentinel new configuration saved on disk
26638:X 11 Dec 2024 16:37:43.353 # +promoted-slave slave 192.168.118.128:6380 192.168.118.128 6380 @ mymaster 172.17.0.1 6379
26638:X 11 Dec 2024 16:37:43.353 # +failover-state-reconf-slaves master mymaster 172.17.0.1 6379
26638:X 11 Dec 2024 16:37:43.397 * +slave-reconf-sent slave 192.168.118.128:6381 192.168.118.128 6381 @ mymaster 172.17.0.1 6379
26638:X 11 Dec 2024 16:37:44.310 # -odown master mymaster 172.17.0.1 6379
26638:X 11 Dec 2024 16:37:44.367 * +slave-reconf-inprog slave 192.168.118.128:6381 192.168.118.128 6381 @ mymaster 172.17.0.1 6379
26638:X 11 Dec 2024 16:37:44.367 * +slave-reconf-done slave 192.168.118.128:6381 192.168.118.128 6381 @ mymaster 172.17.0.1 6379
26638:X 11 Dec 2024 16:37:44.419 * +slave-reconf-sent slave 172.22.0.1:6379 172.22.0.1 6379 @ mymaster 172.17.0.1 6379
26638:X 11 Dec 2024 16:37:44.419 # +failover-end master mymaster 172.17.0.1 6379
26638:X 11 Dec 2024 16:37:44.419 # +switch-master mymaster 172.17.0.1 6379 192.168.118.128 6380
26638:X 11 Dec 2024 16:37:44.419 * +slave slave 192.168.118.128:6381 192.168.118.128 6381 @ mymaster 192.168.118.128 6380
26638:X 11 Dec 2024 16:37:44.419 * +slave slave 172.22.0.1:6379 172.22.0.1 6379 @ mymaster 192.168.118.128 6380
26638:X 11 Dec 2024 16:37:44.419 * +slave slave 172.17.0.1:6379 172.17.0.1 6379 @ mymaster 192.168.118.128 6380
26638:X 11 Dec 2024 16:37:44.421 * Sentinel new configuration saved on disk
26638:X 11 Dec 2024 16:38:14.483 # +sdown slave 172.17.0.1:6379 172.17.0.1 6379 @ mymaster 192.168.118.128 6380
26638:X 11 Dec 2024 16:38:14.483 # +sdown slave 172.22.0.1:6379 172.22.0.1 6379 @ mymaster 192.168.118.128 6380

• 每个Sentinel发现主节点挂掉了并有一个+sdown事件。

• +sdown事件稍候升级到+odown，意味着大多数Sentinel同意了主节点是不可达的，即不可用了。

• 各个Sentinel投票选举出一个Sentinel节点并让它尝试故障转移。

• 开始故障转移。如果重新询问mymaster当前主节点的地址，那么我们会得到一个不同的回复：

127.0.0.1:26379> sentinel master mymaster
 1) "name"
 2) "mymaster"
 3) "ip"
 4) "192.168.118.128"
 5) "port"
 6) "6380"
 7) "runid"
 8) "b3a7596afc1cd2825423d0f43e45138f7457de6c"
 ...