Redis 7.x 系列【23】哨兵模式

有道无术，术尚可求，有术无道，止于术。

本系列Redis 版本 7.2.5

源码地址：https://gitee.com/pearl-organization/study-redis-demo

文章目录

• • 1. 概述
  • 2. 工作原理
  • • 2.1 监控
    • 2.2 标记下线
    • 2.3 哨兵领袖
    • 2.4 新的主节点
    • 2.5 通知更新
    • 3. 搭建演示
    • • 3.1 安装
      • 3.2 修改配置
      • 3.3 启动
      • 3.4 测试

        1. 概述

        官方文档

        主从复制模式常用于数据备份和读写分离，当主节点故障时，需要人工干预来处理主节点故障和从节点的升级，在实际应用中，可用性并不高。

        Redis 提供了基于哨兵（Sentinel）的高可用解决方案，Sentinel是一个运行在特殊模式下的 Redis 服务端，本身不存储任何数据，而是作为主从复制模式下的监控和管理工具。当主节点出现故障时，可以提供自动故障转移功能，从而保证 Redis 服务的连续性和稳定性。

        核心功能：

        • 监控：持续检查主节点和从节点实例是否按预期工作
        • 通知：可以通过 API 通知系统管理员或其他计算机程序，被监控的Redis实例出现问题
        • 自动故障转移：如果主节点未按预期工作，启动故障转移过程，将其中一个从节点被提升为主节点，其他的从节点重新配置使用新的主节点，并且通知在连接时使用的新地址
        • 配置中心：客户端通过连接哨兵来获得当前Redis服务的主节点地址

          2. 工作原理

          2.1 监控

          Redis Sentinel 在启动完成后，首先需要连接到到主从节点进行监控：

          

          在 Sentinel 配置文件中，首先需要配置主节点的地址，首次上线时，会根据该地址连接到主节点，并定期（通常是每1秒）向主节点发送 PING 命令来检查其状态。

          Sentinel 连接到主节点后，还会通过 INFO 命令获取所有从节点的地址信息，建立和从节点的连接，并同样采用心跳机制进行状态检查。

          多个 Sentinel 节点之间，也需要进行通信，会在主节点中建立一个 __sentinel__:hello 专用通道，利用发布订阅机制进行数据交互。可以使用可视化工具查看：

          

          2.2 标记下线

          当某个 Sentinel 节点发送 PING 命令后，主节点在规定的时间内没有响应，则会标记为主观下线（Subjectively Down）状态，其他 Sentinel 节点同样也会检测到主节点下线，并标记为主观下线。当主节点被足够数量的 Sentinel 节点都标记为 S_DOWN ，则标记为客观下线（Objectively Down）状态。

          在 sentinel monitor 配置项中，可以设置主节点被多少个 Sentinel 标记为 S_DOWN 时，则标记为O_Down：

          sentinel monitor mymaster 127.0.0.1 6379 2
          

          从主观下线到客观下线，需要多个哨兵达成一致意见，才能认为主节点客观上已经宕掉，这一步骤是为了防止单个 Sentinel 节点的误判。

          2.3 哨兵领袖

          当主节点被判定为客观下线后，哨兵节点之间会进行投票选举，以选出哨兵领袖（Leader Sentinel），负责后续的故障转移工作。

          整个选举过程基于 Raft 算法，当半数以上的哨兵投票通过后就认定该哨兵为哨兵领袖，所以一般将哨兵数量部署为单数，避免脑裂。

          2.4 新的主节点

          Leader Sentinel 会在从节点中，选择一个新的主节点，选择的标准一般有：

          • 响应速度，慢的就会被优先过滤掉，说明健壮性不够
          • 节点配置的优先级，优先级越高，越容易被选中
          • 数据偏移量，偏移量越大，说明数据复制的完整度越高
          • 节点创建时间，越早创建的节点，会优先选择（ 根据RunId 排序）

            选出新的主节点后，Leader Sentinel 会调用 REPLICAOF 命令将选出的新节点升级为主节点，其他的从节点更新配置信息，并连接到新的主节点，并确保和新主节点之间的数据同步。

            2.5 通知更新

            Leader Sentinel 通过发布订阅通知其他哨兵节点，还可以通过 API 或者脚本发送通知，报告集群的状态变化和故障情况。

            3. 搭建演示

            数据节点直接使用之前搭建的一主两从环境，在此基础上搭建三个哨兵节点，简要部署架构图如下：

            

            所有节点网络访问地址如下 ：

            • 主节点：192.168.56.101:6379
            • 从节点一：192.168.56.102:6379
            • 从节点二：192.168.56.103:6379
            • 哨兵节点一：192.168.56.104:26379
            • 哨兵节点二：192.168.56.105:26379
            • 哨兵节点三：192.168.56.106:26379

              3.1 安装

              Redis 7.x 系列【2】单机部署

              Redis 7.x 系列【21】主从复制

              Redis Sentinel也是一个特殊的 Redis 服务端，安装方法和普通的 Redis 一样，参考上面的文档，在三台哨兵服务器上安装即可。

              3.2 修改配置

              接下来需要修改所有哨兵节点的配置文件，首先从源码中将 sentinel.conf 配置文件复制到配置目录：

              [root@localhost /]# mkdir /etc/redis
              [root@localhost /]# cp ~/redis-7.2.5/sentinel.conf /etc/redis/
              [root@localhost bin]# vim sentinel.conf
              

              三个哨兵节点都需要修改配置，首先允许后台启动：

              daemonize yes
              

              配置当前监控的主节点的名称、IP、端口，以及进行故障转移的最少的投票数：

              sentinel monitor mymaster 192.168.56.101 6379 2
              

              如果主从节点设置了密码，还需要配置主节点名称、认证密码 （主从密码需要保持一致）：

              sentinel auth-pass mymaster 123456
              

              可以配置 Sentinel 节点的密码（其他哨兵节点的密码需要保持一致）：

              requirepass entinel123456
              

              3.3 启动

              这里直接使用命令启动，先启动所有主从复制节点，再启动所有哨兵节点：

              [root@localhost bin]# cd /usr/local/bin
              [root@localhost bin]# ./redis-sentinel /etc/redis/sentinel.conf
              

              3.4 测试

              使用 ./redis-cli 连接任一哨兵节点：

              [root@localhost bin]# ./redis-cli -p 26379
              127.0.0.1:26379> auth sentinel123456
              OK
              

              输入 info sentinel 查看所有哨兵信息，可以看到当前连接的主节点地址为 192.168.56.101:6379 ，以及从节点和哨兵节点的数量：

              127.0.0.1:26379> info sentinel
              # Sentinel
              sentinel_masters:1
              sentinel_tilt:0
              sentinel_tilt_since_seconds:-1
              sentinel_running_scripts:0
              sentinel_scripts_queue_length:0
              sentinel_simulate_failure_flags:0
              master0:name=mymaster,status=ok,address=192.168.56.101:6379,slaves=2,sentinels=3
              

              在主节点服务器上，直接 kill 掉主节点进程：

              [root@localhost bin]# ps -ef | grep redis
              root     16305     1  0 01:05 ?        00:00:29 ./redis-server *:6379
              root     19902 19252  0 11:18 pts/2    00:00:00 grep --color=auto redis
              [root@localhost bin]# kill 16305
              

              再次执行 info sentinel 命令，可以看到主节点地址变成了 192.168.56.102:6379 ，自动进行了故障转移，并选举了新的主节点（当之前下线的主节点重新连接后，会降级为从节点）：

              127.0.0.1:26379> info sentinel
              # Sentinel
              sentinel_masters:1
              sentinel_tilt:0
              sentinel_tilt_since_seconds:-1
              sentinel_running_scripts:0
              sentinel_scripts_queue_length:0
              sentinel_simulate_failure_flags:0
              master0:name=mymaster,status=ok,address=192.168.56.102:6379,slaves=3,sentinels=3
              

              查看 sentinel.conf 配置文件，可以看到自动更新了主节点：

              

              还会自动更新从节点 redis.conf 配置文件：