第3章故障转移基础

故障转移基础：主动 vs 被动故障转移、冷备 vs 热备 vs 温备、RTO与RPO指标

各位同学，今天咱们聊点实在的。故障转移这件事，说白了就是系统出问题后，怎么让业务快速恢复。我见过太多团队，架构图画得漂亮，真到故障时手忙脚乱。嗯，这里面的门道，咱们一个一个拆开讲。

先说说主动和被动。这两个概念，我刚开始接触时也容易搞混。其实很简单——主动故障转移，是系统自己检测到问题，自动切换；被动故障转移，是人工介入，手动操作。

我个人习惯把主动故障转移叫做「自动驾驶模式」。系统持续监控健康状态，一旦发现主节点挂了，自动把流量切到备用节点。整个过程不需要人参与。我在项目中遇到过，某次凌晨3点，数据库主库宕机，主动故障转移在15秒内完成切换，值班同事还在睡梦中，业务已经恢复了。

被动故障转移呢？说白了就是「手动挡」。系统出问题了，告警响了，运维人员登录跳板机，检查状态，然后手动执行切换脚本。你想想看，这个过程少说也要5-10分钟，如果操作不熟练，半小时都有可能。

核心区别：

这里有个坑，我曾经踩过。主动故障转移虽然快，但容易引发「脑裂」问题——两个节点都以为自己是主节点，互相抢资源。所以做主动切换时，一定要配好仲裁机制，比如用ZooKeeper或etcd做选主。

接下来是备份策略。这三个概念，我建议你从「恢复速度」和「成本」两个维度去理解。

冷备，就是备机处于关机状态，数据通过定期备份同步。比如每天凌晨把数据库导出成SQL文件，存到另一台服务器上。真要用的时候，得先装系统、恢复数据、启动服务。我见过一个团队，冷备恢复花了6个小时，因为备份文件损坏了。嗯，这里要注意——冷备一定要定期做恢复演练。

热备，备机时刻在线，数据实时同步。比如MySQL的主从复制，主库写入一条数据，从库立刻同步。主库挂了，从库秒级接管。代价是什么？成本翻倍。两台机器配置一样，带宽也要够。我曾经给一个金融客户做方案，热备的成本占了总预算的40%，但客户说值——每宕机1分钟损失50万。

温备，介于两者之间。备机在运行，但数据同步不是实时的，可能有几分钟到几小时的延迟。比如每小时做一次增量备份。温备适合那些「可以接受短暂数据丢失」的场景。我个人习惯，温备常用于非核心业务，比如报表系统、日志分析平台。

避坑指南：我曾经犯过一个错误——给核心支付系统配了温备，以为每小时同步一次就够了。结果某次主库磁盘损坏，丢了45分钟的交易数据。从那以后，核心系统我坚决用热备，哪怕多花钱。

这两个指标，是衡量故障转移能力的「硬通货」。你出去跟老板汇报，别扯什么架构多牛，直接说RTO多少、RPO多少，老板一听就懂。

RTO（Recovery Time Objective）：恢复时间目标。从故障发生到业务恢复，允许的最长时间。说白了，就是「你能容忍系统挂多久」。

RPO（Recovery Point Objective）：恢复点目标。故障发生时，允许丢失多少数据。说白了，就是「你能容忍丢多少数据」。

举个例子：

你想想看，这两个指标是互相制约的。RTO越短，意味着切换越快，通常需要热备+自动故障转移，成本高。RPO越短，意味着数据同步越频繁，对网络和存储要求高。

常见组合：

我在项目中遇到过，某客户说「我们要RTO=0，RPO=0」。我直接告诉他，那是不可能的。任何系统都有切换时间，任何网络都有延迟。RTO=0意味着永远不宕机，RPO=0意味着数据永远不丢，这只有上帝能做到。我们能做的，是无限逼近，但永远达不到。

重要提醒：RTO和RPO不是技术指标，而是业务指标。别自己拍脑袋定，一定要跟业务方一起讨论。我曾经见过一个团队，技术侧定了RTO=30秒，结果业务方说「我们晚上可以停10分钟做维护」，白白浪费了资源。

说了这么多，到底怎么选？我个人习惯，按以下步骤来：

举个例子：假设你负责一个电商网站的订单系统。业务方说「宕机不能超过2分钟，数据不能丢」。那你的方案就是：热备（MySQL主从复制）+ 主动故障转移（Keepalived或MHA）。RTO控制在30秒以内，RPO接近0。

再比如，一个内部知识库系统。业务方说「挂了半小时能接受，丢10分钟数据也没事」。那温备就够了，每小时同步一次，手动切换。成本能省一大半。

我的经验：别一上来就追求最完美的方案。先做起来，再逐步优化。我见过太多团队，花3个月设计「完美」的故障转移方案，结果还没上线，业务已经换了。先保证能恢复，再追求恢复得快。

好了，这一章的内容就到这里。故障转移的基础概念，说白了就是三个问题：谁来切（主动还是被动）、备机什么状态（冷温热）、能接受多慢（RTO）和丢多少（RPO）。把这些想清楚，后面的架构设计才有根基。