异地多活架构的关键点就是异地、多活，其中异地就是指地理位置上不同的地方，类似于“不要把鸡蛋都放在同一篮子里”；多活就是指不同地理位置上的系统都能够提供业务服务，这里的“活”是活动、活跃的意思
- 同城异区指的是将业务部署在同一个城市不同区的多个机房
- 跨城异地指的是业务部署在不同城市的多个机房，而且距离最好要远一些，距离远一般北京到广州50ms，也可能+++，对余额这类数据，一般不会做跨城异地的多活架构，而只能采用同城异区这种架构，具体还是根据数据特性来设计，对数据一致性要求不那么高，或者数据不怎么改变，或者即使数据丢失影响也不大的业务，跨城异地多活就能够派上用场了
- 跨国异地指的是业务部署在不同国家的多个机房，正常情况下可能就有几秒钟了，用户为不同地区的人提供服务，只读类业务
需要考虑的点：
- “异地多活”是为了保证业务的高可用，保证核心业务的异地多活
- 保证核心数据一致性
- 保证最终一致性，不保证实时一致性
- 多种手段同步数据：消息队列-二次读取-存储系统同步-回源读取-重新生成
- 只保证绝大部分用户的异地多活，比如转账申请处理中-；挂公告；补偿等
业务分级，挑出关键业务；访问量/是否核心业务/收入高的
数据分类，识别数据特征；量/唯一性/实时/可丢失性/可恢复
数据同步：存储同步/消息队列同步/重复生成
异常处理：多通道同步/同步和访问结合/日志记录
无论多么完美的方案，故障的场景下总是可能有一小部分用户业务上出问题，系统无法弥补这部分用户的损失。但我们可以采用人工的方式对用户进行补偿，弥补用户损失，培养用户的忠诚度
接口级故障 - 业务响应缓慢、大量访问超时、大量访问出现异常，这类问题的主要原因在于系统压力太大、负载太高，导致无法快速处理业务请求，由此引发更多的后续问题
优先保证核心业务和优先保证绝大部分用户
- 降级的核心思想就是丢车保帅，优先保证核心业务
- 熔断关键是需要有一个统一的 API 调用层，由 API 调用层来进行采样或者统计
- 限流：基于请求/基于资源 漏桶算法、令牌桶算法、固定窗口、滑动窗口
- 排队
