构建高可用Redis：哨兵模式深度解析与Nacos微服务适配实践

文章目录

一、Redis哨兵模式介绍
- [1.1 哨兵模式的核心定义与实战架构](#1.1 哨兵模式的核心定义与实战架构)
- [1.2 哨兵模式的核心功能](#1.2 哨兵模式的核心功能)
- - [1.2.1 自动化故障转移](#1.2.1 自动化故障转移)
  - [1.2.2 分布式监控](#1.2.2 分布式监控)
  - [1.2.3 配置自动化管理](#1.2.3 配置自动化管理)
二、Redis哨兵模式安装与配置
- [2.1 集群规划](#2.1 集群规划)
- [2.2 安装并配置Redis](#2.2 安装并配置Redis)
- [2.3 Redis开启主从复制](#2.3 Redis开启主从复制)
- [2.4 Redis哨兵模式搭建](#2.4 Redis哨兵模式搭建)
- [2.5 Nacos配置Redis哨兵模式](#2.5 Nacos配置Redis哨兵模式)
三、Redis哨兵测试
- [3.1 测试一：测试哨兵模式](#3.1 测试一：测试哨兵模式)
- [3.2 测试二：微服务对接Redis哨兵模式适配性测试](#3.2 测试二：微服务对接Redis哨兵模式适配性测试)

一、Redis哨兵模式介绍

在Redis实战部署中，高可用是绕不开的核心需求------一旦Redis主节点故障，业务缓存中断、会话数据丢失等问题会直接冲击系统稳定性。哨兵模式（Sentinel Mode）作为Redis官方原生的高可用方案，正是为解决传统主从架构"主节点故障需人工介入"的痛点而生，它通过自动化监控、故障转移与配置管理，让Redis集群具备"自愈"能力。

1.1 哨兵模式的核心定义与实战架构

从实战角度理解，哨兵模式是由"哨兵节点集群"和"Redis数据节点集群"组成的分布式系统：

哨兵节点：独立于Redis数据存储的特殊进程，不存储业务数据，核心职责是监控主从节点状态、判断故障并触发转移；
数据节点：即普通Redis节点，遵循主从复制规则------主节点承接读写请求，从节点实时同步主节点数据，作为备份节点存在。

实战中最经典的架构是"1主2从+3个哨兵"：哨兵节点必须部署奇数个（3个或5个），目的是通过"投票共识"避免故障判断误判与"脑裂"问题。所有哨兵节点会与主从节点建立心跳连接，同时哨兵间也会相互通信，形成全量的集群状态视图------单哨兵节点故障不影响整体监控能力，确保高可用体系自身的可靠性。

1.2 哨兵模式的核心功能

哨兵模式的实战价值集中在三个核心功能上，这些功能直接解决了运维中的实际痛点：

1.2.1 自动化故障转移

故障判断：哨兵通过心跳检测（默认每1秒发送ping命令）发现主节点无响应时，先标记为"主观下线"；随后向其他哨兵发起确认请求，当超过预设比例（如3个哨兵中2个确认，即quorum=2）时，标记为"客观下线"，避免单哨兵误判；

自动切换：哨兵从健康从节点中，按"数据完整性（复制偏移量最大）→响应速度"原则筛选新主节点，自动执行"从节点升主""其余从节点改连新主""更新客户端连接信息"操作，整个过程通常10秒内完成，远超人工效率。

1.2.2 分布式监控

哨兵集群不仅监控主从节点存活状态，还会实时收集节点核心指标：内存使用率、连接数、复制延迟、命令执行耗时等。实战中，运维可通过info sentinel命令快速查看集群状态，提前发现"从节点复制延迟过高""主节点连接数突增"等潜在风险，避免故障扩大。

同时，哨兵间的信息同步机制，确保所有哨兵对集群状态的认知一致，为故障判断和转移提供可靠依据。

1.2.3 配置自动化管理

实战中Redis集群扩容或故障后，手动修改所有节点配置易出错。哨兵模式可自动完成：

新从节点加入时，哨兵自动识别并将其纳入监控，无需手动配置主从关系；
故障转移后，哨兵自动更新所有节点的redis.conf和sentinel.conf，确保配置一致性；
客户端通过哨兵提供的统一地址（如sentinel get-master-addr-by-name mymaster），可实时获取当前主节点信息，无需硬编码主节点IP，实现"无感切换"。

需要注意的是，哨兵模式依赖Redis主从复制机制：只有先搭建好稳定的主从架构（主从数据同步正常、从节点只读配置生效），哨兵才能正常工作。这是后续实战部署的基础，务必提前确认主从复制状态。

二、Redis哨兵模式安装与配置

2.1 集群规划

主机IP	Redis端口	哨兵端口
192.168.119.3（master节点）	12205	26379
192.168.119.5（slave1 节点）	12207	26380
192.168.119.6（slave2 节点）	12208	26381

2.2 安装并配置Redis

Redis的安装方式有很多，可以选择任意一种方式进行安装。本文选择使用apt进行安装：（不再过多讲解）

bash 复制代码

sudo apt install redis-server

sudo vim /etc/redis/redis.conf

# 绑定地址，0.0.0.0 表示允许所有 IP 访问
bind 0.0.0.0
# 端口号
port 12205 #注意修改
# 是否以守护进程运行
daemonize no
# 系统管理方式，使用 systemd
supervised systemd
# PID 文件位置
pidfile /data/redis/redis-server.pid
# 日志文件位置
logfile /data/redis/redis-server.log
# 数据文件存储目录
dir /data/redis
# 设置密码，可选配置
requirepass redispassword
# 开启AOF模式
appendonly yes

# 设置目录权限
sudo mkdir -p /data/redis
sudo chown -R redis:redis /data/redis
sudo chmod 755 /data/redis

sudo vim /lib/systemd/system/redis-server.service
[Service]
# 修改 PID 文件路径
PIDFile=/data/redis/redis-server.pid
# 移除 RuntimeDirectory
RuntimeDirectory=
# 修改可写路径
ReadWritePaths=-/data/redis


# 重新加载 systemd 配置
sudo systemctl daemon-reload
# 启动 Redis 服务
sudo systemctl start redis-server
# 设置开机自启
sudo systemctl enable redis-server
# 检查服务状态
sudo systemctl status redis-server

确认redis集群运行正常。

2.3 Redis开启主从复制

使用redis-cli连接入redis：

bash 复制代码

# slave节点编辑配置文件
vim /etc/redis/redis.conf 
# master 节点ip地址与端口
replicaof 192.168.119.3 12205
# master登陆redis密码
masterauth redispassword

重启redis：（这个部分也可以在redis上进行动态配置）

bash 复制代码

# 重启redis
systemctl restart redis-server

验证主从复制：

bash 复制代码

# 主节点登陆查看
127.0.0.1:12205> INFO replication 
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.119.6,port=12208,state=online,offset=168,lag=0
slave1:ip=192.168.119.5,port=12207,state=online,offset=168,lag=1
master_replid:4796a6810703684edf0525dd94fdbed51a7d08d2
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:168
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:168
127.0.0.1:12205>

2.4 Redis哨兵模式搭建

由于采用apt安装redis，缺少插件，安装redis-sentinel

bash 复制代码

apt install redis-sentinel
# 安装完成后会在/etc/redis下生成配置文件，编辑配置文件

编写主节点配置文件：

bash 复制代码

root@uat:~# vim /etc/redis/sentinel.conf 
bind 0.0.0.0
port 26379
daemonize yes
pidfile "/data/redis/sentinel/redis-sentinel.pid"
logfile "/data/redis/redis-sentinel.log"
dir "/data/redis"
sentinel myid c2bbd96d9a4db0d323b6bfdb1ed7dee8dab37af6
sentinel deny-scripts-reconfig yes
sentinel monitor mymaster 192.168.119.3 12205 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
# redis登陆密码
sentinel auth-pass mymaster redispassword
sentinel config-epoch mymaster 0
sentinel leader-epoch mymaster 0
protected-mode no
supervised systemd
user default on nopass ~* +@all
sentinel current-epoch 0

编写两个从节点的配置文件：

bash 复制代码

root@prod2:/data/redis# vim /etc/redis/sentinel.conf  
bind 0.0.0.0
port 26380
daemonize yes
pidfile "/data/redis/sentinel/redis-sentinel.pid"
logfile "/data/redis/redis-sentinel.log"
dir "/data/redis"
sentinel myid e0eff55dba850c4a37967f711b7c8ab1b7d05285
sentinel deny-scripts-reconfig yes
sentinel monitor mymaster 192.168.119.3 12205 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel auth-pass mymaster redispassword
sentinel config-epoch mymaster 0
sentinel leader-epoch mymaster 0
protected-mode no
supervised systemd
user default on nopass ~* +@all
sentinel current-epoch 0
root@prod2:/data/redis# 


root@prod3:/data/redis# vim /etc/redis/sentinel.conf  
bind 0.0.0.0
port 26381
daemonize yes
pidfile "/data/redis/sentinel/redis-sentinel.pid"
logfile "/data/redis/redis-sentinel.log"
dir "/data/redis"
sentinel myid 6e5dfe20e194b9d5a41ebcf96e6bef5b5d0e0101
sentinel deny-scripts-reconfig yes
sentinel monitor mymaster 192.168.119.3 12205 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel auth-pass mymaster redispassword
sentinel config-epoch mymaster 0
sentinel leader-epoch mymaster 0
protected-mode no
supervised systemd
user default on nopass ~* +@all
sentinel current-epoch 0
root@prod3:/data/redis#

启动哨兵模式：

bash 复制代码

# 所有节点均启动
redis-sentinel /etc/redis/sentinel.conf

验证哨兵模式：

哨兵模式运行成功。

2.5 Nacos配置Redis哨兵模式

编辑Nacos的applications.yml文件：

bash 复制代码

# 编辑application.yml的连接redis的部分
spring:
  data:
    redis:
      password: redispassword
      sentinel:
        master: mymaster
        nodes:
          - "192.168.119.3:26379"
          - "192.168.119.5:26380"
          - "192.168.119.6:26381"

发布配置：

发布配置。

重启一个服务进行测试：

连接成功，并且成功存放数据于redis中。

三、Redis哨兵测试

测试分为两项测试：

验证Redis集群在Master节点异常停止时的状态切换机制、数据一致性及自愈能力，确保核心存储组件的基础容错性。
验证使用Nacos注册发现的服务，在Redis集群发生主从切换时的适配能力，确保Redis底层存储波动不会影响注册到Nacos上的微服务正常运行。

3.1 测试一：测试哨兵模式

停止master的redis测试：

观察主节点日志输出：

bash 复制代码

root@uat:/resource# systemctl stop redis 
root@uat:/resource# 
root@uat:/resource# tail -f /data/redis/redis-sentinel.log 
29690:X 14 Nov 2025 13:08:35.714 # +new-epoch 1
29690:X 14 Nov 2025 13:08:35.717 # +vote-for-leader e0eff55dba850c4a37967f711b7c8ab1b7d05285 1
29690:X 14 Nov 2025 13:08:36.703 # +odown master mymaster 192.168.119.3 12205 #quorum 2/2
29690:X 14 Nov 2025 13:08:36.703 # Next failover delay: I will not start a failover before Fri Nov 14 13:10:36 2025
29690:X 14 Nov 2025 13:08:36.846 # +config-update-from sentinel e0eff55dba850c4a37967f711b7c8ab1b7d05285 192.168.119.5 26380 @ mymaster 192.168.119.3 12205
29690:X 14 Nov 2025 13:08:36.846 # +switch-master mymaster 192.168.119.3 12205 192.168.119.5 12207
29690:X 14 Nov 2025 13:08:36.846 * +slave slave 192.168.119.6:12208 192.168.119.6 12208 @ mymaster 192.168.119.5 12207
29690:X 14 Nov 2025 13:08:36.847 * +slave slave 192.168.119.3:12205 192.168.119.3 12205 @ mymaster 192.168.119.5 12207
29690:X 14 Nov 2025 13:08:41.887 # +sdown slave 192.168.119.3:12205 192.168.119.3 12205 @ mymaster 192.168.119.5 12207
29690:X 14 Nov 2025 13:08:41.887 # +sdown slave 192.168.119.6:12208 192.168.119.6 12208 @ mymaster 192.168.119.5 12207

观察从节点日志输出：

bash 复制代码

root@prod2:/data# tail -f /data/redis/redis-sentinel.log 
921731:X 14 Nov 2025 13:08:35.636 # +sdown master mymaster 192.168.119.3 12205
921731:X 14 Nov 2025 13:08:35.707 # +odown master mymaster 192.168.119.3 12205 #quorum 2/2
921731:X 14 Nov 2025 13:08:35.707 # +new-epoch 1
921731:X 14 Nov 2025 13:08:35.707 # +try-failover master mymaster 192.168.119.3 12205
921731:X 14 Nov 2025 13:08:35.711 # +vote-for-leader e0eff55dba850c4a37967f711b7c8ab1b7d05285 1
921731:X 14 Nov 2025 13:08:35.717 # c2bbd96d9a4db0d323b6bfdb1ed7dee8dab37af6 voted for e0eff55dba850c4a37967f711b7c8ab1b7d05285 1
921731:X 14 Nov 2025 13:08:35.777 # +elected-leader master mymaster 192.168.119.3 12205
921731:X 14 Nov 2025 13:08:35.778 # +failover-state-select-slave master mymaster 192.168.119.3 12205
921731:X 14 Nov 2025 13:08:35.868 # +selected-slave slave 192.168.119.5:12207 192.168.119.5 12207 @ mymaster 192.168.119.3 12205
921731:X 14 Nov 2025 13:08:35.868 * +failover-state-send-slaveof-noone slave 192.168.119.5:12207 192.168.119.5 12207 @ mymaster 192.168.119.3 12205
921731:X 14 Nov 2025 13:08:35.951 * +failover-state-wait-promotion slave 192.168.119.5:12207 192.168.119.5 12207 @ mymaster 192.168.119.3 12205
921731:X 14 Nov 2025 13:08:36.770 # +promoted-slave slave 192.168.119.5:12207 192.168.119.5 12207 @ mymaster 192.168.119.3 12205
921731:X 14 Nov 2025 13:08:36.770 # +failover-state-reconf-slaves master mymaster 192.168.119.3 12205
921731:X 14 Nov 2025 13:08:36.843 * +slave-reconf-sent slave 192.168.119.6:12208 192.168.119.6 12208 @ mymaster 192.168.119.3 12205
921731:X 14 Nov 2025 13:08:36.843 # +failover-end master mymaster 192.168.119.3 12205
921731:X 14 Nov 2025 13:08:36.843 # +switch-master mymaster 192.168.119.3 12205 192.168.119.5 12207
921731:X 14 Nov 2025 13:08:36.844 * +slave slave 192.168.119.6:12208 192.168.119.6 12208 @ mymaster 192.168.119.5 12207
921731:X 14 Nov 2025 13:08:36.844 * +slave slave 192.168.119.3:12205 192.168.119.3 12205 @ mymaster 192.168.119.5 12207
921731:X 14 Nov 2025 13:08:41.912 # +sdown slave 192.168.119.3:12205 192.168.119.3 12205 @ mymaster 192.168.119.5 12207
921731:X 14 Nov 2025 13:08:41.912 # +sdown slave 192.168.119.6:12208 192.168.119.6 12208 @ mymaster 192.168.119.5 12207
921731:X 14 Nov 2025 13:10:03.632 # -sdown slave 192.168.119.3:12205 192.168.119.3 12205 @ mymaster 192.168.119.5 12207

整个过程：

故障检测与共识达成 ：两个哨兵节点几乎同时检测到原主节点 192.168.119.3:12205不可用，并将其标记为主观下线 。随后，哨兵集群迅速达成共识，将其判定为客观下线，这是触发故障转移的前提条件。

领导者选举与从节点选择 ：哨兵集群通过内部选举机制，成功选举出了一个领导者哨兵来负责后续操作。该领导者根据预设规则，从健康的从节点中选出了 192.168.119.5:12207作为新的主节点。

故障转移执行 ：领导者哨兵向选定的从节点发送 SLAVEOF NO ONE命令，将其提升为新的主节点，并更新了其他从节点的复制目标，使其指向新的主节点。关键的 +switch-master事件标志着整个拓扑切换完成。

旧主节点处理 ：故障转移完成后，哨兵会持续监控旧主节点。当旧主节点恢复时，哨兵会将其标记为从节点，并准备在适当的时候将其重新纳入集群。

此时查看哨兵状态：

bash 复制代码

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

测试完整，Redis的master节点正常自动切换。

3.2 测试二：微服务对接Redis哨兵模式适配性测试

（从服务角度验证）

在Gateway正常使用的情况下，会从Nacos获取配置以及服务的路由，之后连接redis并将数据存放在redis中，从redis中寻找路由，停止redis的master节点进行测试：

bash 复制代码

systemctl stop redis

测试服务1：

测试服务2：

自动切换成功，代表集群运行正常，从服务角度验证更具说服力。

好啦，到这就完事儿啦，我还要再测试其他服务去了。