服务容灾：

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

1.容灾：

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

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

2.容灾层级划分：

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

3.容灾评价指标：

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

4.容灾解决方案：

1. 双活：两个业务系统，不区分主从（负载均衡）
2. 灾备：区分主从，系统故障时，启用备用系统
常见的四层容灾设计：


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

                                             （同步写：数据一致性时序图）

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

5.注册中心的登记同样是同步动作，为何能降低性能？ 

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

微服务架构之容灾容错、隔离：

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