Redis主动哨兵模式搭建

本文遵循BY-SA版权协议，转载请附上原文出处链接。

本文作者: 黑伴白

本文链接: http://heibanbai.com.cn/posts/2f139ea1/

在 Redis 主从复制模式中，因为系统不具备自动恢复的功能，所以当主服务器（master）宕机后，需要手动把一台从服务器（slave）切换为主服务器。在这个过程中，不仅需要人为干预，而且还会造成一段时间内服务器处于不可用状态，同时数据安全性也得不到保障，因此主从模式的可用性较低，不适用于线上生产环境。

Redis 官方推荐一种高可用方案，也就是 Redis Sentinel 哨兵模式，它弥补了主从模式的不足。Sentinel 通过监控的方式获取主机的工作状态是否正常，当主机发生故障时， Sentinel 会自动进行 Failover（即故障转移），并将其监控的从机提升主服务器（master），从而保证了系统的高可用性。

Redis哨兵模式原理

哨兵是Redis的一种运行模式，它专注于对Redis实例（主节点、从节点）运行状态的监控，并能够在主节点发生故障时通过一系列的机制实现选主及主从切换，实现故障转移，确保整个Redis系统的可用性。Redis哨兵具备的能力有如下几个：

• 监控（Monitoring）：持续监控Redis主节点、从节点是否处于预期的工作状态。
• 通知（Notification）：哨兵可以把Redis实例的运行故障信息通过API通知监控系统或者其他应用程序。
• 自动故障恢复（Automatic failover）：当主节点运行故障时，哨兵会启动自动故障恢复流程：某个从节点会升级为主节点，其他从节点会使用新的主节点进行主从复制，通知客户端使用新的主节点进行。
• 配置中心（Configuration provider）：哨兵可以作为客户端服务发现的授权源，客户端连接到哨兵请求给定服务的Redis主节点地址。如果发生故障转移，哨兵会通知新的地址。这里要注意：哨兵并不是Redis代理，只是为客户端提供了Redis主从节点的地址信息。

哨兵模式是天然的分布式系统，它被设计为基于一套配置，并在多个哨兵实例的配合下工作。多实例共同协作有以下优势：

• 主节点的系统故障是在多个实例共同认可的情况下完成的，大大降低了误报的概率。
• 即使不是所有的哨兵实例都正常运行哨兵集群也能正常工作，这大大增加了系统的健壮性。

使用 Sentinel 搭建 Redis 集群，基本结构图如下所示：

在上图过程中，哨兵主要有两个重要作用：

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

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

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

1. 主观下线

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

2. 客观下线

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

3. 投票选举

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

对上对述过程做简单总结：

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

Redis主从哨兵规划

本文安装使用3台服务器，共1主2从3哨兵，涉及服务器的复用

IP	角色1	端口1	角色2	端口2	角色3	端口3
199.188.166.111	Redis Master	6379			Sentinel	26379
199.188.166.112			Redis Slave	6379	Sentinel	26379
199.188.166.113			Redis Slave	6379	Sentinel	26379

Redis主从哨兵安装与配置

Redis下载

直接从官方网站下载即可：Download | Redis

示例版本

redis-7.0.4.tar.gz

安装步骤

解压

cd /home/redis
tar -zxvf redis-7.0.4.tar.gz

编译

cd /home/redis/redis-7.0.4/
make

安装

make install PREFIX=/app/redis # 指定路径为/app/redis，安装后将在/app/redis目录下生成一个bin目录，下面有相关文件

在/app/redis下创建etc目录存放配置文件，方便后续管理维护

mkdir /app/redis/etc
cp /home/redis/redis-7.0.4/redis.conf /app/redis/etc/

主从配置

# Redis 默认只允许本机访问，把 bind 修改为 0.0.0.0 表示允许所有远程访问。如果想指定限制访问，可设置对应的 ip
bind 0.0.0.0
# 监听端口默认为6379，可修改为其他端口号
port 6379
# 关闭保护模式，可以外部访问
protected-mode no
# 开启守护进程
daemonize yes
# 指定数据存放目录
dir /app/redis/data
# 指定日志文件
logfile /app/redis/logs/redis.log
# 设置 redis 连接密码 也可通过命令设置密码
requirepass 123456
# slave 服务连接 master 的密码
masterauth 123456

# 指定主机(master)的IP地址和端口,只有从节点配置此项
replicaof 199.188.166.111 6379  

通过命令设置密码，不需要重启redis服务。连接redis之后，通过命令设置

config set requirepass 123456

设置之后，可通过以下指令查看密码

config get requirepass

注：通过命令行修改了密码之后，配置文件（/etc/redis.conf）的requirepass字段后面的密码是不会随之修改的

哨兵配置

每台机器的哨兵进程都需要一个配置文件sentinel.conf，三台机器的配置是一样的，同样放到etc目录下

# 端口默认为26379
port 26379 
# 关闭保护模式，可以外部访问
protected-mode no 
# 开启守护进程
daemonize yes
# 指定数据存放目录
dir /app/redis/data
# 指定日志文件
logfile /app/redis/log/sentinel.log
# 指定主机IP地址和端口，并且指定当有2台哨兵认为主机挂了，则对主机进行容灾切换
sentinel monitor mymaster 199.188.166.111 6379 2
# 当在Redis实例中开启了requirepass，这里就需要提供密码
sentinel auth-pass mymaster 123456
# 这里设置了主机多少秒无响应，则认为挂了
sentinel down-after-milliseconds mymaster 3000
# 主备切换时，最多有多少个slave同时对新的master进行同步，这里设置为默认的1
snetinel parallel-syncs mymaster 1
# 故障转移的超时时间，这里设置为三分钟
sentinel failover-timeout mymaster 180000

启动服务

# 启动主从节点
cd /app/redis/bin
./redis-server /app/redis/etc/redis.conf # 指定配置文件进行启动

# 启动哨兵
cd /app/redis/bin
./redis-sentinel /app/redis/etc/sentinel.conf # 指定配置文件进行启动

停止服务

# 停止主从节点
cd /app/redis/bin
./redis-cli -p 6379 -a 123456 shutdown # 如有密码通过-a指定

# 停止哨兵
./redis-cli -p 26379 shutdown

查看状态

# 查看主从节点状态
[redis@node1 ~]$ cd /app/redis/bin/
[redis@node1 bin]$ ./redis-cli -p 6379
127.0.0.1:6379> auth 123456
OK
127.0.0.1:6379> info replication
# Replication
role:slave
master_host:199.188.166.113
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_read_repl_offset:520513
slave_repl_offset:520513
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:0d7bedf45f715de630f55d584c3a7c911c9330a1
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:520513
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:117462
repl_backlog_histlen:403052

# 查看哨兵状态
[redis@node1 ~]$ cd /app/redis/bin/
[redis@node1 bin]$ ./redis-cli -p 26379
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
master0:name=mymaster,status=ok,address=199.188.166.113:6379,slaves=2,sentinels=3

Redis哨兵模式的优缺点

优点

• 哨兵模式是基于主从模式的，所有主从的优点，哨兵模式都具有。
• 主从可以自动切换，系统更健壮，可用性更高。

缺点

• 具有主从模式的缺点，每台机器上的数据是一样的，内存的可用性较低。
• Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

拓展：为什么Redis推荐奇数节点

其实，Redis并不是只能是奇数个节点，只是推荐奇数个节点，主要原因还是处于成本考虑，因为奇数个节点和偶数个节点允许宕机的节点数是一样的，因为Redis规定：

集群中，半数以上（必须>50%，=50%也不行）节点认为主节点故障了，才会选举新的节点。

---

蚂蚁🐜再小也是肉🥩！