Redis通过哨兵模式实现分布式系统自动故障检测，结合心跳检测、主观下线判定、客观下线协商、领导者选举、故障转移五大核心机制，支持秒级故障切换。本文详解RedisCluster节点检测原理、Prometheus监控告警配置技巧，并给出电商平台高可用架构实战案例。
Redis哨兵模式怎样判断节点故障？
问题：当某个Redis节点响应超时，系统如何确认是真实故障而非网络波动？
方案：哨兵集群采用双重验证机制：
1. 主观下线（SDOWN）：单个哨兵检测到节点500ms未响应
2. 客观下线（ODOWN）：超过quorum数量的哨兵确认故障
案例：某社交App曾因单哨兵误判导致主节点切换，改为3哨兵+quorum=2配置后，故障误报率降低98%
RedisCluster如何自动执行故障转移？
问题：集群模式下从节点如何接管故障主节点的槽位？
方案：基于Gossip协议的分布式共识流程：
– 节点间每秒发送PING/PONG包
– 主节点失联超1500ms触发故障检测
– 从节点发起选举获得多数派同意
案例：某电商大促期间主节点宕机，16384个槽在2.3秒内完成转移，业务无感知
如何用Prometheus监控Redis故障？
问题：人工检查节点状态效率低，怎样实现智能预警？
方案：配置关键指标监控体系：
1. 连接数突增：redis_connected_clients > 1000告警
2. 内存异常：used_memory超过maxmemory的80%
3. 主从延迟：master_repl_offset差值持续扩大
案例：某物流系统通过redis_exporter+AlertManager，提前20分钟预测主节点OOM风险
Redis高可用架构设计的三个误区
误区一：哨兵节点与Redis实例同主机部署
改进方案：物理隔离哨兵与数据节点，至少部署3个独立物理机
误区二：cluster-node-timeout使用默认值
优化建议：根据网络质量设置为1500-5000ms，避免跨机房抖动误判
误区三：忽略客户端重试机制
正确做法：配置Jedis客户端的maxAttempts=3，启用ReadFrom策略
Redis故障检测常见问题
- Q：故障转移期间会丢数据吗？
A：异步复制场景可能丢失最近1秒数据，需配置min-slaves-to-write参数 - Q：哨兵模式与Cluster模式如何选择？
A：哨兵适合主从架构，Cluster支持多主节点，按数据量和分片需求选择 - Q：网络分区如何处理脑裂问题？
A：设置cluster-slave-validity-factor参数，防止过期从节点提升为主
