---

前言

虽然有了Reids 的主从模式，但是我们发现它的故障转移能力非常弱，所以在主从模式的基础之上有衍生出了哨兵模式。

---

一、哨兵模式介绍：

1.1 介绍：

基于主从方案的缺点还是很明显的，假设 Master 宕机，那么就不能写入数据，那么 Slave 也就失去了作用，整个架构就不可用了，除非你手动切换，主要原因就是因为没有自动故障转移机制。

而哨兵（sentinel）的功能比单纯的主从架构全面的多了，哨兵模式是一种特殊的模式，首先 Redis 提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它独立运行。其原理是哨兵通过发送命令，等待 Redis 服务器响应，从而监控运行的多个 Redis 实例。因此哨兵模式具备了自动故障转移、集群监控、消息通知等功能。

1.2 工作机制：

哨兵可以同时监视多个主从服务器，并且在被监视的 Master 下线时，自动将某个 Slave 提升为 Master，然后由新的 Master 继续接收命令。整个过程如下：

• 初始化 sentinel，将普通的 redis 代码替换成 sentinel 专用代码
• 初始化 Masters 字典和服务器信息，服务器信息主要保存 ip:port，并记录实例的地址和 ID
• 创建和 Master 的两个连接，命令连接和订阅连接，并且订阅 sentinel:hello 频道
• 每隔 10 秒向 Master 发送 info 命令，获取 Master 和它下面所有 Slave 的当前信息
  当发现 Master 有新的 Slave 之后，sentinel 和新的 Slave同样建立两个连接，同时每个10秒发送 info 命令，更新 Master 信息
• sentinel 每隔1秒向所有服务器发送 ping 命令，如果某台服务器在配置的响应时间内连续返回无效回复，将会被标记为下线状态
• 选举出领头 sentinel，领头 sentinel 需要半数以上的 sentinel 同意
  领 头sentinel 从已下线的的 Master 所有 Slave 中挑选一个，将其转换为 Master
• 让所有的 Slave 改为从新的 Master 复制数据
• 将原来的 Master 设置为新的 Master 的从服务器，当原来 Master 重新回复连接时，就变成了新 Master 的从服务器
• 其中，sentinel 会每隔 1 秒向所有实例（包括主从服务器和其他sentinel）发送 ping 命令，并且根据回复判断是否已经下线，这种方式叫做主观下线。当判断为主观下线时，就会向其他监视的 sentinel 询问，如果超过半数的投票认为已经是下线状态，则会标记为客观下线状态，同时触发故障转移。

二、哨兵模式搭建：

哨兵模式依赖于redis 的主从模式，是在主从模式的基础之上，在部署setinel 集群服务 对所有的redis 节点进行监控（包括主节点和从节点）

2. 1 redis 主从搭建：

搭建过程可以参考：集群部署篇–Redis 主从模式

2.2 setinel 集群搭建：

Sentinel是Redis的一部分，因此它包含在标准的Redis镜像中，所有安装时只需要用到 redis 镜像；

2.2.1 配置： sentinel.conf ：

# mymaster：自定义集群名，2:投票数量必须2个sentinel才能判断主节点是否失败
sentinel monitor mymaster 192.168.75.128 6379 1
# 指的是超过5000秒，且没有回复，则判定主节点不可达
sentinel down-after-milliseconds mymaster 5000
# 故障转移超时时间
sentinel failover-timeout mymaster 60000
# 表示在故障转移的时候最多有numslaves在同步更新新的master
sentinel parallel-syncs mymaster 1
# sentinel  连接redis 的密码
sentinel auth-pass mymaster 123456

参数解释：
1.1 ）sentinel monitor
在Redis Sentinel配置中，sentinel monitor是一个非常重要的指令。它用于定义哨兵要监控的Redis主服务器(master)。这个指令会让哨兵知道主服务器的IP地址、端口以及对该主服务器进行标识的名称，并且指定了启动故障迁移的最少投票数。

sentinel monitor指令的语法如下：

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

其中：

• <master-name>: 是一个自定义名称，用于哨兵之间识别和标识主服务器的逻辑名字。
• <ip>: 主服务器的IP地址。
• <port>: 主服务器监听的端口。
• <quorum>: 最小投票数，它是哨兵在认为主服务器已经不可达并启动自动故障迁移之前需要达到的最小哨兵同意数。例如，如果设置为2，则至少需要两个哨兵同意主服务器无法访问。

这里有一个具体的示例配置：

sentinel monitor mymaster 127.0.0.1 6379 2

在这个例子中，哨兵将监控运行在127.0.0.1（本地）和6379端口上的Redis服务器，该服务器被命名为mymaster。如果有至少两个哨兵认为mymaster不可达，那么哨兵集群将开始故障迁移的过程。

在部署Sentinel时，通常会充分分散Sentinel节点，并且部署数量要多于你设置的<quorum>值，以形成一个健壮的监控系统，并避免任何两个Sentinel之间的网络分区问题导致错误的故障迁移。

要确保哨兵配置生效，需要在每个哨兵实例上设置相同的sentinel monitor配置。这样，每个哨兵都会监控同一个主服务器，并能共同决策是否需要进行故障迁移。

1.2） sentinel parallel-syncs
sentinel parallel-syncs 参数在 Redis Sentinel 配置文件 sentinel.conf 中用于控制在故障转移过程中可以同时与新的主服务器（promoted master）进行同步的从服务器（slaves）的数量。

当主服务器发生故障而 Sentinel 进行故障转移时，会有一个从服务器被提升为新的主服务器。其他的从服务器需要更新他们的配置以开始从新的主服务器复制数据。由于这个同步操作可能会比较耗时，parallel-syncs 设置决定了有多少个从服务器可以并行地开始同步过程。

配置项的语法如下：

sentinel parallel-syncs <master-name> <numslaves>

其中：

• <master-name> 是哨兵配置中用于标识被监控的主服务器逻辑名称。
• <numslaves> 是允许与新的主服务器同时进行同步的从服务器的最大数量。

举个例子：

sentinel parallel-syncs mymaster 1

在这个配置中，名为 mymaster 的主服务器在故障转移过程中，只允许一个从服务器与新的主服务器并行进行同步。如果有多个从服务器，它们将会依次同步，直到所有从服务器完成同步。如果你设置的数值更高，如 2 或 3，则两个或三个从服务器会被允许并行同步。

选择合适的 parallel-syncs 值需要权衡网络带宽、服务器性能和想要多快地恢复整个 Redis 系统的冗余性。如果你的系统可以同时处理多个从服务器进行同步所需的负载，则可以通过提高 parallel-syncs 的值来加快同步过程，反之亦然。如果设置过高，可能会给新的主服务器带来过多的同步负载，影响其性能。

1.3） sentinel failover-timeout
sentinel failover-timeout 是 Redis Sentinel 配置中控制故障转移超时的参数。这个配置项指定了哨兵在认定主服务器为失效状态、开始执行故障转移操作到操作完成所允许的最长时间。如果在超时时间内故障转移没有完成，哨兵将会取消当前的故障转移操作。

配置项的语法如下：

sentinel failover-timeout <master-name> <milliseconds>

其中：

• <master-name>：是哨兵配置中用于标识被监控的主服务器的逻辑名称。
• <milliseconds>：表示故障转移操作的超时时间，以毫秒为单位。

举例来说：

sentinel failover-timeout mymaster 30000

在上面这个例子中，对于名为 mymaster 的主服务器，哨兵设置了故障转移的超时时间为 30,000 毫秒（即 30 秒）。如果从检测到主服务器失效到完成故障转移（包括从服务器与新的主服务器之间的同步）的时间超过了30秒，哨兵将会放弃这次故障转移操作。

设置合理的 failover-timeout 值很重要，因为：

• 设定值太低可能导致在正常网络延迟或负载较高的情况下故障转移不能成功完成；
• 设定值太高会导致系统在主服务器失效时需要更长的时间来恢复。

默认情况下，Redis Sentinel 的 failover-timeout 设置可能是几分钟。这个值应该根据你的网络环境和主从服务器的同步时间来调整。需要注意的是，故障转移时间也会受到 parallel-syncs 配置的影响，因为它决定了从服务器同步数据的并行度。

2.2.2 运行容器：

docker run -d \
--name myrsentinel \
-p 26379:26379 \
--privileged=true \
-v /root/redis-sentinel/conf/sentinel.conf:/etc/sentinelRedis/sentinel.conf  \
redis \
redis-sentinel /etc/sentinelRedis/sentinel.conf 

重复以上步骤可以安装多个 sentinel ，多个sentinel 的集群名称相同，并且都连接到同一个 主库master ，他们之间会互相发现组成集群；

2.2.3 查看容器的信息：

连接容器

docker exec -it myrsentinel redis-cli -p 26379

通过 sentinel master mymaster 命令查看sentinel集群情况

可以看到 redis 的主库信息；已经 num-slaves 有2个从库 redis； num-other-sentinels：可以看到集群中共有2个sentinel 实例；

2.2.4 故障自动转移：

如果停掉redis 的主库，sentinel 会从slaver的redis 从库中选举出来一个主库，之前的主库会变成从库；

2.2.5 slave 晋升maser：

1）哨兵的选举：
当确定redis服务器确实挂了以后，哨兵要进行故障转移，并且只能有一个哨兵去完成该操作，所以这时候就要选举出一名哨兵来当此重任。
每个在线的哨兵节点都可以成为领导者，当它确认（比如哨兵3）主节点下线时，会向其它哨兵发is-master-down-by-addr命令，征求判断并要求将自己设置为领导者，由领导者处理故障转移；

当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者；

如果哨兵3发现自己在选举的票数大于等于num(sentinels)/2+1时，将成为领导者，如果没有超过，继续选举…………

2）slave 的晋升：
如果master被判下线了，大部分哨兵允许主备切换，那么需要选举一个slave，依次考虑如下：

• 看slave-priority：选择slave优先级最高的；

• 看offset：选择复制offset（偏移量）最大的，指复制最完整的从节点

• 看runid：程序id，就选runid最小的，越早开启的

2.2.6 原主节点重新启动：

因集群中已有了新主节点，所以在次启动，需要在配置文件中加入主节点信息，然后启动redis：

# 设置 主库ip 端口
slaveof 192.168.75.129 6379
# 设置从库访问主库 密码
masterauth 123456

---

总结：

哨兵模式是在redis 主从复制基础上，通过部署sentinel 服务来对整个redis 的主节点和从节点进行监控，当发现主节点下线，则选举出一个sentinel 然后 对监控下的所有slave 节点选举出来一个slave 将其晋升为新的master。

参考：

1 Redis系列：Redis主从、哨兵、集群介绍；
2 Redis — 三种模式：主从、哨兵、集群