参考大佬文章：后台开发必备知识——容灾
1.容灾：
容灾就是对灾难（disater）的容忍能力，即当灾难袭来时，能保证服务正常运行而采取的措施，以实现业务连续性为目标。
后台服务要保证业务连续性（服务不中断，或中断时间在允许范围内），系统需具备容灾能力。基于服务冗余实现的，大而全的容灾系统具有较大成本。
2.容灾层级划分：
1.数据级容灾：数据备份
2.应用级容灾：数据备份 + 服务多实例
3.容灾评价指标：
灾难检测 → 容灾切换 → 数据一致性
4.容灾解决方案：
1. 双活：两个业务系统，不区分主从（负载均衡）
2. 灾备：区分主从，系统故障时，启用备用系统
常见的四层容灾设计：
灾难检测：
通过心跳包实现，主从节点分别向控制层上报心跳，若控制层收不到某个节点的心跳，则认为其不可用，对主节点降级，并把流量切到从节点。
容灾切换：
将流量从一个节点切换到其他节点，可以通过负载均衡实现
数据一致性：
主节点故障时，切换到其他节点也能保证业务不中断，不受影响。等到所有节点都写成功后再返回 → “同步写”
（同步写：数据一致性时序图）但是这种方式有缺点：同步写可能会造成一定延迟，影响系统性能，增加请求响应时间。
所以采用改进方式，优化设计，变"同步"为"异步"，详细步骤：
0. 增加注册中心组件，用于登记写事件
1. master在注册中心登记了写事件，slave可以在注册中心校验数据是否与master一致：
(1) 验证结果一致，无需处理
(2) 验证结果不一致，slave尝试从master复制未写的数据，失败则重试n次
(3) 若重试成功，数据同步完成
(4) 若重试失败，则通知注册中心回滚（做标记），同时通知客户端上次写事件失败，需重新发起请求
（异步写：容灾一致性实现优化）
5.注册中心的登记同样是同步动作，为何能降低性能？
1. 注册写事件涉及到的数据内容通常远小于业务数据。
2. 在多节点时，写事件的注册比各节点的数据同步要快很多。
