Linux Redis 运维实战：Redis 哨兵模式：实现高可用

戏说数据那点事 2025-07-16

238

Linux Redis 运维实战：Redis 哨兵模式：实现高可用

前言

在生产环境中，Redis 的高可用性是确保业务连续性的关键。主从复制提供了数据冗余和读写分离，但无法自动处理主节点故障。Redis 哨兵（Sentinel）模式通过监控主从节点、自动故障转移和主节点选举，实现了高可用架构。哨兵模式在 Linux 环境下的部署与运维涉及多节点配置、监控告警、故障恢复等复杂任务，对运维工程师提出了较高要求。

一、Redis 哨兵模式原理

1.1 哨兵模式的工作机制

Redis Sentinel 是一个独立的进程集合，负责监控 Redis 主从实例、检测故障、执行自动故障转移并通知客户端。其核心功能包括：

监控：定期检查主节点和从节点的健康状态（通过心跳机制）。
故障检测：通过多哨兵投票机制，判断主节点是否下线（客观下线）。
自动故障转移：

选举新的主节点（从从节点中选择）。
更新从节点配置，指向新主节点。
通知客户端更新连接。

配置管理：维护主从拓扑信息，动态更新配置。

1.2 哨兵模式的组件

哨兵节点：运行 redis-sentinel 进程，建议部署奇数个（如 3 或 5）以确保投票一致性。
主节点：处理写操作，同步数据到从节点。
从节点：处理读操作，作为主节点的备份。
客户端：通过哨兵获取当前主节点信息，动态调整连接。

1.3 关键概念

主观下线（SDOWN）：单个哨兵认为主节点不可用（心跳超时）。
客观下线（ODOWN）：多数哨兵达成一致，确认主节点故障。
故障转移：从节点升级为主节点，重新配置主从关系。
优先级（slave-priority）：影响从节点选举为新主节点的顺序。

1.4 运维视角的挑战

部署复杂性：多哨兵节点需协调一致，配置繁琐。
故障转移可靠性：需确保快速切换且数据一致。
监控与告警：实时监控哨兵状态、故障转移事件。
客户端适配：客户端需支持哨兵模式（如 Jedis、Lettuce）。

二、哨兵模式的部署与配置

2.1 环境准备

以下以 CentOS 8 为例，部署一主两从+三哨兵架构：

主节点：IP 192.168.1.100，端口 6379。
从节点 1：IP 192.168.1.101，端口 6379。
从节点 2：IP 192.168.1.102，端口 6379。
哨兵节点：IP 192.168.1.100、192.168.1.101、192.168.1.102，端口 26379。
前提：

Redis 7.0.12 已安装（参考专栏第 1 篇）。
主从复制已配置（参考专栏第 4 篇）。

防火墙允许 6379 和 26379 端口：

sudo firewall-cmd --permanent --add-port=6379/tcp
sudo firewall-cmd --permanent --add-port=26379/tcp
sudo firewall-cmd --reload

2.2 主从节点配置

主节点（192.168.1.100）配置文件 etc/redis/redis.conf：

bind 192.168.1.100
port 6379
requirepass your_secure_password
masterauth your_secure_password
dir var/redis/data/
logfile var/log/redis/redis.log
maxmemory 4gb
maxmemory-policy allkeys-lru
repl-backlog-size 10mb

从节点（192.168.1.101 和 192.168.1.102）配置类似，添加：

slaveof 192.168.1.100 6379
slave-read-only yes

启动主从节点：

sudo systemctl start redis

2.3 哨兵节点配置

在每个哨兵节点（192.168.1.100、192.168.1.101、192.168.1.102）创建配置文件 etc/redis/sentinel.conf：

port 26379
dir var/redis/sentinel/
logfile var/log/redis/sentinel.log
sentinel monitor mymaster 192.168.1.100 6379 2
sentinel auth-pass mymaster your_secure_password
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

关键参数：

sentinel monitor ：监控主节点，quorum=2 表示至少 2 个哨兵同意触发客观下线。
sentinel auth-pass：主节点密码。
down-after-milliseconds：主节点心跳超时时间（默认 30 秒）。
parallel-syncs：故障转移时同时同步的从节点数，建议为 1 以减少主节点压力。
failover-timeout：故障转移超时时间（默认 180 秒）。

2.4 启动哨兵节点

在每个哨兵节点上启动 Sentinel：

redis-sentinel etc/redis/sentinel.conf

或使用 systemd 管理，创建 etc/systemd/system/redis-sentinel.service：

[Unit]
Description=Redis Sentinel
After=network.target

[Service]
User=redis
Group=redis
ExecStart=/usr/local/bin/redis-sentinel etc/redis/sentinel.conf
ExecStop=/usr/local/bin/redis-cli -p 26379 shutdown
Restart=always

[Install]
WantedBy=multi-user.target

启用并启动：

sudo systemctl daemon-reload
sudo systemctl start redis-sentinel
sudo systemctl enable redis-sentinel

2.5 验证哨兵部署

检查哨兵状态：

redis-cli -h 192.168.1.100 -p 26379 INFO SENTINEL

输出示例：

master0:name=mymaster,status=ok,address=192.168.1.100:6379,slaves=2,sentinels=3

验证主从信息：
```
redis-cli -h 192.168.1.100 -p 26379 SENTINEL masters
```
输出主节点信息及从节点列表。
测试故障转移：

停止主节点：
```
sudo systemctl stop redis
```
观察哨兵日志（/var/log/redis/sentinel.log），确认从节点（如 192.168.1.101）被选举为主节点。
检查客户端连接，验证新主节点可用。

2.6 优化配置

哨兵节点数量：至少 3 个哨兵，分布在不同物理机，quorum 设置为 (n/2)+1。
心跳优化：根据网络延迟调整 down-after-milliseconds（如 10 秒）。

通知脚本：配置故障转移通知：

sentinel notification-script mymaster /usr/local/bin/notify.sh

示例脚本 notify.sh：

#!/bin/bash
echo "Sentinel event: $1 $2 $3 $4" >> /var/log/redis/notify.log
# 发送告警到邮件或企业微信

三、监控与告警

3.1 监控关键指标

使用 INFO SENTINEL 和 INFO REPLICATION 监控哨兵和主从状态：

哨兵节点：

sentinel_masters：监控的主节点数。
sentinel_sentinels：活跃哨兵数。
sentinel_slaves：从节点数。

主节点：

connected_slaves：连接的从节点数。

从节点：

master_link_status：主节点连接状态。

3.2 Prometheus + Redis Exporter

部署 Redis Exporter（包括哨兵）：

docker run -d --name redis-exporter -p 9121:9121 oliver006/redis_exporter \
  --redis.addr=redis://192.168.1.100:6379,redis://192.168.1.100:26379 \
  --redis.password=your_secure_password

Prometheus 配置：

scrape_configs:
  - job_name: 'redis-sentinel'
    static_configs:
      - targets: ['192.168.1.100:9121', '192.168.1.101:9121', '192.168.1.102:9121']

关键指标：

redis_sentinel_masters：哨兵监控的主节点数。
redis_sentinel_sentinels：活跃哨兵数。
redis_sentinel_failover_state：故障转移状态。

3.3 告警规则

Prometheus 告警规则示例：

groups:
- name: redis-sentinel
  rules:
  - alert: SentinelDown
    expr: redis_sentinel_sentinels < 3
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "Redis Sentinel {{ $labels.instance }} down"
  - alert: MasterFailover
    expr: redis_sentinel_failover_state != 0
    for: 1m
    labels:
      severity: warning
    annotations:
      summary: "Redis master failover triggered on {{ $labels.instance }}"

3.4 自动化监控脚本

Python 脚本示例：监控哨兵状态并发送告警。

import redis
import smtplib
from email.mime.text import MIMEText

s = redis.Redis(host='192.168.1.100', port=26379)
info = s.info('sentinel')
if info['sentinel_sentinels'] < 3:
    msg = MIMEText(f'Sentinel count dropped to {info["sentinel_sentinels"]}')
    msg['Subject'] = 'Redis Sentinel Alert'
    msg['From'] = 'admin@example.com'
    msg['To'] = 'ops@example.com'
    with smtplib.SMTP('smtp.example.com') as smtp:
        smtp.send_message(msg)

运维实践：

定期运行脚本（如 cron 每 5 分钟）。
结合 Grafana 可视化哨兵状态和故障转移事件。

四、故障排查与恢复

4.1 常见故障及排查

哨兵无法连接主节点：

检查哨兵日志：/var/log/redis/sentinel.log。
验证 sentinel auth-pass 配置。
测试网络：telnet 192.168.1.100 6379。

原因：主节点宕机、网络中断、密码错误。
排查：
解决：修复网络或重启主节点。

故障转移失败：

增加哨兵节点。
确保从节点健康，调整 slave-priority。

原因：哨兵数量不足（少于 quorum）、从节点不可用。
排查：检查 sentinel_sentinels 和 sentinel_slaves。
解决：

客户端连接异常：

原因：客户端未适配哨兵模式，故障转移后未更新主节点。
排查：检查客户端日志，确认是否通过哨兵获取主节点。
解决：使用支持哨兵的客户端（如 JedisSentinelPool）。

4.2 故障恢复

主节点宕机：

哨兵自动选举从节点（如 192.168.1.101）为主节点。

验证新主节点：

redis-cli -h 192.168.1.101 -a your_secure_password INFO REPLICATION

修复原主节点，重新加入作为从节点：

redis-cli -h 192.168.1.100 -a your_secure_password SLAVEOF 192.168.1.101 6379

哨兵节点宕机：

重启哨兵节点，检查日志确认重新加入集群。
若哨兵节点不可恢复，部署新哨兵节点并更新配置。

运维实践：

定期演练故障转移，确保切换时间 < 30 秒。
备份哨兵配置文件，记录主从拓扑。

五、运维案例：哨兵模式优化与故障恢复

5.1 场景描述

某 Redis 哨兵架构（一主两从，三哨兵，16GB 内存，Redis 7.0）在高峰期发生主节点宕机，故障转移耗时 45 秒，客户端连接中断 10%。

5.2 排查步骤

检查哨兵日志：

哨兵日志显示主节点（192.168.1.100）主观下线，触发客观下线。
故障转移耗时长，down-after-milliseconds 为 30 秒。

分析从节点：

从节点 192.168.1.101 选举为主，但同步延迟高（5MB）。
repl-backlog-size 仅 1MB，导致全量同步。

客户端问题：

部分客户端未通过哨兵获取新主节点，导致连接失败。

5.3 优化措施

调整哨兵参数：

降低 down-after-milliseconds：

sentinel down-after-milliseconds mymaster 10000

增大 repl-backlog-size：
```
repl-backlog-size 50mb
```

优化从节点：

提高从节点优先级（slave-priority 100）。
启用无盘复制：
```
repl-diskless-sync yes
```

客户端优化：

更新客户端为 JedisSentinelPool，支持动态主节点切换。

增强监控：

配置 Prometheus 告警，监控 redis_sentinel_failover_state。
添加 Grafana 仪表盘，展示故障转移时间。

5.4 优化结果

故障转移时间降至 15 秒。
客户端连接中断率降至 1%。
复制延迟降至 100KB，系统稳定性增强。

六、总结与展望

本篇讲解了 Redis 哨兵模式的原理、部署步骤、监控与告警、故障排查与恢复实践。哨兵模式通过自动故障转移显著提升了 Redis 的高可用性，运维工程师需掌握配置优化、监控部署和客户端适配技巧。

哨兵 redis

文章转载自戏说数据那点事，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

Linux Redis 运维实战：Redis 哨兵模式：实现高可用

Linux Redis 运维实战：Redis 哨兵模式：实现高可用

前言

一、Redis 哨兵模式原理

1.1 哨兵模式的工作机制

1.2 哨兵模式的组件

1.3 关键概念

1.4 运维视角的挑战

二、哨兵模式的部署与配置

2.1 环境准备

2.2 主从节点配置

2.3 哨兵节点配置

2.4 启动哨兵节点

2.5 验证哨兵部署

2.6 优化配置

三、监控与告警

3.1 监控关键指标

3.2 Prometheus + Redis Exporter

3.3 告警规则

3.4 自动化监控脚本

四、故障排查与恢复

4.1 常见故障及排查

4.2 故障恢复

五、运维案例：哨兵模式优化与故障恢复

5.1 场景描述

5.2 排查步骤

5.3 优化措施

5.4 优化结果

六、总结与展望

评论