哨兵集群
上篇文章介绍了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
复制代码删除哨兵节点
增加哨兵节点时，集群会自动发现哨兵实例。
如果要停止某个哨兵，需按如下步骤进行：
-
- 停止哨兵进程
-
- 在所有哨兵上执行
SENTINEL RESET *，清理 master 状态
- 在所有哨兵上执行
-
- 在所有哨兵上执行
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）已经变为新主库的一个从库了。
至此，我们可以确认哨兵集群是能够正常工作的，在主库宕机时，能够选出新主库，并完成主从切换，并通知客户端更新主库信息。旧主库重新上线后，会自动切换为新主库的从库。