NoSQL 之Redis哨兵

目录

一、Redis 哨兵模式概述

（一）背景与核心目标

（二）基本架构组成

（三）核心功能

二、哨兵模式实现原理

（一）配置关键参数

（二）哨兵节点的定时任务

（三）主节点故障判定与故障转移

三、基础环境准备

（一）实验环境规划

（二）环境初始化操作（所有节点执行）

四、部署 Redis 主从集群

（一）安装 Redis 服务（主节点、从节点操作相同）

（二）编写 Redis 服务脚本（主节点、从节点操作相同）

（三）配置主节点（master）

（四）配置从节点（slave01、slave02）

1. slave01 节点配置

2. slave02 节点配置

（五）验证主从复制状态

五、部署哨兵节点集群

（一）安装与配置哨兵节点（以 sentinel01 为例，sentinel02、sentinel03 操作相同）

（二）编写哨兵服务脚本

（三）启动哨兵节点

（四）验证哨兵状态（以 sentinel01 为例）

六、故障转移实战演练

（一）模拟主节点故障

（二）观察哨兵自动故障转移过程

（三）验证新主从集群状态

（四）旧主节点恢复后状态

（五）故障转移原理总结

七、哨兵模式关键参数调优

（一）核心配置参数说明

（二）参数调优场景

八、哨兵模式监控与维护

（一）常用监控命令

（二）日志分析

（三）日常维护操作

九、哨兵模式优缺点与适用场景

（一）核心优势

（二）局限性

（三）适用场景

---

一、Redis 哨兵模式概述

（一）背景与核心目标

在分布式系统中，Redis 作为高性能键值存储中间件，其可用性至关重要。单节点 Redis 存在单点故障风险，一旦宕机将导致缓存层失效，甚至引发级联故障。为解决这一问题，Redis 引入哨兵模式（Sentinel），通过轻量级的监控与自动故障转移机制，保障 Redis 服务的高可用性。

（二）基本架构组成

哨兵模式的最基础架构由两部分组成：

1. 哨兵节点（Sentinel）：特殊的 Redis 节点，不存储数据，主要负责监控主从节点的运行状态，并在主节点故障时自动执行故障转移。为确保高可用，通常部署多个哨兵节点（如 S1、S2、S3）共同工作。
2. 数据节点：包括主节点（M）和从节点（R），用于存储 Redis 数据。主节点提供读写服务，从节点用于数据备份和读写分离。

（三）核心功能

1. 监控（Monitoring）：持续监控主节点和从节点是否正常运行。
2. 自动故障转移（Automatic Failover）：当主节点故障时，自动将一个从节点提升为新的主节点，并重新配置其他从节点指向新主节点。

二、哨兵模式实现原理

（一）配置关键参数

在哨兵节点的配置文件中，需添加以下核心配置：

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

• <master-name>：主节点的名称（自定义，如 “master”）。
• <ip>：主节点的 IP 地址。
• <port>：主节点的端口号（默认 6379）。
• <quorum>：执行故障恢复操作前至少需要同意的哨兵节点数。例如，设置为 2 表示至少 2 个哨兵节点认为主节点故障时，才会触发故障转移。

（二）哨兵节点的定时任务

哨兵节点启动后，会与监控的主节点建立连接，并定时执行以下 3 个核心任务：

1. 每 10 秒发送 info 命令：向主节点和从节点发送info命令，获取主从节点的状态信息（如从节点列表、复制偏移量等）。通过解析主节点返回的info replication结果，哨兵可获取从节点的 IP 和端口，进而与从节点建立连接。
2. 每 2 秒发送自身信息：通过主节点和从节点的publish/subscribe机制，向其他哨兵节点发送自身信息（如 IP、端口、运行状态等），实现哨兵节点之间的自动发现与信息同步。其他哨兵节点收到信息后，若判断为新哨兵，会将其加入已发现列表并建立连接。
3. 每 1 秒发送 ping 命令：向主节点、从节点和其他哨兵节点发送ping命令，检测节点是否可达。若目标节点在指定时间（down-after-milliseconds，默认 30 秒）内未响应，哨兵节点会将其标记为 “主观下线（SDOWN，Subjective Down）”。

（三）主节点故障判定与故障转移

1. 主观下线（SDOWN）：单个哨兵节点检测到主节点未响应ping命令，且超时时间达到阈值，认为主节点主观下线。
2. 客观下线（ODOWN，Objective Down）：当判断主节点主观下线的哨兵节点数达到quorum值时，哨兵系统认为主节点客观下线（仅主节点有此概念，从节点和哨兵节点故障仅标记为 SDOWN）。此时，哨兵节点进入故障转移流程。
3. 选举领导者哨兵节点：采用 Raft 算法选举领导者哨兵，负责执行故障转移操作，确保同一时间仅有一个哨兵执行操作。选举流程如下：
   • 发现主节点客观下线的哨兵节点（节点 A）向其他哨兵发送请求，请求选举自己为领导者。
   • 其他哨兵节点若未投票给其他节点，会同意节点 A 的请求。
   • 当节点 A 获得超过半数（且≥quorum）的选票时，成为领导者；若选举失败（如多个哨兵同时参选导致选票分散），等待随机时间后重新选举。
4. 故障转移操作步骤：
   • 挑选新主节点：领导者哨兵从从节点中按以下规则筛选：
     • 过滤掉不健康（主观下线或连接超时）的从节点。
     • 选择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	从节点

（二）环境初始化操作（所有节点执行）

1. 关闭防火墙：

systemctl stop firewalld  # 停止防火墙
systemctl disable firewalld  # 禁止开机启动

1. 关闭内核安全机制（SELinux）：

setenforce 0  # 临时关闭
sed -i "s/^SELINUX=.*/SELINUX=disabled/g" /etc/selinux/config  # 永久关闭（需重启生效）

1. 修改主机名：

• 哨兵节点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 服务（主节点、从节点操作相同）

1. 安装依赖工具：

yum -y install gcc gcc-c++ make

1. 下载并解压 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/

1. 编译并安装 Redis：

make && make PREFIX=/usr/local/redis install  # 编译并安装到/usr/local/redis目录

1. 创建配置文件目录：

mkdir /etc/redis

1. 复制默认配置文件：

cp /usr/src/redis-6.2.4/redis.conf /etc/redis/6379.conf  # 使用默认端口6379

1. 创建软链接（方便命令行调用）：

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）

1. 修改配置文件：

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保持默认即可。

1. 启动 Redis 服务：

systemctl daemon-reload  # 重新加载服务配置
systemctl start redis  # 启动服务
systemctl enable redis  # 设置开机自启

1. 验证端口监听：

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，主从复制配置同上。

（五）验证主从复制状态

1. 主节点验证：

redis-cli  # 进入Redis命令行
127.0.0.1:6379> info replication

输出应显示：

• role:master（主节点角色）。
• connected_slaves:2（两个从节点连接），并列出从节点的 IP 和状态。

1. 从节点验证（以 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 操作相同）

1. 安装 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，使用默认路径）

1. 创建配置文件目录：

mkdir /etc/redis

1. 复制 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 为例）

1. 进入 Redis 命令行：

redis-cli -p 6379  # 哨兵默认端口6379

1. 查看哨兵信息：

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（三个哨兵节点已发现彼此）。

六、故障转移实战演练

（一）模拟主节点故障

1. 停止主节点 Redis 服务：

systemctl stop redis  # 在master节点执行

（二）观察哨兵自动故障转移过程

1. 等待片刻后，查看哨兵状态（在 sentinel01 节点执行）：

redis-cli -p 6379
127.0.0.1:6379> info sentinel

• 若主节点已切换，输出中的address应变为新主节点的 IP（如 slave02 的 IP192.168.207.169）。
• status=ok表示新主节点已正常运行。

（三）验证新主从集群状态

1. 新主节点验证（假设 slave02 被提升为主节点）：

redis-cli -h 192.168.207.169 -p 6379
192.168.207.169:6379> info replication

输出应显示role:master，且connected_slaves包含原 slave01 和旧主

（四）旧主节点恢复后状态

1. 启动旧主节点（master）的 Redis 服务：

systemctl start redis

1. 验证旧主节点角色：

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），表明旧主节点恢复后自动成为新主节点的从节点，重新加入集群。

（五）故障转移原理总结

1. 哨兵节点协作流程：
   • 主节点故障后，哨兵通过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配置一致	需在所有哨兵和从节点配置，确保连接认证通过

（二）参数调优场景

1. 网络延迟较高的环境：
   • 增大down-after-milliseconds（如设为 50000ms），减少因短暂网络波动导致的误判。
   • 降低parallel-syncs（如设为 1），避免多从节点同时同步加剧网络压力。
2. 高并发业务场景：
   • 增加哨兵节点数（如 5 个），提高quorum值（如 3），增强故障判定的可靠性。
   • 调整failover-timeout为更短时间（如 60000ms），加快故障恢复速度，减少业务影响时长。
3. 混合云或跨机房部署：
   • 为不同机房的哨兵节点设置独立的quorum阈值（通过多monitor配置），避免跨机房网络故障导致的误判。
   • 使用bind参数限制哨兵节点仅监听本机 IP，结合防火墙规则保障跨机房通信安全。

八、哨兵模式监控与维护

（一）常用监控命令

1. 查看哨兵状态：

redis-cli -p 6379 info sentinel

重点关注：

• sentinel_masters：监控的主节点数量。
• master_<master-name>_status：主节点状态（ok/fail）。
• master_<master-name>_slaves：从节点列表及状态。
• master_<master-name>_sentinels：哨兵节点列表及状态。

1. 查看主从复制详情：

redis-cli info replication

主节点关注connected_slaves数量及从节点延迟（lag值应接近 0）；从节点关注master_link_status（up表示连接正常）和master_repl_offset（复制偏移量是否持续增长）。
3. 手动触发故障转移（测试用）：

redis-cli -p 6379 sentinel failover master

注意：此命令会强制触发主节点故障转移，仅用于测试，生产环境需谨慎操作。

（二）日志分析

1. 哨兵节点日志：
   • 路径：/var/log/redis_6379.log（根据配置文件logfile路径确定）。
   • 关键日志：
     • +sdown：标记节点主观下线。
     • +odown：标记主节点客观下线。
     • +election：触发哨兵选举流程。
     • +failover：开始执行故障转移。
     • +switch-master：主节点切换完成，显示新旧主节点信息。
2. 主从节点日志：
   • 关注SLAVEOF命令执行结果（如SLAVEOF NO ONE表示提升为主节点）、复制错误（如MASTER <-> SLAVE sync started表示开始同步数据）。

（三）日常维护操作

1. 添加新从节点：
   • 在新节点部署 Redis 服务，配置replicaof <master-ip> <master-port>，重启服务即可自动加入主从集群。
   • 哨兵节点会通过info replication命令自动发现新从节点，无需手动配置。
2. 替换故障哨兵节点：
   • 停止故障哨兵节点服务，在新节点重复哨兵部署步骤（使用相同配置文件）。
   • 其他哨兵节点会通过publish/subscribe机制自动发现新加入的哨兵节点，无需重启现有哨兵。
3. 升级 Redis 版本：
   • 主节点升级：
     1. 触发手动故障转移，将主节点切换为从节点。
     2. 停止旧主节点服务，升级 Redis 版本，重新配置为从节点（replicaof <new-master-ip> <port>）。
     3. 等待数据同步完成后，可再次通过故障转移将其提升为主节点（若需要）。
   • 从节点 / 哨兵节点升级：直接停止服务，升级版本后重启，自动恢复原有角色（需确保配置文件未修改）。

九、哨兵模式优缺点与适用场景

（一）核心优势

1. 高可用性保障：通过自动故障转移机制，实现主节点秒级切换，减少服务中断时间。
2. 分布式协作：多哨兵节点通过 Raft 算法达成共识，避免单点故障，提升监控可靠性。
3. 轻量级设计：哨兵节点不存储数据，资源占用低，可无缝集成到现有 Redis 主从架构中。
4. 配置简单：只需在哨兵节点配置monitor规则，无需修改主从节点配置，兼容性强。

（二）局限性

1. 无法解决数据丢失问题：若主节点未及时将数据同步到从节点，故障转移可能导致部分数据丢失（取决于repl-backlog-size和复制延迟）。
2. 脑裂风险：极端网络分区情况下，可能出现多个主节点并存，需通过合理设置quorum和down-after-milliseconds降低风险。
3. 运维复杂度：虽然部署简单，但多节点集群的监控、参数调优及故障排查需要一定的技术门槛。

（三）适用场景

1. 中小型业务集群：适用于对高可用性有要求，但无需超大规模数据分片的场景（如电商缓存、实时计数器等）。
2. 混合云架构：在云服务器与本地数据中心混合部署时，哨兵模式可作为轻量级高可用方案，保障跨环境的缓存服务稳定。
3. 读写分离场景：结合从节点实现读负载分担，哨兵自动维护主从关系，简化应用层路由逻辑。