上一节介绍了 Redis 主从复制, 我们知道主从架构存在一个致命的问题----Master 宕机后整个集群不可用, 且必须运维人员手动进行故障转移.

因此, 哨兵来了

1. 哨兵模式(Sentinel)简介

顾名思义, 哨兵 就是站岗、放哨、巡逻、稽查的士兵, 举个例子, 就是当你在干活时派几个人盯着你, 看你有没有偷懒, 有没有累倒, 如果你累倒了重新派个人, 通知领导等等. Redis 哨兵模式 其实就是一个自动监控、管理、处理 Redis 集群间故障的一个 Redis 服务端程序, 运行在一个特殊的模式下, 不提供数据存储服务, 只进行普通 Redis 节点监控管理等工作. 在哨兵模式中, 节点共分为两大类:

• 数据节点(读写)

• 哨兵节点(监控)

2. Sentinel 工作原理简介

• 当 Master 宕机后, 整个集群将不可用(无法写)

• 此时, 多个 Sentinel 会监控并确认到 Master 宕机, 因此多个 Sentinel 之间会进行一次选举, 选出一个 Sentinel 作为代表进行故障转移

• 当选的 Sentinel 从剩余在线的所有 slave 节点中选举一个 slave 作为新的 Master

• 通知所有的 Slave 新的 Master 地址, 通知所有的 Sentinel 新的 Master 地址, 并重新配置集群

3. Sentinel 作用

通过上面对 Sentinel 的简单介绍, 相信大家已经对 Sentinel 是干什么的有了一个基本的认识, 概括来讲, Sentinel 有如下作用:

• 监控: Sentinel 会不断检查您的主实例和副本实例是否按预期工作。

• 通知: Sentinel 可以通过 API 通知系统管理员或其他计算机程序，其中一个受监控的 Redis 实例出现问题。

• 自动故障转移: 如果一个 master 没有按预期工作，Sentinel 可以启动一个故障转移过程，其中一个副本被提升为 master，其他额外的副本被重新配置为使用新的 master，并且使用 Redis 服务器的应用程序被告知要使用的新地址连接时。

• 配置提供者: Sentinel 充当客户端服务发现的权威来源：客户端连接到 Sentinel 以请求负责给定服务的当前 Redis 主服务器的地址。如果发生故障转移，Sentinels 将报告新地址。

详细可以参考官方文档: https://redis.io/docs/manual/sentinel/#sentinel-as-a-distributed-system

4. Sentinel 实战

4.1 服务器规划

• 192.168.3.26: Master 实例, Sentinel 1

• 192.168.3.27: Slave1 实例, Sentinel 2

• 192.168.3.28:Slave2 实例, Sentinel 3

4.2 主从复制

主从复制的配置这里不再赘述, 还不清楚的朋友去参考上一节 Redis 专题 Redis 集群-主从复制

4.3 启动 Sentinel

启动 Sentinel 这里还是以 Docker 为例(不建议大家在生产环境通过 Docker 部署, 具体问题可以参考官网Sentinel、Docker、NAT 可能的问题: https://redis.io/docs/manual/sentinel/#sentinel-docker-nat-and-possible-issues).

docker run -d --name sentinel1 -p 26379:26379 --restart=always \
   -v ${CONF_DIR}/redisSentinel1:/usr/local/etc/redis \
   -v ${LOGS_DIR}/redisSentinel1:/logs \
   -v ${VOLUME_DATA_DIR}/redisSentinel1:/data \
   redis redis-sentinel /usr/local/etc/redis/sentinel.conf

这里可以看到, 镜像依然是 redis 的镜像, 只不过有以下几个改动:

• 端口从 6379 变为 26379 (配置文件可以改, 默认为 26379)

• 运行命令从 redis-server 变为 redis-sentinel(运行在 sentinel mode)

• 配置文件从redis.conf 变为 sentinel.conf

4.4 配置 Sentinel

4.4.1 配置 Sentinel1

从上面启动命令已经看到, 要运行 sentinel 我们需要准备一个 sentinel.conf 配置文件, 该文件对 sentinel mode 的 redis 实例进行配置, 一个基本配置如下:

# 指定哨兵运行的端口
port 26379
# 为哨兵命名(mymaster), 192.168.3.26 监控 redis 集群的主节点, 2(quorum) 表示有 2 个 sentinel 认为某一个节点挂了就真的认为它挂了(一般为 sentinel 集群数 / 2 + 1)
sentinel monitor mymaster 192.168.3.26 6379 2
# 主节点多长时间没响应就认为其挂了60000 == 60s
sentinel down-after-milliseconds mymaster 60000
# 新的 master 同步时一次有多少副本进行同步(越小服务器压力越小, 时间花费的越长)
sentinel parallel-syncs mymaster 1
# 数据同步超时时间
sentinel failover-timeout mymaster 180000

# Redis 实例密码以确保 Sentinel 可以链接到 Redis 实例
sentinel auth-pass mymaster javaFamily123!!

# 允许其他人访问
bind 0.0.0.0
protected-mode no

# 解决 docker 部署 ip 和端口重新映射的问题
sentinel announce-ip 192.168.3.26
sentinel announce-port 26379

运行起来 Sentinel 后会发现 Sentinel 后台有如下日志输出

4.4.2 配置 Sentinel2 及 Sentinel3

配置 Sentinel2 及 Sentinel3 与 Sentinel1 基本类似, 只是在对应机器上创建对应的配置文件, 启动 docker 即可

这里以 Sentinel2 为例说明

• sentinel.conf

# 指定哨兵运行的端口
port 26379
sentinel monitor mymaster 192.168.3.26 6379 2
sentinel auth-pass mymaster javaFamily123!!
sentinel down-after-milliseconds mymaster 60000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

bind 0.0.0.0
protected-mode no

sentinel announce-ip 192.168.3.27
sentinel announce-port 26379

只需注意修改 sentinel announce-ip 为正确的 ip 即可.

• 启动 sentinel2

docker run -d --name sentinel2 -p 26379:26379 --restart=always \
   -v ${CONF_DIR}/redisSentinel2:/usr/local/etc/redis \
   -v ${LOGS_DIR}/redisSentinel2:/logs \
   -v ${VOLUME_DATA_DIR}/redisSentinel2:/data \
   redis redis-sentinel /usr/local/etc/redis/sentinel.conf

4.4.3 查看 Sentinel 集群

• Sentinel 正常启动后可以看到如下日志输出

• 有时候也可以看到 sdown 及 odown 等标记

其中 sdown 表示主观下线, +sdown 表示新增主观下线标记, 以上截图中意思为: sentinel1 主观认为 slave2(192.168.3.28) 下线了 如果认为某一个节点下线的哨兵数量达到配置文件中配置的 quorum 数(我们是 3 个 sentinel 集群, quorum 配置的 2)就会标记下线节点 +odown, 表示客观下线 如果没有达到 quorum, 即可能只是某个 sentinel 网络原因认为其主观下线, 待网络正常后就会取消主观下线标记, 即 -sdown

• Sentinel 正常启动后也可以通过 redis-cli 指令连接到客户端, 不过需要注意的是端口是 26379, 且 redis 运行在 Sentinel mode, 是不支持读写的

• 依然可以通过 info 指令查看 sentinel 状态, 不过在 sentinel mode 下会有一个 Sentinel 的信息板块

4.5 测试故障转移

为了测试 sentinel 的故障转移, 我们直接手动停止 master 实例

我们需要等待 down-after-milliseconds mymaster(我们配置的 60s)后就可以在 sentinel 后台看到如下信息:

4.6 测试新的主从

新的 master 已经切换到 slave2(192.168.3.28), 副本为 slave1, 因此我们连接到新的 master 和 slave 测试是否依然高可用

• 连接新的 master(slave2) 写入

• 连接 slave1 副本查询

至此, Sentinel 已经帮我们进行了故障转移, 整个 Redis 集群也达到了自动化高可用状态

5. 哨兵的优缺点

虽然 Sentinel 已经弥补了主从的不足, 自动帮我们进行故障转移, 但是依然还存在一些问题

5.1 哨兵模式的优点

• 哨兵集群，基于主从复制模式，所有的主从配置优点，它都有

• 主从可以切换，故障可以转移，高可用性的系统

• 哨兵模式就是主从模式的升级，手动到自动，更加健壮

• Sentinel 会不断的检查主服务器 和 从服务器是否正常运行。当被监控的某个 Redis 服务器出现问题，Sentinel 通过API脚本向管理员或者其他的应用程序发送通知。

5.2 哨兵模式的缺点

• 单个节点的存储能力是有上限的，访问能力是有上限的, Redis 不好在线扩容，集群容量一旦到达上限，在线扩容就十分麻烦

• 每个节点都存储着相同的数据, 很浪费内存

• 哨兵模式的配置繁琐