Redis系列(三)-Redis哨兵模式(一篇文章让你全面的了解reids哨兵模式)

哨兵模式概述

举一个通俗易懂的例子

有一个皇帝(master)他有2个儿子，大儿子(slave1)和小儿子(slave2)。有一天皇帝离家出走了皇位空虚(master宕机)，大儿子和小儿子为了争夺皇位杀得血流成河，导致国家动荡不安(redis无法提供服务)。这个时候三个辅政大臣(哨兵)站出来了说：你们别打架了，再打国家破裂了(服务器瘫痪)，由我们来考察你们那个可以登基做皇帝。于是三位辅政大臣经过讨论，超过半数(2人同意,先皇规定必须大于等于2票)推举了大儿子当皇帝。后来的某一天老皇帝突然回来了三位辅政大臣说根据祖训，不好意思你不能继续当皇帝了，你就在旁边做你的太上皇(slave1)吧。

哨兵模式的角色

上面的例子对应redis的哨兵模式角色如下：

皇帝：master主redis服务器

太上皇/大儿子：slave1从redis服务器1

小儿子：slave2从redis服务器2

三位辅政大臣：分别是三个哨兵sentinel，如果只有一位辅政大臣就是单个哨兵(也是一种redis服务器，只不过不提供对外服务)

上面提到了==超过半数(2人同意,先皇规定必须大于等于2票)==就好比sentinel里面配置的票数参数（具体如何配置，后面会讲到）

技术来介绍哨兵模式

sentinel系统可以监视一个或者多个redis master服务，以及这些master服务的所有从服务。当某个master服务下线时，自动将该master下的某个从服务升级为master服务替代已下线的master服务继续处理请求。当修复已下线的master服务后不会抢占新的master的角色。
sentinel可以让redis实现主从复制，当一个集群中的master失效之后，sentinel可以选举出一个新的master用于自动接替master的工作，集群中的其他redis服务器自动指向新的master同步数据。一般建议sentinel采取奇数台，防止某一台sentinel无法连接到master导致误切换
Sentinel(哨兵)是用于监控redis集群中Master状态的工具，是Redis 的高可用性解决方案，sentinel哨兵模式已经被集成在redis2.4之后的版本中
Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案，当用Redis做Master-slave的高可用方案时，假如master宕机了，Redis本身(包括它的很多客户端)都没有实现自动进行主备切换，而Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自动切换。Sentinel由一个或多个Sentinel 实例组成的Sentinel 系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器。

哨兵模式的作用

监控(Monitoring): 哨兵(sentinel) 会不断地发消息检查你的Master和Slave是否运作正常。

提醒(Notification)：当被监控的某个Redis节点出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。

自动故障迁移(Automatic failover)：当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作，它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master；当客户端试图连接失效的Master时，集群也会向客户端返回新Master的地址，使得集群可以使用现在的Master替换失效Master。Master和Slave服务器切换后，Master的redis.conf、Slave的redis.conf和sentinel.conf的配置文件的内容都会发生相应的改变，即，Master主服务器的redis.conf配置文件中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换。

哨兵模式流程图

单台哨兵：

多台哨兵集群：

哨兵进行对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式

Sentinel状态持久化

snetinel的状态会被持久化地写入sentinel的配置文件中。每次当收到一个新的配置时，或者新创建一个配置时，配置会被持久化到硬盘中，并带上配置的版本戳。这意味着，可以安全的停止和重启sentinel进程。

Sentinel工作方式，选举原理，自动切换机制（每个Sentinel实例都执行的定时任务）

每个Sentinel以每秒一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个PING命令。
如果一个实例（instance）距离最后一次有效回复PING命令的时间超过 own-after-milliseconds 选项所指定的值(在sentinel的配置文件中指定，后面会说到)，则这个实例会被Sentinel标记为主观下线。
如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。
当有足够数量的Sentinel（大于等于配置文件指定的值，该值在sentinel的配置文件指定监控master主机的时候在末尾指定的，例：sentinel monitor myredis 127.0.0.1 6379 1）在指定的时间范围内确认Master的确进入了主观下线状态，则Master会被标记为客观下线。
在一般情况下，每个Sentinel 会以每10秒一次的频率向它已知的所有Master，Slave发送 INFO 命令。
当Master被Sentinel标记为客观下线时，Sentinel 向下线的 Master 的所有Slave发送 INFO命令的频率会从10秒一次改为每秒一次。
若没有足够数量的Sentinel同意Master已经下线，Master的客观下线状态就会被移除。若 Master重新向Sentinel 的PING命令返回有效回复，Master的主观下线状态就会被移除。

主观下线与客观下线

主观下线：(Subjectively Down，简称 SDOWN）指的是单个Sentinel(哨兵)实例对服务器做出的下线判断，即单个sentinel认为某个服务下线（有可能是接收不到订阅，之间的网络不通等等原因）。服务器在down-after-milliseconds给定的毫秒数之内，没有返回 Sentinel 发送的 PING 命令的回复，或者返回一个错误，那么 Sentinel 将这个服务器标记为主观下线（SDOWN ）。如果多个sentinel监视一个服务，有可能存在多个sentinel的down-after-milliseconds配置不同，这个在实际生产中要注意。

客观下线:（Objectively Down，简称 ODOWN）指的是多个 Sentinel (哨兵)实例在对同一个服务器做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的服务器下线判断，然后开启failover(执行故障转移)。只有当master被认定为客观下线时，才会发生故障迁移。

哨兵之间交流方式，如何判断主观和客观

sentinel通过发送 SENTINEL is-master-down-by-addr ip port current_epoch runid，（ip：主观下线的服务id，port：主观下线的服务端口，current_epoch：sentinel的纪元，runid：*表示检测服务下线状态，如果是sentinel 运行id，表示用来选举领头sentinel）来询问其它sentinel是否同意服务下线。
一个sentinel接收另一个sentinel发来的is-master-down-by-addr后，提取参数，根据ip和端口，检测该服务时候在该sentinel主观下线，并且回复is-master-down-by-addr，回复包含三个参数：down_state（1表示已下线，0表示未下线），leader_runid（领头sentinal id），leader_epoch（领头sentinel纪元）。
sentinel接收到回复后，根据配置设置的下线最小数量，达到这个值，既认为该服务客观下线。
客观下线条件只适用于主服务器：对于任何其他类型的 Redis 实例， Sentinel 在将它们判断为下线前不需要进行协商，所以从服务器或者其他 Sentinel 永远不会达到客观下线条件。
只要一个 Sentinel 发现某个主服务器进入了客观下线状态，这个 Sentinel 就可能会被其他 Sentinel 推选出，并对失效的主服务器执行自动故障迁移操作。

Sentinel三个定时任务

每10秒每个sentinel会对master和slave执行info命令，这个任务达到两个目的：发现slave节点和确认主从关系
每2秒每个sentinel通过master节点的channel交换信息（pub/sub）。master节点上有一个发布订阅的频道(sentine:hello)。sentinel节点通过sentinel:hello频道进行信息交换(对节点的"看法"和自身的信息)，达成共识。
每1秒每个sentinel对其他sentinel和redis节点执行ping操作（相互监控），这个其实是一个心跳检测，是失败判定的依据。

slave配置的自动纠正

哨兵会负责自动纠正slave的一些配置，比如slave如果要成为潜在的master候选人，哨兵会确保slave在复制现有master的数据; 如果slave连接到了一个错误的master上，比如故障转移之后，那么哨兵会确保它们连接到正确的master上。

为什么不搭建两台哨兵集群而至少是三台呢？

原因：两台哨兵无法执行故障转移

如果哨兵集群仅仅部署了个2个哨兵实例，quorum=1

master宕机，sentinel1和sentinel2中只要有1个哨兵认为master宕机就可以进行故障切换，同时s1和s2中会选举出一个哨兵来执行故障转移

同时这个时候，进行故障转移的哨兵选取需要获得大部分哨兵的统一授权。需要majority，2个哨兵的majority就是2（2的majority=2，3的majority=2，5的majority=3，4的majority=2），2个哨兵都运行着，就可以允许执行故障转移

但是如果整个M1和S1运行的机器宕机了，此时就没有majority来允许执行故障转移，虽然另外一台机器还有一个R1，但是故障转移不会执行

发生故障转移时，如何选举哨兵领导者(执行者)

选举哨兵领导者的过程，需要多个哨兵节点共同协商来选出。这个选举协商的过程，在分布式领域中叫做达成共识，协商的算法叫做共识算法。
共识算法主要为了解决在分布式场景下，多个节点如何针对某一个场景达成一致的结果。
共识算法包括很多种，例如Paxos、Raft、Gossip算法等，(可以说下Raft算法，其他俩个复杂)。
哨兵选举领导者的过程类似于Raft算法，它的算法足够简单易理解。
简单来讲流程如下：

每个哨兵都设置一个随机超时时间，超时后向其他哨兵发送申请成为领导者的请求
其他哨兵只能对收到的第一个请求进行回复确认
首先达到多数确认选票的哨兵节点，成为领导者
如果在确认回复后，所有哨兵都无法达到多数选票的结果，那么进行重新选举，直到选出领导者为止

选择出哨兵领导者后，之后的故障恢复操作都由这个哨兵领导者进行操作。

slave服务器有多个如何选取一个新的master呢？

哨兵领导者针对发生故障的master节点，需要在它的slave节点中，选择一个节点来代替其工作。
这个选择新master过程也是有优先级的，在多个slave的场景下，优先级按照：slave-priority配置 > 数据完整性 > runid较小者进行选择。
也就是说优先选择slave-priority最小值的slave节点，如果所有slave此配置相同，那么选择数据最完整的slave节点，如果数据也一样，最后选择runid较小的slave节点。

故障转移过程

经过优先级选择，选出了备选的master节点后，下一步就是要进行真正的主从切换了。
哨兵领导者给备选的master节点发送slaveof no one命令，让该节点成为master。
哨兵领导者会给故障节点的所有slave发送slaveof $newmaster命令，让这些slave成为新master的从节点，开始从新的master上同步数据。
最后哨兵领导者把故障节点降级为slave，并写入到自己的配置文件中，待这个故障节点恢复后，则自动成为新master节点的slave。
一旦一个sentinel成功地对一个master进行了failover，即使其它的slave还没针对新master重新配置自己，它也将会把关于master的最新配置通过广播形式通知其它sentinel，其它的sentinel则更新对应master的配置。

至此，整个故障切换完成。

客户端感知新master

哨兵在故障切换完成之后，会向自身节点的指定pubsub中写入一条信息，客户端可以订阅这个pubsub来感知master的变化通知。我们的客户端也可以通过在哨兵节点主动查询当前最新的master，来拿到最新的master地址。
另外，哨兵还提供了“钩子”机制，我们也可以在哨兵配置文件中配置一些脚本逻辑，在故障切换完成时，触发“钩子”逻辑，通知客户端发生了切换，让客户端重新在哨兵上获取最新的master地址。

哨兵配置文件详解

# Example sentinel.conf
# 哨兵sentinel实例运行的端口 默认26379
port 26379# 哨兵sentinel的工作目录
dir /tmp# 设置哨兵sentinel实例后台启动
daemonize yes# 设置哨兵sentinel实例的日志输出
logfile /var/log/sentinel/5000/sentinel.log# 哨兵sentinel监控的redis主节点的 ip port
# master-name  可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。
# quorum 当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点失联了
# quorum的值一般设置为sentinel个数的二分之一加1，例如3个sentinel就设置2。
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2# 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供密码
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster 123# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行同步，
# 这个数字越小，完成failover所需的时间就越长，
# 但是如果这个数字越大，就意味着越 多的slave因为replication而不可用。
# 可以通过将这个值设为 1 来保证每次只有一个slave处于不能处理命令请求的状态。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1# 故障转移的超时时间 failover-timeout 可以用在以下这些方面：
# 1. 同一个sentinel对同一个master两次failover之间的间隔时间。
# 2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
# 3.当想要取消一个正在进行的failover所需要的时间。
# 4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了
# 默认三分钟
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000# SCRIPTS EXECUTION# 配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员。
# 对于脚本的运行结果有以下规则：
# 若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10
# 若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。
# 如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。
# 一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。# 通知型脚本:当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等），将会去调用这个脚本，
# 这时这个脚本应该通过邮件，SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时，将传给脚本两个参数，
# 一个是事件的类型，
# 一个是事件的描述。
# 如果sentinel.conf配置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentinel无法正常启动成功。
# 通知脚本
# sentinel notification-script <master-name> <script-path>
sentinel notification-script mymaster /var/redis/notify.sh# 客户端重新配置主节点参数脚本
# 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息。
# 以下参数将会在调用脚本时传给脚本:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
# 目前<state>总是“failover”,
# <role>是“leader”或者“observer”中的一个。
# 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的
# 这个脚本应该是通用的，能被多次调用，不是针对性的。
# sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

单台哨兵模式部署

Redis集群准备

首先我们要准备好一个伪Redis一主二从的Rdis集群（为什么说伪集群呢？应为学习机器不够，Redis服务器都搭建在同一个服务器上，生产实践上分开搭建即可）。

这里不对Rdis集群的搭建做过多的描述，具体请阅读博文：

单个哨兵的搭建

在redis启动目录，我的是：/usr/local/bin下面新建一个sentinel.conf文件，用来配置一个哨兵

命令：vim sentinel.conf

配置以下文件内容，具体不明白的查看上面的配置文件详解

port 26379
dir /tmp
sentinel monitor mymaster 127.0.0.1 6379 1
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

命令：redis-sentinel ./sentinel.conf

在Redis的启动目录下找到redis-sentinel 用它来启动哨兵

[root@VM-0-16-centos bin]# ls
appendonly.aof  log6380.log      redis-check-aof
busybox-x86_64  log6381.log      redis-check-rdb
dump6379.rdb    redis79.conf     redis-cli
dump6380.rdb    redis80.conf     redis.conf
dump6381.rdb    redis81.conf     redis-sentinel
dump.rdb        redis82.conf     redis-server
log6379.log     redis-benchmark  sentinel.conf
# 使用sentinel.conf配置文件启动哨兵
[root@VM-0-16-centos bin]# redis-sentinel sentinel.conf
23855:X 09 Dec 2021 16:11:57.710 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
23855:X 09 Dec 2021 16:11:57.710 # Redis version=6.2.6, bits=64, commit=00000000, modified=0, pid=23855, just started
23855:X 09 Dec 2021 16:11:57.710 # Configuration loaded
23855:X 09 Dec 2021 16:11:57.711 * monotonic clock: POSIX clock_gettime_._                                                  _.-``__ ''-._                                             _.-``    `.  `_.  ''-._           Redis 6.2.6 (00000000/0) 64 bit.-`` .-```.  ```\/    _.,_ ''-._                                  (    '      ,       .-`  | `,    )     Running in sentinel mode|`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379|    `-._   `._    /     _.-'    |     PID: 23855`-._    `-._  `-./  _.-'    _.-'                                   |`-._`-._    `-.__.-'    _.-'_.-'|                                  |    `-._`-._        _.-'_.-'    |           https://redis.io       `-._    `-._`-.__.-'_.-'    _.-'                                   |`-._`-._    `-.__.-'    _.-'_.-'|                                  |    `-._`-._        _.-'_.-'    |                                  `-._    `-._`-.__.-'_.-'    _.-'                                   `-._    `-.__.-'    _.-'                                       `-._        _.-'                                           `-.__.-'                                               23855:X 09 Dec 2021 16:11:57.712 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
23855:X 09 Dec 2021 16:11:57.721 # Sentinel ID is 23c6c1541cbc4444cd544ddc502e889b1699e353
23855:X 09 Dec 2021 16:11:57.721 # +monitor master mymaster 127.0.0.1 6379 quorum 1
23855:X 09 Dec 2021 16:11:57.722 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
23855:X 09 Dec 2021 16:11:57.730 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379

我们看到哨兵已经成功的启动，里面包括了哨兵ID，主机的信息和从机的信息，这样我们就成功的搭建好了一个单台的哨兵

测试主机断开

对主机6379执行SHUTDOWN，监控哨兵服务器的日志打印

在红色标记中哨兵检测到6379状态异常，查询选举到6380，给6380发送slaveod no one 操作升级为主机，断开slave6381与6379的来连接重新连接到6380。

再次查看Redis服务器节点信息，我们发现6380的角色切换已经成功

重启6379节点，我们发现哨兵讲6379自动的设置为6380的slave服务器

查看6379，6380，6381节点状态，6380变成master,6379和6381成为了slave服务器。

多台哨兵模式部署

Redis集群准备

这次准备的系统环境和单台哨兵模式搭建环境一模一样，采用一主二从的Redis集群

三台哨兵的搭建

在redis启动目录，我的是：/usr/local/bin下面新建3个sentinel.conf文件，分别是sentinel6379.conf、sentinel6380.conf、sentinel6381.conf

命令：vim sentinel6379.conf vim sentinel6380.conf vim sentinel6381.conf

vim sentinel6379.conf 写入下面的配置文件内容

port 26379
dir /tmp
daemonize yes
logfile /var/log/sentinel/sentinel6379.log
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

vim sentinel6380.conf 写入下面的配置文件内容

port 26380
dir /tmp
daemonize yes
logfile /var/log/sentinel/sentinel6380.log
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

vim sentinel6381.conf 写入下面的配置文件内容

port 26381
dir /tmp
daemonize yes
logfile /var/log/sentinel/sentinel6381.log
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

启动哨兵sentinel

[root@VM-0-16-centos bin]# redis-sentinel sentinel6379.conf
[root@VM-0-16-centos bin]# redis-sentinel sentinel6381.conf
[root@VM-0-16-centos bin]# redis-sentinel sentinel6380.conf
[root@VM-0-16-centos bin]# ps -ef|grep redis
root     11982     1  0 17:58 ?        00:00:00 redis-sentinel *:26379 [sentinel]
root     11993     1  0 17:58 ?        00:00:00 redis-sentinel *:26381 [sentinel]
root     12011     1  0 17:58 ?        00:00:00 redis-sentinel *:26380 [sentinel]
root     12072 23723  0 17:58 pts/4    00:00:00 grep --color=auto redis
root     16272     1  0 Dec08 ?        00:02:21 redis-server *:6380
root     19063 18893  0 15:47 pts/1    00:00:00 redis-cli -p 6380
root     19282 19084  0 15:48 pts/2    00:00:00 redis-cli -p 6381
root     26966     1  0 16:28 ?        00:00:07 redis-server *:6379
root     26987 18461  0 16:28 pts/0    00:00:00 redis-cli -p 6379
root     31412     1  0 Dec07 ?        00:03:31 ./redis-server *:6381

查看哨兵日志

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-eR5KCgfP-1639108467893)(image-20211209180800689.png)]

关闭master服务器

查看sentinel6379.log

[root@VM-0-16-centos /]# tail -f /var/log/sentinel/sentinel6379.log
11982:X 09 Dec 2021 17:58:37.082 * +sentinel sentinel ddc2a2cb16b6ee0af3327c509d1dc72b8f5db277 127.0.0.1 26380 @ mymaster 127.0.0.1 6379
11982:X 09 Dec 2021 18:09:21.927 # +sdown master mymaster 127.0.0.1 6379
11982:X 09 Dec 2021 18:09:22.018 # +new-epoch 1
11982:X 09 Dec 2021 18:09:22.025 # +vote-for-leader ddc2a2cb16b6ee0af3327c509d1dc72b8f5db277 1
11982:X 09 Dec 2021 18:09:23.044 # +odown master mymaster 127.0.0.1 6379 #quorum 3/2
11982:X 09 Dec 2021 18:09:23.044 # Next failover delay: I will not start a failover before Thu Dec  9 18:15:22 2021
11982:X 09 Dec 2021 18:09:23.102 # +config-update-from sentinel ddc2a2cb16b6ee0af3327c509d1dc72b8f5db277 127.0.0.1 26380 @ mymaster 127.0.0.1 6379
11982:X 09 Dec 2021 18:09:23.102 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6380
11982:X 09 Dec 2021 18:09:23.102 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380
11982:X 09 Dec 2021 18:09:23.102 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380
11982:X 09 Dec 2021 18:09:53.112 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380

查看sentinel6380.log

[root@VM-0-16-centos /]# tail -f /var/log/sentinel/sentinel6380.log
12011:X 09 Dec 2021 18:09:23.026 # +promoted-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
12011:X 09 Dec 2021 18:09:23.026 # +failover-state-reconf-slaves master mymaster 127.0.0.1 6379
12011:X 09 Dec 2021 18:09:23.101 * +slave-reconf-sent slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
12011:X 09 Dec 2021 18:09:24.069 * +slave-reconf-inprog slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
12011:X 09 Dec 2021 18:09:24.069 * +slave-reconf-done slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
12011:X 09 Dec 2021 18:09:24.127 # +failover-end master mymaster 127.0.0.1 6379
12011:X 09 Dec 2021 18:09:24.127 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6380
12011:X 09 Dec 2021 18:09:24.128 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380
12011:X 09 Dec 2021 18:09:24.128 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380
12011:X 09 Dec 2021 18:09:54.145 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380

查看sentinel6381.log

[root@VM-0-16-centos sentinel]# tail -f sentinel6381.log
11993:X 09 Dec 2021 17:58:29.828 # Configuration loaded
11993:X 09 Dec 2021 17:58:29.829 * monotonic clock: POSIX clock_gettime
11993:X 09 Dec 2021 17:58:29.829 * Running mode=sentinel, port=26381.
11993:X 09 Dec 2021 17:58:29.829 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
11993:X 09 Dec 2021 17:58:29.837 # Sentinel ID is b4f10d222071bf2c6fea379fae7c7e216cf3d813
11993:X 09 Dec 2021 17:58:29.837 # +monitor master mymaster 127.0.0.1 6379 quorum 2
11993:X 09 Dec 2021 17:58:29.838 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
11993:X 09 Dec 2021 17:58:29.844 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
11993:X 09 Dec 2021 17:58:31.024 * +sentinel sentinel e40c8e2820801fa1b679237672b87709fa1ca63b 127.0.0.1 26379 @ mymaster 127.0.0.1 6379
11993:X 09 Dec 2021 17:58:37.082 * +sentinel sentinel ddc2a2cb16b6ee0af3327c509d1dc72b8f5db277 127.0.0.1 26380 @ mymaster 127.0.0.1 6379
11993:X 09 Dec 2021 18:09:21.966 # +sdown master mymaster 127.0.0.1 6379
11993:X 09 Dec 2021 18:09:22.018 # +new-epoch 1
11993:X 09 Dec 2021 18:09:22.025 # +vote-for-leader ddc2a2cb16b6ee0af3327c509d1dc72b8f5db277 1
11993:X 09 Dec 2021 18:09:22.067 # +odown master mymaster 127.0.0.1 6379 #quorum 3/2
11993:X 09 Dec 2021 18:09:22.067 # Next failover delay: I will not start a failover before Thu Dec  9 18:15:22 2021
11993:X 09 Dec 2021 18:09:23.101 # +config-update-from sentinel ddc2a2cb16b6ee0af3327c509d1dc72b8f5db277 127.0.0.1 26380 @ mymaster 127.0.0.1 6379
11993:X 09 Dec 2021 18:09:23.101 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6380
11993:X 09 Dec 2021 18:09:23.102 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380
11993:X 09 Dec 2021 18:09:23.102 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380
11993:X 09 Dec 2021 18:09:53.125 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380

日志解析

我们发现在sentinel6379.log和sentinel6381.log中发现这两段日志

##### sentinel6379.log
# 标记127.0.0.1 6379为主观下线
11982:X 09 Dec 2021 18:09:21.927 # +sdown master mymaster 127.0.0.1 6379# 更新纪元(epoch)
11982:X 09 Dec 2021 18:09:22.018 # +new-epoch 1# 投票选举哨兵leader为ddc2a2cb16b6ee0af3327c509d1dc72b8f5db277
11982:X 09 Dec 2021 18:09:22.025 # +vote-for-leader ddc2a2cb16b6ee0af3327c509d1dc72b8f5db277 1# 标记127.0.0.1 6379为客观下线
11982:X 09 Dec 2021 18:09:23.044 # +odown master mymaster 127.0.0.1 6379 #quorum 3/211982:X 09 Dec 2021 18:09:23.044 # Next failover delay: I will not start a failover before Thu Dec  9 18:15:22 2021##### sentinel6381.log
# 标记127.0.0.1 6379为主观下线
11993:X 09 Dec 2021 18:09:21.966 # +sdown master mymaster 127.0.0.1 6379# 更新纪元(epoch)
11993:X 09 Dec 2021 18:09:22.018 # +new-epoch 1# 投票选举哨兵leader为ddc2a2cb16b6ee0af3327c509d1dc72b8f5db277
11993:X 09 Dec 2021 18:09:22.025 # +vote-for-leader ddc2a2cb16b6ee0af3327c509d1dc72b8f5db277 1# 标记127.0.0.1 6379为客观下线
11993:X 09 Dec 2021 18:09:22.067 # +odown master mymaster 127.0.0.1 6379 #quorum 3/2
11993:X 09 Dec 2021 18:09:22.067 # Next failover delay: I will not start a failover before Thu Dec  9 18:15:22 2021##### sentinel6380.log
# 升级slave6380为主服务器
12011:X 09 Dec 2021 18:09:23.026 # +promoted-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
# 进行故障切换
12011:X 09 Dec 2021 18:09:23.026 # +failover-state-reconf-slaves master mymaster 127.0.0.1 6379
# 通知6381重新绑定6380
12011:X 09 Dec 2021 18:09:23.101 * +slave-reconf-sent slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
12011:X 09 Dec 2021 18:09:24.069 * +slave-reconf-inprog slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
12011:X 09 Dec 2021 18:09:24.069 * +slave-reconf-done slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
12011:X 09 Dec 2021 18:09:24.127 # +failover-end master mymaster 127.0.0.1 6379
12011:X 09 Dec 2021 18:09:24.127 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6380
12011:X 09 Dec 2021 18:09:24.128 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380
12011:X 09 Dec 2021 18:09:24.128 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380
12011:X 09 Dec 2021 18:09:54.145 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380

这样我们我们成功搭建了三台哨兵集群，可实现Redis的高可用，自动故障切换。

哨兵模式的优缺点

优点

1、哨兵集群，基于主从复制模式，所有主从配置的优点，它全有
2、主从可以切换，故障可以转移，系统的可用性会更好
3、哨兵模式就是主从模式的升级，手动到自动，更加健壮

缺点

1、Redis不好在线扩容，集群容量一旦达到上限，在线扩容就十分麻烦
2、哨兵模式配置麻烦

尾言

本文为款神说Redis学习笔记
学习地址：https://www.bilibili.com/video/BV1S54y1R7SB?p=34

鸣谢参考：
https://www.cnblogs.com/kevingrace/p/9004460.html
https://blog.csdn.net/qq_43338943/article/details/115169965

上一篇：https://blog.csdn.net/qq_33631756/article/details/121898925