故障转移怎么实现？

本文目录导读：

1. 网络层/硬件层故障转移（最基础）
2. 应用层/服务层故障转移（最常用）
3. 数据层故障转移（最复杂）
4. 常见工具与平台
5. 实现故障转移的三个关键要素
6. 总结：如何设计一个简单的故障转移？

故障转移（Failover）的核心目标是：当系统中的一个组件（如服务器、数据库、网络）发生故障时，能够自动、无缝地将工作负载切换到另一个健康的备用组件上，从而保证服务的持续可用性。

实现故障转移的方式主要取决于你希望保护的资源类型（如IP、数据库、应用进程）和架构层级,以下是几种主流的实现方案及其原理：

网络层/硬件层故障转移（最基础）

这是最底层、最快的故障转移方式,通常依赖硬件或操作系统。

• VRRP / CARP 协议
  • 原理：多台服务器（通常是2台）共享一个虚拟IP（VIP），其中一台是Master（主），负责响应VIP请求；另一台是Backup（备），主机会通过心跳报文宣告自己的存活，如果Backup在指定时间（如3秒）内收不到Master的心跳，就会接管VIP,成为新的Master。
  • 应用：常用于防火墙、路由器的热备,或作为高可用集群的入口。
  • 特点：透明、切换快（秒级），但对应用层故障（如HTTP服务挂起但进程还在）无感。

应用层/服务层故障转移（最常用）

这是针对特定服务进程的故障转移，需要一个集群管理软件（如下方提到的Keepalived、Heartbeat等套件）或容器编排平台。

• 主从模式

  • 原理：一个主节点负责所有读写，一个或多个从节点只负责同步数据，当主节点宕机时,从节点之一被提升为新的主节点。
  • 典型实现：Redis Sentinel、MySQL主从+ MHA、MongoDB Replica Set。
  • 切换流程：
    1. Sentinel/仲裁节点检测到主节点超时。
    2. 多数Sentinel/从节点达成共识,确认主节点失效。
    3. 选举出一个从节点，执行 SLAVEOF NO ONE 命令使其变为新主。
    4. 修改配置,将客户端连接指向新主。

• 主主模式

  • 原理：两个节点都处于活动状态，各自处理请求，但通常需要配合流量入口做负载均衡，当一个节点故障时,流量全部切换给另一个。
  • 难点：需要解决数据冲突和写入一致性问题（如MySQL双写），生产环境使用较少,常见于无状态服务。

数据层故障转移（最复杂）

数据层的故障转移除了要恢复服务，还必须保证数据不丢、一致性不破坏。

• 共享存储 + 挂载切换

  • 原理：所有节点访问同一个共享存储（如NAS、SAN、Ceph RBD），应用进程运行在活动的节点上,数据则从共享存储读取。
  • 切换：当节点A故障时，节点B接管挂载点（如通过 fsck 强制挂载），启动自己的服务进程，并对外提供服务，数据库集群（如Oracle RAC）是典型代表。

• 应用层数据复制 + 重定向

  • 原理：数据在多个节点之间实时同步（如同步复制或异步复制）。
  • 切换：故障发生时，客户端或路由层（如 ProxySQL、HaProxy MySQL）负责将读写流量切换到数据一致的新节点，对应的是无共享存储的架构。

常见工具与平台

实现故障转移的三个关键要素

无论使用哪种技术,一套完整的故障转移方案都需要解决三个问题：

1. 心跳检测

   • 问题：如何判断节点是否真的挂了？（避免误判导致“脑裂”）
   • 方案：
     • 多路径心跳：使用双网卡、双交换机进行检测,避免单网卡故障导致误判。
     • 仲裁机制：引入第三方组件（如K8s的etcd、ZooKeeper、Consul）,由协调者根据多数投票结果决定是否切换。

2. 数据一致性

   • 同步模式：主节点写入后，必须等从节点确认后才返回成功（性能差，但绝对一致）。
   • 异步模式：主节点写入并返回成功，然后异步发送给从节点（性能好，但可能丢数据）。
   • 半同步模式：折中方案,至少一个从节点确认即可。

3. 客户端透明切换

   • 问题：即使服务端切换成功了，客户端的连接还是旧的,怎么让客户端知道服务器换了？
   • 方案：
     • VIP法：IP地址保持不变（从故障服务器漂移到备用服务器）,客户端无感知。
     • DNS法：修改DNS记录，指向新IP（生效慢，依赖DNS缓存）。
     • 负载均衡器法：在LB层面监控后端,自动摘掉故障节点。
     • 客户端自动重试：客户端SDK中内置重试逻辑和地址列表（如ZooKeeper、Eureka、Nacos等注册中心）。

如何设计一个简单的故障转移？

假设你有一个 Web 应用（Node.js/Java）和一台 MySQL 数据库,想实现基本的故障转移：

1. 无状态应用层：

   • 部署两台应用服务器。
   • 前面架设一个 Nginx，配置 upstream 指向这两台服务器,并启用健康检查。
   • 在Nginx服务器上配置 Keepalived,提供VIP。
   • 结果：任一一台应用服务器宕机,Nginx自动将流量切到另一台。

2. 有状态数据库层：

   • 部署两台MySQL：主（Master）、从（Slave）。
   • 配置 半同步复制。
   • 安装 MySQL Router 或 ProxySQL，它会监控主节点健康状态，在主节点挂掉时,自动将读写分离切换到新的主节点。
   • 结果：主库宕机，从库被升级为新主,应用端通过路由器无缝切换。

一句话总结：无状态服务靠负载均衡器+健康检查+IP漂移；有状态服务靠主从复制+选举算法+连接路由器。