参考大佬文章：后台开发必备知识——容灾

容灾就是对灾难（disater）的容忍能力，即当灾难袭来时，能保证服务正常运行而采取的措施，以实现业务连续性为目标。

后台服务要保证业务连续性（服务不中断，或中断时间在允许范围内），系统需具备容灾能力。基于服务冗余实现的，大而全的容灾系统具有较大成本。

1.数据级容灾：数据备份 2.应用级容灾：数据备份 + 服务多实例

灾难检测 →  容灾切换 → 数据一致性

1. 双活：两个业务系统，不区分主从（负载均衡） 2. 灾备：区分主从，系统故障时，启用备用系统 常见的四层容灾设计：灾难检测： 通过心跳包实现，主从节点分别向控制层上报心跳，若控制层收不到某个节点的心跳，则认为其不可用，对主节点降级，并把流量切到从节点。容灾切换： 将流量从一个节点切换到其他节点，可以通过负载均衡实现数据一致性： 主节点故障时，切换到其他节点也能保证业务不中断，不受影响。等到所有节点都写成功后再返回 → “同步写”                                              （同步写：数据一致性时序图）

但是这种方式有缺点：同步写可能会造成一定延迟，影响系统性能，增加请求响应时间。 所以采用改进方式，优化设计，变"同步"为"异步"，详细步骤： 0. 增加注册中心组件，用于登记写事件 1. master在注册中心登记了写事件，slave可以在注册中心校验数据是否与master一致： (1) 验证结果一致，无需处理 (2) 验证结果不一致，slave尝试从master复制未写的数据，失败则重试n次 (3) 若重试成功，数据同步完成 (4) 若重试失败，则通知注册中心回滚（做标记），同时通知客户端上次写事件失败，需重新发起请求                                      （异步写：容灾一致性实现优化）

1. 注册写事件涉及到的数据内容通常远小于业务数据。 2. 在多节点时，写事件的注册比各节点的数据同步要快很多。

微服务架构之容灾容错_Jaemon-CSDN博客_微服务容灾