故障转移如何实现

“故障转移（Failover）”的实现方式取决于具体场景（数据库、服务器、网络、云服务、微服务等都略有不同），但核心思想是一致的：当主节点不可用时，系统自动将流量/任务切换到备用节点，保证业务连续性。

下面从 通用原理 → 常见实现方式 → 典型示例 讲清楚。

一、故障转移的核心原理

1. 健康检测（Health Check）
   • 定期检测主节点是否存活（心跳、ping、端口、业务探针）
2. 状态同步（可选）
   • 主备数据一致（同步复制 / 异步复制）
3. 决策机制
   • 谁来判断“主节点挂了”（人工 / 自动）
4. 切换动作
   • VIP漂移、DNS切换、服务注册中心更新、负载均衡转发
5. 恢复与回切
   • 主节点恢复后是否自动回切

二、常见故障转移实现方式

1️⃣ 主备模式（Active-Standby）

• 一个主节点对外服务
• 一个或多备节点待命
• 主挂 → 备接管

实现手段

• VIP（虚拟IP）+ Keepalived
• 数据库主从 + 自动提升从库

✅ 简单
❌ 资源利用率低

2️⃣ 双活 / 多活（Active-Active）

• 多节点同时服务
• 某节点故障 → 流量被重新分配

实现手段

• 负载均衡（Nginx / LVS / F5）
• 服务注册与发现（Consul / Nacos / Eureka）

✅ 高可用、高利用率
❌ 数据一致性复杂

3️⃣ 基于负载均衡的故障转移

用户 → LB → [Server A, Server B, Server C]

• LB 检测节点健康
• 故障节点自动摘除

典型技术

• Nginx upstream
• Kubernetes Service + readinessProbe

4️⃣ 基于虚拟IP（VIP）的故障转移

Client → VIP
VIP → Master（挂了）→ Backup

常用方案

• Keepalived + VRRP
• 云厂商的 HA VIP

5️⃣ 数据库故障转移

• 主从复制
• 哨兵 / 集群管理器
  • MySQL：MHA、Orchestrator
  • Redis：Sentinel
  • PostgreSQL：Patroni

流程：

1. 主库故障
2. 哨兵检测
3. 提升从库为主
4. 客户端重连

6️⃣ 云原生 / 微服务故障转移

• Kubernetes：
  • Pod 重启
  • 多副本 + 调度策略
• Service Mesh（Istio）：
  • 自动重试、熔断、流量切换

三、一个简单的实现示例（Keepalived）

vrrp_instance VI_1 {
  state MASTER
  interface eth0
  virtual_router_id 51
  priority 100
  virtual_ipaddress {
    192.168.1.100
  }
}

主节点挂掉 → VIP 自动漂到备节点

四、故障转移的关键点（容易踩坑）

• ❗ 脑裂（Split-Brain）：主备都认为自己为主
  • 解决：仲裁节点、 fencing
• ❗ 数据丢失：异步复制
• ❗ 切换风暴：检测太灵敏
• ❗ 回切导致二次故障

五、总结一句话

故障转移 = 检测故障 + 决策切换 + 无缝接管 + 可控恢复

如果你说的是某一具体系统（如 MySQL、Redis、K8s、Nginx、云服务器），我可以直接给你对应方案和配置示例。