Redis高可用 故障处理 Redis集群主机宕机后如何应对，redis集群中主机宕机解决方案

Redis集群主机宕机后的生存指南：别让缓存雪崩毁了你的系统

凌晨三点的夺命连环call

"王工！Redis主节点挂了！整个电商首页都打不开了！"凌晨三点，我被运维同事的电话惊醒，揉着惺忪睡眼连上VPN，看到监控大屏上一片血红——三个Redis主节点同时离线，缓存命中率瞬间归零，数据库QPS直接爆表，这是我经历过最惨烈的生产事故,也让我深刻认识到Redis高可用方案的重要性。

Redis集群架构快速回顾

在深入解决方案前,我们先简单梳理下Redis常见的集群模式：

1. 主从复制：最基础的高可用方案，一个主节点(Master)带多个从节点(Slave)
2. 哨兵模式(Sentinel)：在主从基础上增加自动故障检测和转移
3. Redis Cluster：官方分布式方案，数据分片存储在多个主节点
4. 第三方集群方案：如Codis、Twemproxy等代理方案

无论采用哪种架构，主节点宕机都是最严重的故障场景之一,下面我们就来拆解不同情况下的应对策略。

主从+哨兵架构下的主节点宕机

现象识别

• 监控指标：主节点连接超时，从节点复制中断
• 业务表现：写操作失败，读操作可能降级到从节点

标准处理流程

1. 确认故障：通过redis-cli -h 主机IP -p 端口 ping确认节点状态
2. 检查哨兵日志：tail -f /var/log/redis/sentinel.log查看故障转移进度
3. 手动触发转移（如自动转移失败）：

   redis-cli -p 26379 sentinel failover mymaster

4. 验证新主节点：redis-cli -p 26379 sentinel get-master-addr-by-name mymaster

避坑指南

• 脑裂问题：原主节点恢复后可能形成"双主"，需通过CONFIG REWRITE重置配置
• 数据一致性：检查info replication中的master_repl_offset差异
• 客户端适配：确保客户端支持自动重连和新主节点发现

Redis Cluster主节点宕机

故障特征

• 部分键空间不可用（取决于槽位分布）
• 客户端收到CLUSTERDOWN或MOVED错误

标准恢复流程

1. 集群状态检查：

   redis-cli --cluster check 存活节点IP:端口

2. 从节点提升：

   redis-cli --cluster failover --force 存活节点IP:端口

3. 节点替换（如需）：

   redis-cli --cluster add-node 新节点IP:端口 存活节点IP:端口 --cluster-slave

关键注意事项

• 最小存活要求：Redis Cluster需要大多数主节点存活才能维持服务
• 槽位迁移：故障节点恢复后可能需要手动迁移槽位
• 客户端重试：配置合理的retry策略和refresh间隔

高级防御方案

多活架构设计

# 示例：双写策略伪代码
def set_key(key, value):
    try:
        redis_primary.set(key, value)
    except RedisError:
        redis_secondary.set(key, value)
        alert_admin("主集群异常，已降级到备用集群")

分级缓存策略

• L1：本地缓存（Caffeine/Guava） 5ms
• L2：Redis集群 20ms
• L3：数据库 200ms

熔断与降级

# Hystrix配置示例
hystrix.command.default.circuitBreaker.requestVolumeThreshold=20
hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds=5000

事后复盘要点

1. 根因分析：

   • 硬件故障？SSD寿命耗尽？
   • 网络分区？交换机故障？
   • 人为失误？误执行了FLUSHALL？

2. 改进措施：

   • 增加物理节点分散风险
   • 调整cluster-node-timeout参数
   • 完善监控指标（不只是PING监控）

3. 应急预案：

   

   ### Redis主节点宕机checklist
   - [ ] 确认故障范围
   - [ ] 通知相关方
   - [ ] 启动备份连接池
   - [ ] 记录操作时间线

写在最后

那次凌晨的故障让我们付出了惨痛代价——核心业务中断47分钟，直接损失超百万，但也正是这次教训，促使我们重建了整个缓存体系，现在我们的Redis集群可以承受任意两个可用区同时故障，所有运维操作都有"undo"方案。

在分布式系统中，故障不是"是否会发生"的问题，而是"何时发生"的问题，好的架构师不是能预防所有故障，而是能在故障发生时,让系统优雅地降级而非崩溃。