故障转移

故障转移（Failover）是系统在主节点故障时，自动切换到备用节点继续提供服务的能力。故障转移是高可用的核心机制，可以减少故障时间，提高系统可用性。

故障转移的类型

主备切换（Active-Standby）

主节点处理请求，备节点待命。主节点故障时，备节点接管。

主备切换的优势：实现简单、数据一致性好。

主备切换的问题：备节点闲置（资源浪费）、切换可能有延迟。

主备切换的应用：数据库主从、Redis 主从、负载均衡主备。

双活切换（Active-Active）

两个节点同时处理请求，任一节点故障时，另一个节点接管全部请求。

双活切换的优势：资源利用率高、故障切换快。

双活切换的问题：数据一致性复杂、需要负载均衡。

双活切换的应用：多活架构、负载均衡集群。

多活架构

多活架构是跨地域的部署架构，不同地域可以同时提供服务，任一地域故障时，其他地域接管。

多活架构的优势：地域级容灾、就近访问（延迟低）、资源利用率高。

多活架构的问题：数据一致性复杂、成本高。

多活架构的应用：大型互联网公司的全球部署。

故障检测

健康检查

健康检查是判断节点是否健康的机制。健康检查方式：HTTP 端点、TCP 端口、命令执行。

健康检查配置：检查间隔（5-10 秒）、超时时间（2-5 秒）、失败阈值（连续 3 次失败则判定故障）。

心跳机制

心跳是节点定期发送的信号，表明自己存活。心跳机制：主节点定期发送心跳，备节点监听心跳。如果备节点在超时时间内未收到心跳，则认为主节点故障。

心跳的问题：网络分区可能导致双主（脑裂），需要仲裁机制。

仲裁机制

仲裁机制是解决脑裂的方法，通过第三方仲裁决定谁是主节点。仲裁实现：奇数个节点（多数派）、外部存储（如 ZooKeeper、etcd）、共享磁盘（如 Quorum Disk）。

故障转移流程

故障检测

备节点定期检查主节点健康，连续 N 次检查失败后判定主节点故障。

角色切换

备节点提升为主节点，接管主节点的职责。角色切换可能涉及：IP 漂移（虚拟 IP 漂移到备节点）、DNS 切换（修改 DNS 记录）、配置更新（更新客户端配置）。

通知客户端

客户端需要感知主节点的变化，切换到新的主节点。通知方式：VIP（虚拟 IP，对客户端透明）、配置中心（客户端从配置中心获取主节点地址）、服务发现（客户端从注册中心发现主节点）。

数据同步

新主节点需要同步数据，确保数据一致性。数据同步方式：主从复制（从节点已有数据，只需增量同步）、全量同步（从节点需要全量拉取数据）。

故障转移的实现

数据库故障转移

MySQL 主从切换：从节点提升为主节点，客户端切换到新主节点。MySQL MHA（Master High Availability）是自动化主从切换工具。

Redis 主从切换：Sentinel 是 Redis 的高可用方案，自动完成主从切换。

负载均衡故障转移

Keepalived：通过 VRRP 协议实现主备切换，虚拟 IP 在主备节点间漂移。

双活负载均衡：两个负载均衡器同时工作，通过 ECMP（等价多路径路由）分发流量。

Kubernetes 故障转移

Pod 故障：Controller Manager 检测到 Pod 故障，自动创建新 Pod。

节点故障：Node Controller 检测到节点故障，将 Pod 调度到其他节点。

故障转移的挑战

脑裂（Split-Brain）

网络分区导致多个节点认为自己是主节点，数据冲突。

解决方案：仲裁机制、_fence（通过存储_fence 隔离故障节点）。

数据一致性

故障转移期间可能丢失数据，需要权衡一致性和可用性。

解决方案：同步复制（数据不丢失）、半同步复制（折中方案）、异步复制（性能好但可能丢失数据）。

切换延迟

故障转移需要时间，可能导致服务短暂中断。

解决方案：快速故障检测、预切换（提前发现主节点问题并切换）、自动重连（客户端自动重连到新主节点）。

故障转移的最佳实践

定期演练：定期进行故障转移演练，验证故障转移机制的有效性。

监控告警：监控主节点状态、故障转移事件，异常时及时告警。

自动化：自动化故障转移，减少人工干预，提高恢复速度。

文档记录：记录故障转移流程和运维手册，便于知识传承。

故障转移是高可用的核心机制，理解故障转移的原理和挑战，有助于设计高可用的系统架构。