故障转移 Failover 的流程是什么？设计时要注意什么？
简化版
故障转移是检测到主节点或服务异常后，把流量和职责切换到备用节点的过程。核心流程包括故障检测、确认与防抖、选主或提升备节点、更新路由、恢复服务、观察验证和处理旧主，重点要防止误切、脑裂、数据丢失和反复抖动。
详细版
典型 Failover 流程：
- 监控或心跳发现主节点异常；
- 多次确认故障，避免瞬时网络抖动误判；
- 判断备节点数据状态和健康状态；
- 选出新主或提升备节点；
- 更新 VIP、DNS、注册中心、配置或客户端路由；
- 流量切到新主，观察错误率、延迟、数据一致性；
- 隔离旧主，避免恢复后继续写入造成脑裂；
- 故障修复后做数据追平和角色恢复。
Failover 的关键不是“能不能切”，而是“切得是否安全”。有状态组件尤其要关注复制延迟、未提交数据、双主写入、客户端缓存路由和回滚策略。
完整版教学
一、故障转移不是重启机器那么简单
应用实例挂掉时，Failover 可能只是负载均衡摘掉故障实例。但数据库、缓存、消息队列这类有状态组件的故障转移复杂得多。因为它们不仅承接请求，还保存状态。切换时必须考虑数据是否完整、谁有资格成为新主、旧主恢复后怎么办。
以数据库主从为例，主库故障后，从库可能落后主库几秒。如果直接把从库提升为新主，最后几秒的写入可能丢失。如果旧主其实没挂，只是网络隔离，它可能还在接受部分客户端写入，系统就会出现两个主库。这就是脑裂风险。
因此 Failover 是一套流程，不是一个按钮。
二、故障检测要避免误判
如果心跳一次失败就切换，网络抖动会导致频繁切换。频繁切换比短暂故障更危险，因为每次切换都可能刷新连接、改变路由、触发缓存失效、造成数据同步压力。
常见防抖策略包括：连续多次失败才判定故障；多个探测点共同确认；区分本机故障和网络分区；设置最小切换间隔；切换前检查备节点健康状态。
对于关键数据库，还可能需要人工确认或仲裁机制。自动化越强，越要防止自动化在错误信号下放大事故。
三、选主和提升备节点要看数据状态
不是任何从节点都适合成为新主。要优先选择复制延迟最小、数据最完整、性能容量足够、网络位置合适的节点。某些系统会通过日志位点、事务 ID、Raft 日志索引等判断哪个副本最新。
如果使用多数派协议，只有获得多数派确认的日志才能对外提交，这样新主选出后可以保证已提交数据不丢。传统异步主从则无法提供同样保证，必须接受一定 RPO，或者通过半同步、强同步、业务补偿降低风险。
四、路由更新是恢复服务的关键
新主选出来后，客户端要知道去哪里访问。路由更新方式可能是 VIP 漂移、DNS 切换、注册中心实例变更、配置中心推送、代理层切换或客户端刷新连接池。
DNS 切换要注意 TTL，客户端可能缓存旧地址。长连接服务要主动断开旧连接或让客户端重连。数据库连接池可能持有旧主连接，如果不刷新，会继续写旧节点失败。很多 Failover 事故不是选主失败，而是路由没有彻底切干净。
五、旧主处理决定是否会脑裂
旧主恢复后不能马上接回写流量。它可能缺少新主上的数据，也可能保留旧状态。正确做法通常是先隔离旧主，禁止写入，然后根据新主数据重新追平或重建副本。确认一致后，再以从节点身份加入集群。
脑裂的本质是系统同时出现两个可以接受写入的主节点。防脑裂需要租约、仲裁、多数派、STONITH、只允许新主持有写权限等机制。对数据库来说，防脑裂比快速恢复更重要，因为双写造成的数据冲突往往很难修。
六、Failover 的核心指标是 RTO、RPO 和误切率
评价一次故障转移是否合格，不能只看“有没有切过去”。RTO 反映恢复耗时，RPO 反映数据损失，误切率反映稳定性。自动化切换太慢，业务不可用时间长；切换太激进，网络抖动也触发主备倒换，反而制造事故。
有状态组件还要看数据位点。比如数据库从库 A 延迟 1 秒，从库 B 延迟 10 秒，选新主时应优先选择数据更完整的副本。消息系统要看副本是否在 ISR 内，协调系统要看是否获得多数派。选主不是随机找一个活着的节点，而是选择“健康、最新、容量足够、不会脑裂”的节点。
Failover 后还要观察业务指标：错误率是否下降，P99 是否恢复，写入是否成功，主从复制是否重新建立，旧主是否被隔离。切过去只是中场，不是结束。
七、自动切换和人工确认的边界要分清
应用实例故障、无状态服务摘流，通常适合自动化，因为影响范围小、回滚简单。有状态主库切换、跨机房切流、支付链路降级，风险更高，可能需要自动检测加人工确认，或者在满足严格条件时自动执行。
边界取决于业务等级和系统成熟度。如果有多数派协议、完善的 fencing、可靠的位点判断和演练记录，自动切换可以更大胆；如果复制链路复杂、数据冲突难处理，就要保守一些。高可用不是越自动越高级，而是自动化动作必须在可信信号和安全约束下运行。
面试追问“怎么防脑裂”时，要讲出旧主隔离。可以通过关闭旧主写权限、断开客户端、STONITH、租约过期、多数派选主、代理层只允许新主写入等方式处理。只讲“选一个新主”不够，旧主恢复后的处置才是防止双写的关键。
八、常见误区与追问
这道题要紧扣「故障转移设计」本身回答，不能把它混成泛泛的高可用套话。面试官通常不是只听定义，而是看你能不能把适用场景、关键流程、失败边界和工程取舍串起来，尤其要说明故障域、冗余、健康检查、切换流程、RPO/RTO 和演练结果。
| 回答层次 | 要讲清的内容 | 容易漏掉的边界 |
|---|---|---|
| 核心结论 | 故障转移要解决发现故障、确认主备状态、切换流量、防脑裂、数据追平和回切演练 | 不要停在名词解释 |
| 流程机制 | 健康检查发现异常 -> 仲裁确认故障 -> 冻结旧主或防写 -> 提升新主 -> 切换流量 -> 校验后回切 | 要说清触发点、状态变化、确认点和失败兜底 |
| 工程取舍 | 心跳 3 秒一次、连续 3 次失败再切换，最快也要约 9 秒确认，太短容易误判，太长增加 RTO | 高可用不是永不故障，而是用冗余、隔离、自动切换和演练降低故障影响 |
故障转移设计 面试拆解：
1. 健康检查发现异常
2. 仲裁确认故障
3. 冻结旧主或防写
4. 提升新主
5. 切换流量
6. 校验后回切记忆钩子：先给结论，再拆流程，再讲数字例子和失败边界；回答「故障转移设计」时要围绕题目问法收束，不要把相邻概念堆成一段没有重点的名词清单。
- 误区：检测到失败就立刻切换。 误判会导致双主、数据分叉或频繁抖动。
- 误区：切换只改一个域名。 还要处理连接池、缓存、队列、客户端重试和数据追平。
- 误区：自动切换不需要人工预案。 自动化也要有止血、回滚和人工接管路径。
- 追问：如何避免脑裂？ 用多数派仲裁、租约、 fencing token 或强制旧主下线。
- 追问：RTO 由什么决定？ 检测时间、仲裁时间、提升时间、流量生效和客户端重连时间。
- 追问：切换后为什么要校验？ 确认新主数据完整、复制位点正确、业务写入正常。
九、加强记忆
Failover 可以按“发现故障、确认故障、选择新主、更新路由、隔离旧主、观察恢复”来记。应用层切换重点是摘流量，有状态组件切换重点是数据完整和防脑裂。切得快很重要，但切得安全更重要。