Redis系列（3）哨兵高可用

　　哨兵集群
　　上篇文章介绍了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
　　port
　　26379
　　端口
　　daemonize
　　yes
　　后台运行
　　pidfile
　　/var/run/redis-sentinel.pid
　　PID文件
　　logfile
　　/var/redis/log/26379.log
　　日志文件
　　dir
　　/var/redis/26379
　　工作目录
　　sentinel monitor
　　
　　要监控的 master
　　其中，sentinel monitor    可以有多个，因为一个哨兵集群可以监控多个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     复制代码
　　哨兵实例启起来之后，就可以与主库建立连接，那么哨兵如何知道有哪些从库呢？
　　哨兵会向主库发送 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     复制代码
　　判断主库下线的流程大致如下：
　　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）已经变为新主库的一个从库了。
　　至此，我们可以确认哨兵集群是能够正常工作的，在主库宕机时，能够选出新主库，并完成主从切换，并通知客户端更新主库信息。旧主库重新上线后，会自动切换为新主库的从库。
　　作者：bojiangzhou
　　链接：https://juejin.cn/post/7067024548884906020