目录
（一）安装与配置哨兵节点（以 sentinel01 为例，sentinel02、sentinel03 操作相同）
一、Redis 哨兵模式概述
（一）背景与核心目标
在分布式系统中，Redis 作为高性能键值存储中间件，其可用性至关重要。单节点 Redis 存在单点故障风险，一旦宕机将导致缓存层失效，甚至引发级联故障。为解决这一问题，Redis 引入哨兵模式（Sentinel），通过轻量级的监控与自动故障转移机制，保障 Redis 服务的高可用性。
（二）基本架构组成
哨兵模式的最基础架构由两部分组成：
- 哨兵节点（Sentinel）：特殊的 Redis 节点，不存储数据，主要负责监控主从节点的运行状态，并在主节点故障时自动执行故障转移。为确保高可用，通常部署多个哨兵节点（如 S1、S2、S3）共同工作。
- 数据节点：包括主节点（M）和从节点（R），用于存储 Redis 数据。主节点提供读写服务，从节点用于数据备份和读写分离。
（三）核心功能
- 监控（Monitoring）：持续监控主节点和从节点是否正常运行。
- 自动故障转移（Automatic Failover）：当主节点故障时，自动将一个从节点提升为新的主节点，并重新配置其他从节点指向新主节点。
二、哨兵模式实现原理
（一）配置关键参数
在哨兵节点的配置文件中，需添加以下核心配置：
sentinel monitor <master-name> <ip> <port> <quorum>
<master-name>：主节点的名称（自定义，如 “master”）。<ip>：主节点的 IP 地址。<port>：主节点的端口号（默认 6379）。<quorum>：执行故障恢复操作前至少需要同意的哨兵节点数。例如，设置为 2 表示至少 2 个哨兵节点认为主节点故障时，才会触发故障转移。
（二）哨兵节点的定时任务
哨兵节点启动后，会与监控的主节点建立连接，并定时执行以下 3 个核心任务：
- 每 10 秒发送 info 命令：向主节点和从节点发送
info命令，获取主从节点的状态信息（如从节点列表、复制偏移量等）。通过解析主节点返回的info replication结果，哨兵可获取从节点的 IP 和端口，进而与从节点建立连接。 - 每 2 秒发送自身信息：通过主节点和从节点的
publish/subscribe机制，向其他哨兵节点发送自身信息（如 IP、端口、运行状态等），实现哨兵节点之间的自动发现与信息同步。其他哨兵节点收到信息后，若判断为新哨兵，会将其加入已发现列表并建立连接。 - 每 1 秒发送 ping 命令：向主节点、从节点和其他哨兵节点发送
ping命令，检测节点是否可达。若目标节点在指定时间（down-after-milliseconds，默认 30 秒）内未响应，哨兵节点会将其标记为 “主观下线（SDOWN，Subjective Down）”。
（三）主节点故障判定与故障转移
- 主观下线（SDOWN）：单个哨兵节点检测到主节点未响应
ping命令，且超时时间达到阈值，认为主节点主观下线。 - 客观下线（ODOWN，Objective Down）：当判断主节点主观下线的哨兵节点数达到
quorum值时，哨兵系统认为主节点客观下线（仅主节点有此概念，从节点和哨兵节点故障仅标记为 SDOWN）。此时，哨兵节点进入故障转移流程。 - 选举领导者哨兵节点：采用 Raft 算法选举领导者哨兵，负责执行故障转移操作，确保同一时间仅有一个哨兵执行操作。选举流程如下：
- 发现主节点客观下线的哨兵节点（节点 A）向其他哨兵发送请求，请求选举自己为领导者。
- 其他哨兵节点若未投票给其他节点，会同意节点 A 的请求。
- 当节点 A 获得超过半数（且≥
quorum）的选票时，成为领导者；若选举失败（如多个哨兵同时参选导致选票分散），等待随机时间后重新选举。
- 故障转移操作步骤：
- 挑选新主节点：领导者哨兵从从节点中按以下规则筛选：
- 过滤掉不健康（主观下线或连接超时）的从节点。
- 选择
slave-priority（从节点优先级，默认 100，值越小优先级越高）最高的从节点。 - 若优先级相同，选择复制偏移量（
master_repl_offset，表示从节点复制主节点数据的进度）最大的从节点（数据最完整）。 - 若仍无法区分，选择
runid最小的从节点（runid是 Redis 节点启动时生成的唯一标识符）。
- 更新主从状态：
- 向选中的从节点发送
slaveof no one命令，将其提升为新主节点。 - 向其他从节点发送
slaveof <new-master-ip> <new-master-port>命令，使其成为新主节点的从节点。
- 向选中的从节点发送
- 处理旧主节点：将故障的旧主节点标记为新主节点的从节点，待其恢复后自动以从节点身份重新加入集群。
- 挑选新主节点：领导者哨兵从从节点中按以下规则筛选：
三、基础环境准备
（一）实验环境规划
| 操作系统 | 配置 | IP 地址 | 主机名 | 角色 |
|---|---|---|---|---|
| OpenEuler24 | 2C4G | 192.168.207.131 | sentinel01 | 哨兵节点 |
| OpenEuler24 | 2C4G | 192.168.207.165 | sentinel02 | 哨兵节点 |
| OpenEuler24 | 2C4G | 192.168.207.166 | sentinel03 | 哨兵节点 |
| OpenEuler24 | 2C4G | 192.168.207.167 | master | 主节点 |
| OpenEuler24 | 2C4G | 192.168.207.168 | slave01 | 从节点 |
| OpenEuler24 | 2C4G | 192.168.207.169 | slave02 | 从节点 |
（二）环境初始化操作（所有节点执行）
- 关闭防火墙：
systemctl stop firewalld # 停止防火墙
systemctl disable firewalld # 禁止开机启动
- 关闭内核安全机制（SELinux）：
setenforce 0 # 临时关闭
sed -i "s/^SELINUX=.*/SELINUX=disabled/g" /etc/selinux/config # 永久关闭（需重启生效）
- 修改主机名：
- 哨兵节点
sentinel01：
hostnamectl set-hostname sentinel01
- 哨兵节点
sentinel02：
hostnamectl set-hostname sentinel02
- 哨兵节点
sentinel03：
hostnamectl set-hostname sentinel03
- 主节点
master：
hostnamectl set-hostname master
- 从节点
slave01：
hostnamectl set-hostname slave01
- 从节点
slave02：
hostnamectl set-hostname slave02
修改完成后，重启系统使主机名生效：
reboot
四、部署 Redis 主从集群
（一）安装 Redis 服务（主节点、从节点操作相同）
- 安装依赖工具：
yum -y install gcc gcc-c++ make
- 下载并解压 Redis 源码：
wget http://download.redis.io/releases/redis-6.2.4.tar.gz # 若无法下载，可手动上传
tar -zxvf redis-6.2.4.tar.gz -C /usr/src/
cd /usr/src/redis-6.2.4/
- 编译并安装 Redis：
make && make PREFIX=/usr/local/redis install # 编译并安装到/usr/local/redis目录
- 创建配置文件目录：
mkdir /etc/redis
- 复制默认配置文件：
cp /usr/src/redis-6.2.4/redis.conf /etc/redis/6379.conf # 使用默认端口6379
- 创建软链接（方便命令行调用）：
ln -s /usr/local/redis/bin/* /usr/local/bin/
（二）编写 Redis 服务脚本（主节点、从节点操作相同）
cat > /etc/systemd/system/redis.service << EOF
[Unit]
Description=Redis
After=network.target
[Service]
Type=forking
ExecStart=/usr/local/redis/bin/redis-server /etc/redis/6379.conf
WantedBy=multi-user.target
[Install]
WantedBy=multi-user.target
EOF
（三）配置主节点（master）
- 修改配置文件：
vim /etc/redis/6379.conf
- 监听地址（第 75 行左右）：允许远程访问，添加服务器 IP：
bind 127.0.0.1 192.168.207.167
- 启用守护进程（第 257 行左右）：
daemonize yes
- 日志文件（添加，第 203 行左右）：
logfile "/var/log/redis_6379.log"
- 其他默认配置：端口
port 6379、PID 文件pidfile /var/run/redis_6379.pid、日志级别loglevel notice保持默认即可。
- 启动 Redis 服务：
systemctl daemon-reload # 重新加载服务配置
systemctl start redis # 启动服务
systemctl enable redis # 设置开机自启
- 验证端口监听：
netstat -anpt | grep 6379
输出应包含192.168.207.167:6379的监听状态。
（四）配置从节点（slave01、slave02）
1. slave01 节点配置
- 修改配置文件：
vim /etc/redis/6379.conf
- 监听地址：
bind 127.0.0.1 192.168.207.168
- 启用守护进程：
daemonize yes
- 日志文件：
logfile "/var/log/redis_6379.log"
- 其他默认配置同上。
- 主从复制配置（在文件末尾添加）：
replicaof 192.168.207.167 6379 # Redis 6.x及以上版本使用replicaof替代slaveof
- 启动服务：
systemctl daemon-reload
systemctl start redis
systemctl enable redis
- 验证端口监听：
netstat -anpt | grep 6379
2. slave02 节点配置
与 slave01 操作一致，仅需将监听地址改为192.168.207.169，主从复制配置同上。
（五）验证主从复制状态
- 主节点验证：
redis-cli # 进入Redis命令行
127.0.0.1:6379> info replication
输出应显示：
role:master（主节点角色）。connected_slaves:2（两个从节点连接），并列出从节点的 IP 和状态。
- 从节点验证（以 slave01 为例）：
redis-cli
127.0.0.1:6379> info replication
输出应显示：
role:slave（从节点角色）。master_host:192.168.207.167（主节点 IP）。master_link_status:up（连接状态正常）。
五、部署哨兵节点集群
（一）安装与配置哨兵节点（以 sentinel01 为例，sentinel02、sentinel03 操作相同）
- 安装 Redis（哨兵节点本质是特殊的 Redis 节点）：
yum -y install gcc gcc-c++ make # 若已安装可跳过
tar -zxvf redis-6.2.4.tar.gz -C /usr/src/
cd /usr/src/redis-6.2.4/
make && make install # 编译安装（无需指定PREFIX，使用默认路径）
- 创建配置文件目录：
mkdir /etc/redis
- 复制 Redis 配置文件并修改为哨兵配置：
cp /usr/src/redis-6.2.4/sentinel.conf /etc/redis/6379.conf # 哨兵默认端口6379
vim /etc/redis/6379.conf
- 关键配置修改：
- 监听地址（第 75 行左右）：允许所有 IP 访问（哨兵节点需相互通信）：
bind 0.0.0.0
- 启用守护进程（第 257 行左右）：
daemonize yes
- 哨兵监控配置（在文件末尾添加）：
sentinel monitor master 192.168.207.167 6379 2 # 监控主节点，quorum=2
sentinel down-after-milliseconds master 30000 # 主节点超时时间30秒（默认值，可省略）
sentinel parallel-syncs master 1 # 故障转移时，从节点同步新主节点数据的并行数（默认1）
sentinel failover-timeout master 180000 # 故障转移超时时间180秒（默认值，可省略）
（二）编写哨兵服务脚本
cat > /etc/systemd/system/redis.service << EOF
[Unit]
Description=Redis Sentinel
After=network.target
[Service]
Type=forking
ExecStart=/usr/local/bin/redis-sentinel /etc/redis/6379.conf
WantedBy=multi-user.target
[Install]
WantedBy=multi-user.target
EOF
（三）启动哨兵节点
systemctl daemon-reload # 重新加载服务配置
systemctl start redis # 启动哨兵服务
systemctl enable redis # 设置开机自启
（四）验证哨兵状态（以 sentinel01 为例）
- 进入 Redis 命令行：
redis-cli -p 6379 # 哨兵默认端口6379
- 查看哨兵信息：
127.0.0.1:6379> info sentinel
输出应包含：
sentinel_masters:1（监控 1 个主节点）。master:name=master, status=ok, address=192.168.207.167:6379（主节点状态正常）。slaves=2（两个从节点）。sentinels=3（三个哨兵节点已发现彼此）。
六、故障转移实战演练
（一）模拟主节点故障
- 停止主节点 Redis 服务：
systemctl stop redis # 在master节点执行
（二）观察哨兵自动故障转移过程
- 等待片刻后，查看哨兵状态（在 sentinel01 节点执行）：
redis-cli -p 6379
127.0.0.1:6379> info sentinel
- 若主节点已切换，输出中的
address应变为新主节点的 IP（如 slave02 的 IP192.168.207.169）。 status=ok表示新主节点已正常运行。
（三）验证新主从集群状态
- 新主节点验证（假设 slave02 被提升为主节点）：
redis-cli -h 192.168.207.169 -p 6379
192.168.207.169:6379> info replication
输出应显示role:master，且connected_slaves包含原 slave01 和旧主
（四）旧主节点恢复后状态
- 启动旧主节点（master）的 Redis 服务：
systemctl start redis
- 验证旧主节点角色：
redis-cli -h 192.168.207.167 -p 6379
192.168.207.167:6379> info replication
- 输出应显示
role:slave，master_host指向新主节点 IP（如192.168.207.169），表明旧主节点恢复后自动成为新主节点的从节点，重新加入集群。
（五）故障转移原理总结
- 哨兵节点协作流程：
- 主节点故障后，哨兵通过
ping命令检测到主观下线，触发quorum投票机制确认客观下线。 - 基于 Raft 算法选举领导者哨兵，确保唯一执行故障转移的节点。
- 领导者哨兵按规则挑选新主节点，重新配置主从关系，保证数据一致性和服务可用性。
- 主节点故障后，哨兵通过
七、哨兵模式关键参数调优
（一）核心配置参数说明
| 参数名称 | 作用 | 推荐值 | 备注 |
|---|---|---|---|
sentinel monitor <master-name> <ip> <port> <quorum> |
配置哨兵监控的主节点及故障判定所需的最少哨兵数 | quorum通常设为哨兵节点数的一半 + 1（如 3 个哨兵时设为 2） |
确保多数派决策，避免脑裂 |
sentinel down-after-milliseconds <master-name> <ms> |
判定节点主观下线的超时时间 | 建议 10000-30000ms（10-30 秒） | 需根据网络延迟调整，过小易误判，过大延迟故障发现 |
sentinel parallel-syncs <master-name> <num> |
故障转移时，从节点同步新主节点数据的并行数量 | 1-2 | 数值越大，同步速度越快，但可能增加新主节点负载 |
sentinel failover-timeout <master-name> <ms> |
故障转移的最大超时时间 | 建议 180000ms（3 分钟） | 超过此时间未完成转移，视为失败，需人工干预 |
sentinel auth-pass <master-name> <password> |
主节点密码（若启用认证） | 与主节点requirepass配置一致 |
需在所有哨兵和从节点配置，确保连接认证通过 |
（二）参数调优场景
- 网络延迟较高的环境：
- 增大
down-after-milliseconds（如设为 50000ms），减少因短暂网络波动导致的误判。 - 降低
parallel-syncs（如设为 1），避免多从节点同时同步加剧网络压力。
- 增大
- 高并发业务场景：
- 增加哨兵节点数（如 5 个），提高
quorum值（如 3），增强故障判定的可靠性。 - 调整
failover-timeout为更短时间（如 60000ms），加快故障恢复速度，减少业务影响时长。
- 增加哨兵节点数（如 5 个），提高
- 混合云或跨机房部署：
- 为不同机房的哨兵节点设置独立的
quorum阈值（通过多monitor配置），避免跨机房网络故障导致的误判。 - 使用
bind参数限制哨兵节点仅监听本机 IP，结合防火墙规则保障跨机房通信安全。
- 为不同机房的哨兵节点设置独立的
八、哨兵模式监控与维护
（一）常用监控命令
- 查看哨兵状态：
redis-cli -p 6379 info sentinel
重点关注：
sentinel_masters：监控的主节点数量。master_<master-name>_status：主节点状态（ok/fail）。master_<master-name>_slaves：从节点列表及状态。master_<master-name>_sentinels：哨兵节点列表及状态。
- 查看主从复制详情：
redis-cli info replication
主节点关注connected_slaves数量及从节点延迟（lag值应接近 0）；从节点关注master_link_status（up表示连接正常）和master_repl_offset（复制偏移量是否持续增长）。
3. 手动触发故障转移（测试用）：
redis-cli -p 6379 sentinel failover master
注意：此命令会强制触发主节点故障转移，仅用于测试，生产环境需谨慎操作。
（二）日志分析
- 哨兵节点日志：
- 路径：
/var/log/redis_6379.log（根据配置文件logfile路径确定）。 - 关键日志：
+sdown：标记节点主观下线。+odown：标记主节点客观下线。+election：触发哨兵选举流程。+failover：开始执行故障转移。+switch-master：主节点切换完成，显示新旧主节点信息。
- 路径：
- 主从节点日志：
- 关注
SLAVEOF命令执行结果（如SLAVEOF NO ONE表示提升为主节点）、复制错误（如MASTER <-> SLAVE sync started表示开始同步数据）。
- 关注
（三）日常维护操作
- 添加新从节点：
- 在新节点部署 Redis 服务，配置
replicaof <master-ip> <master-port>，重启服务即可自动加入主从集群。 - 哨兵节点会通过
info replication命令自动发现新从节点，无需手动配置。
- 在新节点部署 Redis 服务，配置
- 替换故障哨兵节点：
- 停止故障哨兵节点服务，在新节点重复哨兵部署步骤（使用相同配置文件）。
- 其他哨兵节点会通过
publish/subscribe机制自动发现新加入的哨兵节点，无需重启现有哨兵。
- 升级 Redis 版本：
- 主节点升级：
- 触发手动故障转移，将主节点切换为从节点。
- 停止旧主节点服务，升级 Redis 版本，重新配置为从节点（
replicaof <new-master-ip> <port>）。 - 等待数据同步完成后，可再次通过故障转移将其提升为主节点（若需要）。
- 从节点 / 哨兵节点升级：直接停止服务，升级版本后重启，自动恢复原有角色（需确保配置文件未修改）。
- 主节点升级：
九、哨兵模式优缺点与适用场景
（一）核心优势
- 高可用性保障：通过自动故障转移机制，实现主节点秒级切换，减少服务中断时间。
- 分布式协作：多哨兵节点通过 Raft 算法达成共识，避免单点故障，提升监控可靠性。
- 轻量级设计：哨兵节点不存储数据，资源占用低，可无缝集成到现有 Redis 主从架构中。
- 配置简单：只需在哨兵节点配置
monitor规则，无需修改主从节点配置，兼容性强。
（二）局限性
- 无法解决数据丢失问题：若主节点未及时将数据同步到从节点，故障转移可能导致部分数据丢失（取决于
repl-backlog-size和复制延迟）。 - 脑裂风险：极端网络分区情况下，可能出现多个主节点并存，需通过合理设置
quorum和down-after-milliseconds降低风险。 - 运维复杂度：虽然部署简单，但多节点集群的监控、参数调优及故障排查需要一定的技术门槛。
（三）适用场景
- 中小型业务集群：适用于对高可用性有要求，但无需超大规模数据分片的场景（如电商缓存、实时计数器等）。
- 混合云架构：在云服务器与本地数据中心混合部署时，哨兵模式可作为轻量级高可用方案，保障跨环境的缓存服务稳定。
- 读写分离场景：结合从节点实现读负载分担，哨兵自动维护主从关系，简化应用层路由逻辑。