业务高可用方案
高可用是系统级工程
应对机房断电、火灾、城市地震、水灾等极端情况，就需要异地多活架构。
跨城异地和同城异区
银行存款余额、支付宝余额无法做到跨城异地多活。例如，挖掘机挖断光缆后，广州机房和北京机房是不是可以同时转出去1W元？因此只能做同城异区架构(应对机房级别故障)。
跨城异地和同城异区，是完全两套不同的架构。距离数字上的变化，量变引起了质变，架构复杂度大大提升，网络传输速度降低，中间不可控因素增多。上述这些问题，同城异区也会遇到，但是概率小很多，而且同城异区还可以搭建多套互联通道，成本可控，搭建同城异区，架构上可以将两个机房当作本地机房来设计，无需额外考虑。
跨城异地多活
- 优先实现核心业务的异地多活架构
- 异地多活理论上就不可能很快，物理因素决定的，因此只同步核心业务的数据，保证最终一致性，不保证实时一致性
- 多种手段同步数据：消息队列、B 中心本机读取失败再去 A 中心读取一次、重新生成数据方式、数据库同步等
- 只保证大部分用户的异地多活：异地多活无法保证 100% 的业务可用
异地多活设计步骤
- 业务分级，挑选核心业务：访问量大的业务、核心业务、产生大量收入的业务
- 数据分类：数据量、数据是否必须唯一 (例如用户 ID)、实时性、可丢失性 (session)、可恢复性
- 数据同步方案：MySQL 数据同步、消息队列同步、重复生成
- 异常处理：避免整体业务不可用、修正异常数据、弥补用户损失
通过多个通道同步的方式，来进行异常处理：
- 一个走公网，一个走内网
- 数据可以重复覆盖
通过同步和访问结合方案的设计，来进行异常处理：
- 接口走公网，同步走内网
- 数据有路由规则
- 优先读取本地数据，然后再通过接口访问
接口级故障应对
核心思想：优先保证核心业务，优先保证绝大部分用户。
异地多活架构应对系统级别故障，另外一种常见的是接口级别的故障 (访问超时、异常、响应缓慢)。
具体措施：降级 (应对系统自身故障)、熔断 (应对依赖的外部系统故障)、限流 (性能压测确定阈值)、排队 (限流的变种)