跨可用区容灾与故障转移实战：当一个机房挂了，你的业务还能撑住吗？
去年，某云厂商一个可用区（AZ）发生电力故障，持续了四个小时。大量单AZ部署的业务直接停摆。有一个客户凌晨三点打电话给我：“我们挂了四个小时，损失几百万。隔壁公司跟我们用同一个云，他们怎么没挂？”
我问他：“你们是单AZ部署吗？”
“是。”
“他们呢？”
“应该是多AZ。”
他沉默了。
这是云上容灾最残酷的真相：机房一定会挂。区别只在于，你部署了几个AZ，能不能扛得住。
今天聊聊跨可用区容灾与故障转移。不是那种“多点部署很重要”的废话，而是帮你理清楚：怎么跨AZ部署？故障怎么检测？流量怎么切？数据怎么不丢？
01 多AZ不等于自动容灾
很多人以为，把资源分散在多个AZ，容灾就做好了。这是误会。
多AZ只是给了你容灾的可能性，但需要主动配置才能生效。
需要的配置：
负载均衡跨AZ：流量能在AZ间分发，一个AZ挂了，切到另一个
数据库跨AZ：主库在A，备库在B，能自动切换
应用无状态：会话不绑定单个AZ，切流量用户不丢登录
那家挂了四小时的客户，EC2是在多个AZ，但负载均衡没有跨AZ，数据库也没配备库。A区故障后，A区的EC2全挂，流量切不到B区，因为LB没配跨AZ。白部署了。
反常识观点：把机器放在多个AZ，不等于你在做容灾。 要做容灾，得把整个调用链都跨AZ。
02 跨AZ部署的三种模式
不同模式，RTO（恢复时间）和成本不同。
模式一：主备模式
主AZ：跑全量业务
备AZ：只部署实例，不跑流量（或跑小流量）
故障时：手动或自动切流量到备AZ
RTO：分钟级到小时级
成本：冗余资源少，备AZ可以只保留最低配
模式二：双活模式
两个AZ都跑流量，各约50%
故障时：剩下一个AZ接100%流量
RTO：秒级（负载均衡自动切）
成本：需要双份资源，接受跨AZ流量费
模式三：多活模式
三个及以上AZ同时跑
适合超大规模、极高可用要求
RTO：秒级
成本：线性增加
那家客户后来改了双活：LB跨AZ，数据库主备同步复制，两个AZ各50%流量。再遇到AZ故障，流量自动切到另一个，用户无感知。
03 故障检测与自动转移
容灾的关键是“自动”，不是“人工”。
负载均衡层面的检测：
健康检查：定期探测后端实例。连续失败N次，标记不健康，停止转发流量。
跨AZ切换：LB在AZ间分发流量。如果LB自身也在一个AZ里，那个AZ挂了，LB也挂。要用“多AZ LB”或“跨AZ LB”。
DNS层面的切换：
如果不用LB，可以用DNS轮询，配合健康检查做自动切换。但DNS切换有缓存，生效慢（分钟级），不适合高要求场景。
数据库层面的切换：
主备同步复制：备库实时同步主库数据。
自动切换：主库挂了，备库自动升主，应用重连。
那家客户之前数据库没配备库，AZ故障后，数据在新的可用区起不来。后来配了跨AZ主备同步复制，RPO接近0，RTO分钟级。
04 数据同步：同步还是异步？
跨AZ容灾的核心瓶颈，往往是数据同步。
同步复制
事务要写到主库和备库才返回成功
优点：数据不丢（RPO=0）
缺点：延迟增加，跨AZ网络延迟可能几毫秒，可以接受
异步复制
主库写完就返回，后台同步到备库
优点：性能好
缺点：AZ故障时，可能丢几秒到几分钟的数据
怎么选？
核心数据（订单、支付）：同步复制
非核心数据（日志、分析）：异步复制
那家电商的订单库用了同步复制，跨AZ延迟约2ms，可以接受。日志库异步复制，丢几秒日志没关系。
05 成本不是不做的理由
很多人不做跨AZ容灾，理由是“贵”。
算一笔账：
单AZ部署：资源成本 X
双活部署：资源成本 2X，加上跨AZ流量费（约每GB 0.01-0.02美元）
另一个账：AZ宕机四小时，损失几百万。够付几年跨AZ流量费。
那家客户挂了四小时，损失数百万。后来做双活，每月多花几千美金。运维负责人说：“这笔账，当时觉得贵，出事才知道便宜。”
06 一个真实案例：AZ故障，零影响
去年某云厂商一个AZ故障，持续两小时。一个客户，业务零影响。
他们做了什么？
应用无状态，会话存Redis（跨AZ）
负载均衡跨AZ，自动摘掉故障AZ的实例
数据库跨AZ主备同步复制，自动切换
Redis跨AZ集群，自动故障转移
定期演练，每季度模拟一次AZ故障
故障发生时，他们的监控大屏上，只有一条告警：“AZ-1不可用，流量已切换至AZ-2”。用户无感知。
写在最后
可用区故障，不是“万一”，是“迟早”。区别在于：你是被动承受，还是提前准备。
那家挂了四小时的客户，后来把所有核心业务改成了跨AZ双活。运维负责人说：“以前觉得多AZ是成本，现在觉得是保险。不是防止出事，是出事的时候能扛住。”
你的业务，扛得住一个机房挂掉吗？
