故障切换如何保可用

“故障切换（Failover）如何保证可用”这个问题，通常出现在**高可用架构（HA）**设计中。核心目标是：当某个节点、服务或机房发生故障时，系统能自动、快速、无缝地把流量或服务转移到备用资源上，用户几乎无感知。

下面按原则 → 常见机制 → 实践要点来说明。

一、保证可用的核心原则

1. 冗余（Redundancy）

   • 没有备份，就没有切换
   • 关键组件至少“一主一备”或“多活”

2. 自动检测（Health Check）

   • 能发现故障，才能切换
   • 检测要快、误判要少

3. 快速切换（Low RTO）

   • RTO（恢复时间目标）越短越好
   • 通常要求秒级甚至毫秒级

4. 数据一致性（RPO 可控）

   • 不能为了可用而丢关键数据
   • 根据业务容忍度选择同步/异步复制

二、常见故障切换机制

1. 主备切换（Active–Standby）

• 主节点故障 → 备节点接管
• 常用于数据库、网关、负载均衡器
• 示例：
  • MySQL MHA
  • Redis Sentinel
  • Keepalived + VIP

✅ 优点：简单
❌ 缺点：备节点平时闲置

2. 多活架构（Active–Active）

• 多个节点同时提供服务
• 一个挂了，其他继续扛
• 常用于：
  • 微服务
  • 多机房
  • 全局流量调度（GSLB）

✅ 优点：资源利用率高
❌ 缺点：一致性和路由复杂

3. 健康检查 + 自动剔除

• 负载均衡层（LB）定期探测：
  • TCP / HTTP / 心跳
• 不健康节点自动下线

示例：

• Nginx upstream health check
• Kubernetes liveness / readiness probe

4. 分布式协调与选主

• 用一致性协议避免“脑裂”
• 常见组件：
  • ZooKeeper
  • etcd
  • Consul

典型机制：

• Leader Election
• Lease（租约）机制

5. 流量调度与降级

• DNS / GSLB 切换
• 服务降级（返回缓存、默认值）
• 限流熔断（防止雪崩）

三、工程落地关键点

✅ 1. 避免“脑裂（Split-Brain）”

• 使用奇数节点
• 引入仲裁（quorum）
• 网络分区时“少数派主动退出”

✅ 2. 切换要可演练

• 定期做故障注入（Chaos Engineering）
• 验证：
  • 切换是否自动
  • 数据是否丢失
  • 用户是否感知

✅ 3. 状态与无状态分离

• 无状态服务：切换极快
• 有状态服务：
  • 使用共享存储
  • 或强一致复制

✅ 4. 监控与告警闭环

• 切换前后都要有指标：
  • QPS
  • 延迟
  • 错误率
• 切换本身也要告警（避免“静默失败”）

四、一句话总结

故障切换保可用的本质是：冗余 + 自动检测 + 快速决策 + 可控一致性。

如果你有具体场景（比如：数据库、K8s、微服务、云机房），我可以给你更针对性的方案和架构图。