1. Redis哨兵机制深度解析
Redis哨兵(Sentinel)是Redis官方提供的高可用性解决方案,它本质上是一个分布式监控系统,由多个哨兵节点组成集群,共同监控主从Redis节点的健康状态。当主节点出现故障时,哨兵集群能够自动完成故障检测、主从切换和配置更新等一系列操作。
哨兵系统采用Raft算法实现分布式共识,确保多个哨兵节点对主节点状态的判断保持一致。每个哨兵节点会定期执行以下核心操作:
- 每10秒向主从节点发送INFO命令获取拓扑信息
- 每1秒向其他哨兵节点和Redis节点发送PING命令检测存活状态
- 每2秒通过发布/订阅频道与其他哨兵交换主节点状态判断
关键提示:生产环境必须部署至少3个哨兵节点,且分布在不同的物理服务器上。这是为了避免脑裂问题(Split-brain)——当网络分区发生时,奇数个节点能确保总能达成多数共识。
1.1 哨兵集群的典型架构设计
一个健壮的哨兵集群部署方案应该包含:
- 3个或以上哨兵节点(必须奇数个)
- 1个主Redis节点(master)
- 2个或以上从节点(slave)
这种配置下,即使单个哨兵节点或从节点故障,系统仍能保持高可用。当主节点宕机时,哨兵集群需要获得多数(quorum)投票才能执行故障转移。对于3个哨兵节点的集群,quorum通常设置为2。
2. 环境准备与节点规划
2.1 服务器资源配置建议
对于生产环境,建议采用以下配置:
- Redis节点:至少4核CPU,8GB内存,SSD存储
- 哨兵节点:可与Redis节点同机部署,但建议2核CPU,4GB内存
- 网络:节点间延迟应<5ms,带宽>100Mbps
示例部署方案(3台物理机):
code复制主机1: Redis主节点 + 哨兵1
主机2: Redis从节点1 + 哨兵2
主机3: Redis从节点2 + 哨兵3
2.2 系统参数调优
在/etc/sysctl.conf中添加:
bash复制# 避免swap影响性能
vm.swappiness = 1
# 增加TCP连接队列
net.core.somaxconn = 65535
# 加快故障检测
net.ipv4.tcp_keepalive_time = 60
执行sysctl -p生效后,还需设置用户限制:
bash复制echo "* soft nofile 65535" >> /etc/security/limits.conf
echo "* hard nofile 65535" >> /etc/security/limits.conf
3. Redis主从集群部署
3.1 编译安装Redis
建议使用最新稳定版(本文以7.0为例):
bash复制wget https://download.redis.io/releases/redis-7.0.0.tar.gz
tar xzf redis-7.0.0.tar.gz
cd redis-7.0.0
make BUILD_TLS=yes && make install
重要:生产环境务必启用TLS加密,编译时添加BUILD_TLS=yes参数。
3.2 主节点配置
创建/etc/redis/master.conf:
conf复制bind 0.0.0.0
port 6379
daemonize yes
pidfile /var/run/redis_6379.pid
logfile "/var/log/redis_6379.log"
dir /var/lib/redis/6379
requirepass your_strong_password
masterauth your_strong_password
appendonly yes
tls-port 6380
tls-cert-file /etc/redis/certs/redis.crt
tls-key-file /etc/redis/certs/redis.key
tls-ca-cert-file /etc/redis/certs/ca.crt
3.3 从节点配置
从节点配置与主节点类似,需额外添加:
conf复制replicaof <master-ip> 6379
replica-read-only yes
tls-replication yes
启动顺序建议:
- 先启动主节点
- 再逐个启动从节点
- 通过
redis-cli info replication验证主从状态
4. 哨兵集群部署实战
4.1 哨兵节点配置
每个哨兵节点的配置(如/etc/redis/sentinel1.conf):
conf复制port 26379
daemonize yes
logfile "/var/log/redis/sentinel1.log"
dir "/var/lib/redis/sentinel1"
sentinel monitor mymaster <master-ip> 6379 2
sentinel auth-pass mymaster your_strong_password
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
sentinel tls-port 26380
sentinel tls-cert-file /etc/redis/certs/redis.crt
sentinel tls-key-file /etc/redis/certs/redis.key
sentinel tls-ca-cert-file /etc/redis/certs/ca.crt
关键参数说明:
down-after-milliseconds: 判定节点不可用的超时时间(建议5-30秒)failover-timeout: 故障转移超时时间(通常1-5分钟)parallel-syncs: 故障转移后同时同步的从节点数(根据从节点数量调整)
4.2 启动与验证
逐个启动哨兵节点:
bash复制redis-sentinel /etc/redis/sentinel1.conf
验证集群状态:
bash复制redis-cli -p 26379 sentinel masters
redis-cli -p 26379 sentinel slaves mymaster
redis-cli -p 26379 sentinel sentinels mymaster
5. 高级配置与调优
5.1 网络分区处理策略
在哨兵配置中添加:
conf复制sentinel deny-scripts-reconfig yes
sentinel client-reconfig-script mymaster /path/to/notify.sh
notify.sh示例:
bash复制#!/bin/bash
# 接收事件类型、事件描述等参数
echo "[$(date)] $@" >> /var/log/redis/sentinel_events.log
5.2 监控与告警集成
Prometheus监控配置示例:
yaml复制- job_name: 'redis_sentinel'
metrics_path: '/metrics'
static_configs:
- targets: ['sentinel1:26379', 'sentinel2:26379', 'sentinel3:26379']
关键监控指标:
sentinel_known_slavessentinel_known_sentinelssentinel_master_down_since_seconds
6. 故障模拟与恢复演练
6.1 主节点宕机测试
- 在主节点执行DEBUG SEGFAULT触发崩溃
- 观察哨兵日志,确认故障转移流程
- 检查新主节点的
redis-cli info replication输出 - 恢复旧主节点,观察其自动变为从节点
6.2 网络分区模拟
使用iptables模拟网络中断:
bash复制# 阻断主节点网络
iptables -A INPUT -p tcp --dport 6379 -j DROP
iptables -A OUTPUT -p tcp --dport 6379 -j DROP
# 30秒后恢复
sleep 30 && iptables -F
观察哨兵行为,特别注意:
- 是否出现不必要的故障转移
- 网络恢复后主从拓扑是否正确恢复
7. 生产环境注意事项
-
密码安全:
- 主从节点和哨兵节点必须使用强密码
- 定期轮换密码时,需先更新所有从节点和哨兵的配置再更新主节点
-
版本一致性:
- 所有Redis节点和哨兵节点应保持相同版本
- 升级时先升级从节点,最后升级主节点
-
容量规划:
- 主节点内存使用不应超过物理内存的70%
- 从节点数量根据读负载需求确定,通常2-5个
-
客户端实现:
java复制JedisSentinelPool pool = new JedisSentinelPool( "mymaster", Set.of("sentinel1:26379", "sentinel2:26379", "sentinel3:26379"), config, timeout, password, useTls );客户端必须配置所有哨兵节点地址,并实现自动重试逻辑
-
定期演练:
- 每季度至少执行一次手动故障转移测试
- 监控系统必须覆盖哨兵选举次数、故障转移耗时等关键指标
在实际运维中,我们发现当Redis实例数量超过50个时,建议将哨兵集群拆分为多个逻辑组,每个组监控10-15个Redis实例,以避免单个哨兵集群监控过多实例导致的性能问题。同时,跨机房的哨兵部署需要特别注意时钟同步问题,所有节点必须配置NTP服务并保持时间误差在50ms以内。