系列专栏：Redis系列专栏

哨兵集群

上篇文章介绍了Redis主从架构模式，在这个模式下，主库存在着单点问题，如果主库发生故障，那客户端就无法发送写请求，而且从库也无法进行数据复制同步了。所以一般部署Redis主库架构时，还会部署哨兵（Sentinel）集群来保证Redis的高可用性，在主库发生故障时，可以自动进行故障转移，将从库切换为新的主库。这篇文章就来看看如何部署哨兵集群，以及其工作的原理。

哨兵部署架构

哨兵机制是 Redis 官方高可用解决方案，哨兵本身也是集群分布式部署，且至少需要2个以上节点才能正常工作。

上篇文章我们部署了一主两从，在此基础之上，我们在每台服务器上再启动一个哨兵实例，由三个哨兵组成的哨兵集群来监控Redis主从集群，部署架构如下图所示，这也是比较经典的3节点哨兵集群。

部署哨兵集群

哨兵其实就是一个运行在特殊模式下的 Redis 进程，部署哨兵的前提就是已经安装了Redis，安装方式可以参考 Redis系列（1） — 单机版安装及数据持久化。

安装好 Redis 后，将哨兵配置文件拷贝到 /var/redis 下：

# cp /usr/local/src/redis-6.2.5/sentinel.conf /etc/redis/

修改配置文件中的如下配置：

配置	值	说明
bind	<ip>	绑定本机IP
port	26379	端口
daemonize	yes	后台运行
pidfile	/var/run/redis-sentinel.pid	PID文件
logfile	/var/redis/log/26379.log	日志文件
dir	/var/redis/26379	工作目录
sentinel monitor	<master-name> <ip> <redis-port> <quorum>	要监控的 master

其中，sentinel monitor <master-name> <ip> <redis-port> <quorum> 可以有多个，因为一个哨兵集群可以监控多个Redis主从集群。

sentinel monitor mymaster 172.17.0.2 6379 2

创建工作目录：

# mkdir -p /var/redis/26379

切换到redis安装目录：

/usr/local/src/redis-6.2.5/src

在每台机器上分别启动哨兵：

./redis-sentinel /etc/redis/sentinel.conf

检查哨兵是否启动成功：

[root@centos-03 src]# ps -ef|grep redis
root       185     1  0 03:05 ?        00:00:05 /usr/local/bin/redis-server 172.17.0.4:6379
root       213     1  0 03:37 ?        00:00:00 ./redis-sentinel 172.17.0.4:26379 [sentinel]

检查哨兵状态

启动完成后，可以查看哨兵日志，日志里会显示出每个哨兵监控的 master，并能够自动发现对应的 slave。

[root@centos-03 src]# cat /var/redis/log/26379.log 
213:X 28 Dec 2021 03:37:46.227 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
213:X 28 Dec 2021 03:37:46.227 # Redis version=6.2.5, bits=64, commit=00000000, modified=0, pid=213, just started
213:X 28 Dec 2021 03:37:46.227 # Configuration loaded
213:X 28 Dec 2021 03:37:46.227 * monotonic clock: POSIX clock_gettime
213:X 28 Dec 2021 03:37:46.228 * Running mode=sentinel, port=26379.
213:X 28 Dec 2021 03:37:46.228 # Sentinel ID is f43d3d4bca3f809be708c17e4c1c8951de5c6d9d
213:X 28 Dec 2021 03:37:46.228 # +monitor master mymaster 172.17.0.2 6379 quorum 2
213:X 28 Dec 2021 03:37:46.230 * +slave slave 172.17.0.4:6379 172.17.0.4 6379 @ mymaster 172.17.0.2 6379
213:X 28 Dec 2021 03:37:46.234 * +slave slave 172.17.0.3:6379 172.17.0.3 6379 @ mymaster 172.17.0.2 6379
213:X 28 Dec 2021 03:37:47.955 * +sentinel sentinel fbeaca3b7cc3a7fee7660dd2e239683021861d69 172.17.0.3 26379 @ mymaster 172.17.0.2 6379
213:X 28 Dec 2021 03:37:48.063 * +sentinel sentinel 018048f0adc0523b4b13d8ddde04c8882bb3d9af 172.17.0.2 26379 @ mymaster 172.17.0.2 6379

接着可以连接到哨兵服务器：

redis-cli -h 172.17.0.4 -p 26379 

然后通过如下几个命令来检查哨兵的状态：

sentinel master mymaster 
sentinel slaves mymaster 
sentinel sentinels mymaster 
sentinel get-master-addr-by-name mymaster

删除哨兵节点

增加哨兵节点时，集群会自动发现哨兵实例。

如果要停止某个哨兵，需按如下步骤进行：

• 1. 停止哨兵进程
• 1. 在所有哨兵上执行 SENTINEL RESET *，清理 master 状态
• 1. 在所有哨兵上执行 SENTINEL MASTER mymaster查看所有哨兵对数量是否达成了一致

哨兵组成

基本运行机制

哨兵其实就是一个运行在特殊模式下的 Redis 进程，是 Redis 集群架构中非常重要的一个组件，哨兵主要负责的就是三个任务：监控、选主、通知。

• 监控：负责监控 redis master 和 slave 进程是否正常工作
• 选主：如果 master 挂掉了，从 salve 中选举一个新的 master 出来
• 通知：如果故障转移发生了，通知客户端新的 master 地址

哨兵进程在运行时，会周期性地给所有的主库、从库发送 PING 命令，检测它们是否在线运行。如果从库没有在规定时间内响应哨兵的 PING 命令，哨兵就会把它标记为 下线状态；如果主库没有在规定时间内响应哨兵的 PING 命令，哨兵就会判定 主库下线，然后开始自动切换主库的流程。

自动切换主库首先就是要选主，主库挂了以后，哨兵就需要从多个从库里，按照一定的规则选择一个从库实例，把它作为新的主库，集群就有了新主库。

选好新主库后，哨兵就要去把新主库的连接信息通知给其他从库，让它们执行 replicaof 命令，和新主库建立连接，并进行数据复制。同时，哨兵会把新主库的连接信息通知给客户端，让它们把请求操作发到新主库上。

集群发现机制

启动哨兵的最小配置就是：

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

哨兵实例启起来之后，就可以与主库建立连接，那么哨兵如何知道有哪些从库呢？

哨兵会向主库发送 INFO 命令，INFO 命令返回的结果中就包含了主库的信息以及从库的信息。有了从库的信息后，哨兵就可以和从库建立连接，定时发送 PING 命令检查主从库的健康状况。

INFO 命令中就包含从库的信息：

哨兵发现机制

哨兵只是连接到主库，那它怎么知道集群中其它的哨兵呢？哨兵之间也需要互相发现，在判断主库下线和选主的时候需要集群中的哨兵来共同投票完成。

哨兵互相之间的发现，是通过 Redis 的 pub/sub（发布/订阅） 机制实现的，每个哨兵每隔2秒会往 __sentinel__:hello 这个频道里发送一个消息，这个消息包含自己的 IP、端口、实例ID等信息，然后其他哨兵都可以消费到这个消息，就可以知道其他哨兵的信息了，然后建立连接。

每个哨兵还会发送对主库的监控配置，这样可以跟其他哨兵交换对主库的监控配置，互相进行监控配置的同步。

核心原理

判断主库下线

哨兵对主库的下线判断有“主观下线(sdown)”和“客观下线(odown)”两种，只有客观下线，才会开启主从切换的过程。

哨兵会使用PING命令周期性的检测它自己和主、从库的网络连接情况，来判断实例的状态。如果主库或从库响应 PING 命令超时，哨兵就会标记它“主观下线”。

PING 检测超时时间参数如下，默认30秒：

sentinel down-after-milliseconds mymaster 30000 

如果是从库，那么就是简单的标记为“主观下线”，因为从库的下线一般影响不太大，集群的对外服务不会间断。而如果是主库主观下线，并不会立即开启主从切换，因为可能存在误判的情况。误判就是主库实际并没有故障，但可能由于集群网络压力较大、网络拥塞等情况导致哨兵误判。而一旦开启主从切换，就要去选择新主库，然后同步主从库数据，还要去通知客户端连接到新主库，开销非常大。所以有必要判断是否误判，减少误判的情况。

减少误判的办法就是通过多个哨兵实例一起来判断，只有哨兵集群中超过指定数量的实例认为主库“主观下线”，才会认为主库“客观下线”，表明主库下线已经是一个客观事实了。

哨兵集群中任何一个实例只要判断主库“主观下线”后，就会给其他实例发送 is-master-down-by-addr 命令，其他实例会根据自己和主库的连接情况，返回 Y（赞成票）或 N （反对票）。一个哨兵只要获得仲裁所需的赞成票数后，就可以标记主库客观下线。

仲裁所需的赞成票数量就是 sentinel monitor 参数中指定的 quorum 值。例如，有3个哨兵，quorum 配置的是2，那么，一个哨兵需要2张赞成票，就可以标记主库为“客观下线”了，这两票包括自己的一票和另外一个哨兵的一票。

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

判断主库下线的流程大致如下：

Leader选举

一段时间内，哨兵集群中可能有多个哨兵都判定主库客观下线，这时就需要选一个哨兵出来执行主从切换。判定主库客观下线的哨兵接着会向其它哨兵发送命令，让它给自己投票，表明希望由自己来执行主从切换。这个投票过程为Leader 选举，最终执行主从切换的哨兵称为 Leader。

投票过程中，判定主库客观下线的哨兵首先给自己投一票赞成票，然后给其它哨兵发送命令，其它哨兵在未投票的情况下，会投赞成票，否则投反对票。哨兵成为 Leader 需满足以下条件：得到半数以上的赞成票（majority = N/2 + 1），且 得到的票数 >= quorum。

例如有5个哨兵，majority = 3，quorum = 2，那么哨兵就必须得到 3 票以上才能成为 Leader；如果 quorum = 5，那么就必须得到 5 票才能成为 Leader。

如果没有哨兵得到足够的票数，那么这轮投票就不会产生 Leader，哨兵集群会等待一段时间后再重新选举，等待的时间为故障转移超时时间的2倍。故障转移超时时间配置如下，默认180秒：

sentinel failover-timeout mymaster 180000

可以看到，哨兵集群能够成功投票，很大程度上依赖于选举命令的正常网络传播和传输快慢。如果网络压力较大或有短时堵塞，就可能导致没有一个哨兵能拿到半数以上的赞成票，网络状况好的哨兵就可能得到半数以上的赞成票。

哨兵数量

前面说过，哨兵集群需要至少3个实例才能正常工作，如果只有2个实例，那么一个哨兵想成为 Leader，必须获得2票才行，虽然正常情况下也能完成选举，但如果有个哨兵挂掉了，那么此时就无法得到足够的票数，就无法执行主从切换了。因此，2个哨兵实例无法保证哨兵集群高可用，通常我们至少会配置 3 个哨兵实例。

但哨兵实例也不是越多越好，哨兵在判定“主观下线”和选举“哨兵Leader”时，都需要和其他节点进行通信，哨兵实例越多，通信的次数也就越多，而且部署多个哨兵时，会分布在不同机器上，节点越多带来的机器故障风险也会越大，这些问题都会影响到哨兵的通信和选举，出问题时也就意味着选举时间会变长，切换主从的时间变久。

选择新主库

哨兵 Leader 选举出来之后，Leader 就可以开始执行主从切换了，主从切换首先就是要选择新的主库。

选择新主库的规则如下：

1. 网络状况

首先检查从库的网络状况，如果从库与主库断连超过 down-after-milliseconds * 10 毫秒，说明这个从库的网络状况不好，不适合用来做主库，被过滤掉。

2. 从库优先级

接下来对剩下的从库按优先级（replica-priority）排序，数值越低，优先级越高，如果有一个优先级最高的，那么它就是新的主库了。一般在服务器配置不一样的时候，我们可以给高配置服务器的实例设置高优先级。

优先级配置，默认100，数值越低优先级越高。注意注释中的说明，不要设置为0，设置为0表示这个从节点不会作为主库（master），就不会被哨兵选择作为主库。

# The replica priority is an integer number published by Redis in the INFO
# output. It is used by Redis Sentinel in order to select a replica to promote
# into a master if the master is no longer working correctly.
#
# A replica with a low priority number is considered better for promotion, so
# for instance if there are three replicas with priority 10, 100, 25 Sentinel
# will pick the one with priority 10, that is the lowest.
#
# However a special priority of 0 marks the replica as not able to perform the
# role of master, so a replica with priority of 0 will never be selected by
# Redis Sentinel for promotion.
#
# By default the priority is 100.
replica-priority 100

3. 复制偏移量

如果上一步从库的优先级都一样，接下来就要判断从库和原主库的复制进度（offset），从库复制进度越靠后，优先级就越高。

主从库都会维护一个偏移量，主库写入 N 字节的指令，主库偏移量（master_repl_offset）就会加 N，从库接收了 N 字节的数据，从库偏移量（slave_repl_offset）就会加上 N。如果有从库的偏移量最接近主库的偏移量，那它就是新的主库。

4. 比较 runID

最后，在优先级和复制进度都相同的情况下，按 run ID 排序，ID 号最小的从库会被选为新主库。

以上就是“选主”的一个整体流程：

通知客户端

哨兵之间通过 pub/sub 机制组成集群，同时，哨兵又通过 INFO 命令，获得了从库的连接信息，也能和从库建立连接，并进行监控。主从库切换后，客户端也需要知道新主库的连接信息，所以，哨兵还需要把新主库的信息告诉客户端。

哨兵和客户端间的信息同步也是基于 pub/sub 机制来完成的，不过是基于哨兵的 pub/sub 机制，客户端可以从哨兵订阅消息。哨兵提供的消息订阅频道有很多，不同频道包含了主从库切换过程中的不同关键事件。

客户端和哨兵建立连接后，就可以订阅这些事件。主从切换完成后，客户端就会监听到 +switch-master 事件，这时客户端就可以从哨兵那得到新主库的地址和端口了。

通过 pub/sub 机制，有了这些事件通知，客户端不仅可以在主从切换后得到新主库的连接信息，还可以监控到主从库切换过程中发生的各个重要事件。这样，客户端就可以知道主从切换进行到哪一步了，有助于了解切换进度。

配置版本号

哨兵在切换主库时，会从要切换到的新主库那里得到一个 epoch（版本号）每次切换的 epoch 都是唯一的。如果第一个选举出的哨兵切换失败了，那么其他哨兵，会等待 failover-timeout 时间，然后接替继续执行切换，此时会重新获取一个新的 epoch。

哨兵完成切换之后，会在自己本地更新生成最新的master配置，然后通过 pub/sub 机制同步给其他的哨兵。这时 epoch 版本号就起作用了，因为各种消息都是通过一个channel去发布和监听的，所以一个哨兵完成一次新的切换之后，新的master配置是跟着新的 epoch 版本号的，其他的哨兵都是根据版本号的大小来更新自己的master配置的。

数据丢失

Redis 主从复制存在两种数据丢失的情况：

1. 异步复制

主库同步数据到从库是异步的，所以可能有部分数据还未同步到从库，主库就宕机了，这部分数据就丢失了。

2. 脑裂

如果主库所在服务器脱离了正常网络，与其它从库都无法连接，但实际上主库还运行着。而哨兵会认为主库宕机了，然后开始选择新的主库，这时集群就会有两个主库，这就是“脑裂”。这时可能客户端还没来得及切换到新的主库，然后继续向旧主库写数据，而旧主库恢复后，会被当成新主库的一个从库，数据也会被清空，重新从新主库复制数据，那么这部分数据也会丢失。

有两个配置可以减少异步复制和脑裂问题导致的数据丢失：

min-replicas-to-write 1 # 默认 3
min-replicas-max-lag 10 # 默认 10

这两个配置的意思是至少有1个（min-replicas-to-write）从库，与主库的复制同步延迟超过10秒（min-replicas-max-lag）后，主库就不再接收任何写请求。

这两个配置可以确保任何一个从库跟主库如果延时超过10秒，主库就不会接收客户端任何写请求，最多丢失10秒的数据。

集群容灾演练

下面通过一些测试来看下在主库宕机时，哨兵是否能重新选主并切换新主库。

主库下线分析

首先在其中一个哨兵实例上查看当前主库的信息如下（172.17.0.2）：

现在将主库 kill 掉，并删除 PID 文件：

可以查看哨兵日志：

首先可以得知当前哨兵ID为：

# Sentinel ID is 018048f0adc0523b4b13d8ddde04c8882bb3d9af

杀掉主库后，可以看到哨兵判定 master 主观下线（+sdown）：

# +sdown master mymaster 172.17.0.2 6379

接着有 quorum 数量的哨兵都认为 master 主观下线了，状态变为客观下线（+odown）：

# +odown master mymaster 172.17.0.2 6379 #quorum 2/2

接着就获取了一个新的 epoch 版本号：

# +new-epoch 1

然后是投票选举Leader阶段：当前哨兵投票给了自己，另外两个哨兵也投票给了自己：

# +vote-for-leader 018048f0adc0523b4b13d8ddde04c8882bb3d9af 1
# f43d3d4bca3f809be708c17e4c1c8951de5c6d9d voted for 018048f0adc0523b4b13d8ddde04c8882bb3d9af 1
# fbeaca3b7cc3a7fee7660dd2e239683021861d69 voted for 018048f0adc0523b4b13d8ddde04c8882bb3d9af 1

选出了新出库（172.17.0.4）：

# +selected-slave slave 172.17.0.4:6379 172.17.0.4 6379 @ mymaster 172.17.0.2 6379

实例退出主观下线状态：

# -odown master mymaster 172.17.0.2 6379

从库重新配置事件：

* +slave-reconf-inprog slave 172.17.0.3:6379 172.17.0.3 6379 @ mymaster 172.17.0.2 6379 160:X 21 Feb 2022 03:48:47.494 
* +slave-reconf-done slave 172.17.0.3:6379 172.17.0.3 6379 @ mymaster 172.17.0.2 6379

新主库切换完成：

# +switch-master mymaster 172.17.0.2 6379 172.17.0.4 6379

至此，我们通过日志可以看到Redis主备切换的一个过程，然后在哨兵上也可以看到主库已经切换成功。

旧主库上线

再将旧主库重新启动：

启动之后在哨兵日志中可以看到旧主库已经退出主观下线状态了：

# -sdown slave 172.17.0.2:6379 172.17.0.2 6379 @ mymaster 172.17.0.4 6379

接着在新主库（172.17.0.4）中查看，可以发现旧主库（172.17.0.2）已经变为新主库的一个从库了。

至此，我们可以确认哨兵集群是能够正常工作的，在主库宕机时，能够选出新主库，并完成主从切换，并通知客户端更新主库信息。旧主库重新上线后，会自动切换为新主库的从库。