Redis 哨兵模式的实现详解

高可用（HA）

所谓的高可用，也叫HA（High Availability），是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。如果在实际生产中，redis只部署一个节点，当机器故障时，整改服务都不能提供服务了。这就是我们常说的单点故障。如果redis部署了多台，当一台或几台故障时，整个系统依然可以对外提供服务，这样就提高了服务的可用性。

Redis的主从架构主要是为了提高并发量，主写从读。那么现在问题来了，现在Master机器挂掉了，其他机器都是Slave，没办法写，我们只能读缓存数据了。等下运维发现机子挂了，赶紧帮忙重启，那这段时间的写请求怎么办？手动解决响应是高延迟的一个操作啊。这么一说，你就会发现这样解决问题很蠢。所以Redis的哨兵机制就是为了解决这个愚蠢的问题。在Redis服务器集群出现问题时及时处理，及时进行故障转移（主备切换），减少系统不能提供服务的时间，这就是哨兵模式要解决的最重要的问题。

哨兵模式概述

哨兵模式是Redis的高可用方式，哨兵节点是特殊的redis服务，不提供读写服务，主要用来监控所有的redis节点。 哨兵架构下client端第一次从哨兵找出redis的主节点，后续就直接访问redis的主节点，不会每次都通过sentinel代理访问redis的主节点，当redis的主节点挂掉时，哨兵会第一时间感知到，并且在slave节点中重新选出来一个新的master，然后将新的master信息通知给client端，从而实现高可用。这里面redis的client端一般都实现了订阅功能，订阅sentinel发布的节点变动消息。

哨兵的搭建

伪集群 + 哨兵

下面将会搭建如下架构的哨兵集群

1. 复制sentinel.conf文件

将 Redis 安装目录中的 sentinel.conf 文件复制到 cluster 目录（该目录是上次搭建伪集群建立的一个目录）中。该配置文件中用于存放一些 sentinel 集群中的一些公共配置。

2. 修改sentinel.conf文件

修改 cluster/sentinel.conf 配置文件。

• sentinel monitor

  

  该配置用于指定 Sentinel 要监控的 master 是谁< ip >< redis-port >，并为 master 起了一个名字< master-name >。该名字在后面很多配置中都会使用。同时指定 Sentinel 集群中决定该master“客观下线状态”判断的 sentinel 数量 < quorum >。< quorum >的另一个用途与sentinel 的 Leader 选举有关。要求中至少要有 max(quorum, sentinelNum/2+1)个 sentinel 参与，选举才能进行。

  这里将该配置注释掉，因为要在后面的其它配置文件中设置，如果不注释就会出现配置冲突。

sentinel auth-pass

如果 Redis 主从集群中的主机设置了访问密码，那么该属性就需要指定 master 的主机名与访问密码。以方便 sentinel 监控 master。

3. 新建sentinel26380.conf

在 redis 目录下的 cluster 目录中新建 sentinel26380.conf 文件作为 Sentinel 的配置文件，并在其中键入如下内容：

include sentinel.conf
pidfile /var/run/sentinel_26380.pid
port 26380
sentinel monitor mymaster 192.168.11.10 6380 2
# 192.168.11.10是Redis服务器的IP地址
# logfile access26380.log

sentinel26380.conf文件保存退出后，在新建sentinel26381.conf和sentinel26382.conf这两个文件，文件内容就是上面的内容，只不过要把所有的26380改为26381和26382即可。最后结果如下：

4. 启动并关联Redis集群

详见：Redis的主从集群搭建与配置

5. 启动Sentinel集群

启动命令

在/usr/local/bin 目录下有一个命令 redis-sentinel 用于启动 Sentinel。不过，我们发现一个奇怪的现象：/usr/local/bin 目录中的 redis-sentinel 命令是 redis-server 命令的软链接。

查看 Redis 安装目录中的 src 目录中的 redis-server 与 redis-sentinel 命令，我们发现这两个命令的大小一模一样。其实，这两个命令本质上是同一个命令。

之所以可以启动不同的进程，主要是因为在启动时所加载的配置文件的不同。所以在启动 Sentinel 时，需要指定 sentinel.conf 配置文件。

• 两种启动方式

  Redis 首先会调用 checkForSentinelMode 函数来判断当前是否以哨兵模式来运行，并把标识赋值到 server.sentinel_mode。

  server.sentinel_mode = checkForSentinelMode(argc,argv);
  

  checkForSentinelMode 是如何判断当前是否以哨兵模式来运行：

  int checkForSentinelMode(int argc, char **argv) {
      int j;
      // 判断第一个参数是不是 redis-sentinel
      if (strstr(argv[0],"redis-sentinel") != NULL) return 1;
      // 判断其他的参数是不是 --sentinel
      for (j = 1; j < argc; j++)
          if (!strcmp(argv[j],"--sentinel")) return 1;
      return 0;
  }
  

  可以看出它是通过两个条件来判断的：

  这就对应了我们在命令行中启动哨兵实例的两种方式，一是直接运行 redis-sentinel 命令，另一种是运行 redis-server 命令并且参数中含有 --sentinel 参数。

  • 执行的命令是否为 redis-sentinel。
  • 命令参数中是否含有 --sentinel。
  • 方式一：使用 redis-sentinel 命令：redis-sentinel sentinel26380.conf
  • 方式二：使用 redis-server 命令：redis-server sentinel26380.conf --sentinel

这样Redist的哨兵集群就搭建完成了。

6. 查看 Sentinel 信息

运行中的 Sentinel 就是一个特殊 Redis，其也可以通过客户端连接，然后通过 info sentinel来查看当前连接的 Sentinel 的信息。

7. 查看 Sentinel 配置文件

查看端口号为26830的Sentinel的配置文件

哨兵优化配置

在公共的 sentinel.conf 文件中，还可以通过修改一些其它属性的值来达到对 Sentinel 的配置优化。

sentinel down-after-milliseconds

该选项指定了 Sentinel 认为服务器已经断线所需的毫秒数。如果服务器在给定的毫秒数之内， 没有返回 Sentinel 发送的 ping 命令的回复， 或者返回一个错误， 那么 Sentinel 将这个服务器标记为主观下线。

• sentinel parallel-syncs

  该选项指定了在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步， 这个数字越小， 完成故障转移所需的时间就越长。

  如果从服务器被设置为允许使用过期数据集（参见对 redis.conf 文件中对 slave-serve-stale-data 选项的说明）， 那么你可能不希望所有从服务器都在同一时间向新的主服务器发送同步请求， 因为尽管复制过程的绝大部分步骤都不会阻塞从服务器， 但从服务器在载入主服务器发来的 RDB 文件时， 仍然会造成从服务器在一段时间内不能处理命令请求： 如果全部从服务器一起对新的主服务器进行同步， 那么就可能会造成所有从服务器在短时间内全部不可用的情况出现。

  你可以通过将这个值设为 1 来保证每次只有一个从服务器处于不能处理命令请求的状态。

sentinel failover-timeout

指定故障转移超时时间（单位毫秒），默认3分钟，被用于下面四种场景：

场景1：假设现在某个master节点宕机，并且现在有5个slave节点。Sentinel集群通过选举算法选择3号slave节点晋升为master，但是这个3号slave一直晋升master节点失败（故障转移失败），如果在3分钟之内这个3号slave还是无法晋升为master节点，那么Sentinel集群会重新选择一个slave节点去晋升为master节点。如果重新选择的节点在6分钟之内无法晋升为master，Sentinel集群再次重新选择一个slave节点，以此类推。

场景2：旧的master已经宕机，新master已经上任。新master在刚开始上任时，slave节点并不会同步新master的数据，从Sentinel检测到相关错误时开始计时，会强制salve同步新master节点的数据，这时slave要在3分钟之内，把原来旧master节点的数据换成新master节点的数据。

场景3：旧的master已经宕机，Sentinel集群准备选择一个slave节点晋升为master节点。此时晋升master节点的命令已发出，但是在较短的时间内还没有产生任何配置信息的变化，就在这时Sentinel集群突然决定撤销这个slave晋升为新master，取消这个故障转移的时间为3分钟。

场景4：在进行故障转移时，所有slave节点同步新的master节点的数据所需的最大时间（3分钟）。如果同步时间超过了3分钟，那么sentinel parallel-syncs配置设置的值可能会无效，Sentinel会让更多的slave同时去同步新master节点的数据。

sentinel deny-scripts-reconfig

指定是否可以通过命令 sentinel set 动态修改 notification-script 与 client-reconfig-script 两个脚本。默认是不能的（设置为yes）。这两个脚本如果允许动态修改，可能会引发安全问题。

动态修改配置

通过 redis-cli 连接上 Sentinel 后，通过 sentinel set 命令可动态修改配置信息。例如，上面的命令动态修改了 sentinel monitor 中的 quorum 的值。

下表是 sentinel set 命令支持的参数（共七个）：

• Sentinel 模式下的可用命令

  在Sentinel模式下，Redis服务器不能执行诸如SET、DBSIZE、EVAL等等这些命令，因为服务器根本没有在命令表中载入这些命令。PING、SENTINEL、INFO、SUBSCRIBE（订阅频道）、UNSUBSCRIBE（退订频道）、PSUBSCRIBE（订阅模式）和PUNSUBSCRIBE（退订模式）这七个命令就是客户端可以对Sentinel执行的全部命令了。

到此这篇关于Redis 哨兵模式的实现详解的文章就介绍到这了,更多相关Redis请搜索服务器之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持服务器之家！

原文地址：https://blog.csdn.net/qq_54015483/article/details/130756519