这是小卷对分布式系统架构学习的第3篇文章，虽然知道大家都不喜欢看纯技术文章，写了也没多少阅读量，但是个人要成长的话，还是需要往深一点的技术上去探索的
1.为什么需要容错
分布式系统的本质是不可靠的，一个大的服务集群中，程序可能崩溃、节点可能宕机、网络可能中断，这些“意外情况”其实全部都在“意料之中”。故障的发生是必然的，所以需要设计一套健壮的容错机制来应对这些问题。
容错策略，指的是“面对故障，我们该做些什么”；而容错设计模式，指的是“要实现某种容错策略，我们该如何去做”。下面介绍7种常见的容错策略。
2.七种容错策略
7种常见的容错策略：故障转移、快速失败、安全失败、沉默失败、故障恢复、并行调用和广播调用
故障转移Failover
概念：分布式服务中，服务会有多个副本。如果调用的服务器出现故障，系统不会直接返回失败，而是切换到其他服务副本上，保证返回调用成功的结果。
故障转移需要设置重试次数，并且需根据实际业务场景考虑是否设置故障转移。示例：
现在有 Service A → Service B → Service C 这么一条调用链。假设 A 的超时阈值为 100ms，而 B 调用 C 需要 60ms，然后不幸失败了，这时候做故障转移其实已经没有太大意义了。因为即使B调用C故障转移成功了，调用耗时至少增加60ms，A已经超时了，这种故障转移对系统无利。
适用场景：读多写少的采集，如：电商商品查询；对成功率要求高的采集
快速失败Failfast
当业务场景不允许，或者服务是非幂等时，重复调用会产生脏数据，就不能用故障转移了，需要用到快速失败。
概念：服务在调用失败后，立即返回错误，不做任何重试
示例：支付场景中，调用银行扣款接口，返回结果是网络异常。这时候无法区分是否已扣款了，为避免重复扣款，只能服务抛出异常报错，不能重试
适用场景：高实时性场景、交易支付场景
缺点：调用方需有较高容错能力
安全失败Failsafe
服务也区分主路和旁路，旁路的特点是服务失败了也不影响核心业务。比如spring项目中的日志、Debug信息等。旁路逻辑不影响最终结果。因此，对这类逻辑的容错策略就是，即使旁路逻辑失败了，也当做正确返回。
概念：当服务调用失败时，忽略异常并返回一个默认的结果，确保系统继续运行。
适用场景：非核心业务场景，日志处理、监控采集
优点：最大化保证系统稳定性
示例：java中的try-catch，Dubbo中的failsafe策略
沉默失败Failsilent
概念：大量请求如果都等到超时才失败，可能将系统的线程、内存、网络资源耗尽，影响整个服务稳定性。对该场景的失败策略是：当请求失败后，默认服务提供者一定时间内无法提供服务了，不再向它分配流量，将错误隔离开来。
实际应用场景：分布式系统中，单点故障时，流量调度系统不再给该节点分配流量，每隔5分钟自动检查节点是否恢复。
故障恢复Failback
不是单独存在的，通常默认使用快速失败+故障恢复策略
概念：故障恢复是指在服务调用失败后，将失败的请求异步存储下来，存到数据库或消息队列中，并定时重试或补偿，直到调用成功。这种方式对业务具有一定的“追溯”能力。故障恢复也需有最大重试次数限制
适用场景：实时性要求不高，数据一致性要求高的场景。如：库存更新、订单状态同步
优点：提高系统最终一致性
缺点：系统需配合消息队列，实现复杂
小结：前面5种容错策略都是针对调用失败后如何进行弥补的，下面2种是调用之前如何提供成功率的
并行调用Forking
概念：同时调用多个服务节点，只要任意一个节点返回成功结果即认为调用成功。对于调用结果相同或相似的服务节点，这种方式可大幅提高调用成功率。
适用场景：多副本部署场景、调用耗时长且高可用要求的场景。如：数据库分片存储查询
优点：提供成功率，减少等待时间（取决于最先返回成功的节点）
缺点：增加系统开销
广播调用Broadcast
概念：请求发送给所有服务实例，并收集所有返回结果，要求所有请求全部成功才算成功。这种方式适用于需要对多个节点进行同步操作的场景
适用场景：刷新分布式缓存、配置同步
优点：所有节点都能执行操作
缺点：并行执行开销大
实现方式：Dubbo的broadcast策略支持广播调用
7种容错策略对比
| 容错策略 | 优点 | 缺点 | 应用场景 |
|---|---|---|---|
| 故障转移 | 系统自动处理，调用者对失败信息不可见 | 会增加调用时间，也会导致额外的资源开销 | 调用幂等服务，对调用时间不敏感的场景 |
| 快速失败 | 调用者有失败的处理完全控制，不依赖服务的幂等性 | 调用者必须正确处理失败逻辑，容易引起雪崩 | 调用非幂等的服务，超时阈值较低的场景 |
| 安全失败 | 不影响主逻辑 | 只适用于旁路调用 | 调用链中的旁路服务 |
| 沉默失败 | 控制错误不影响全局 | 出错的地方将有一段时间内不可用 | 频繁超时的服务 |
| 故障恢复 | 调用失败后自动重试，也不影响主逻辑 | 推荐用于旁路服务调用，重试任务可能堆积，重试仍然可能失败 | 调用链中的旁路服务，对实时性要求不高的主逻辑 |
| 并行调用 | 尽可能在最短时间内获得最高的成功率 | 额外消耗机器资源，大部分调用可能是无用功 | 资源充足且失效容忍度低的场景 |
| 广播调用 | 支持同时对批量的服务提供者发起调用 | 资源消耗大，失败概率高 | 只适用于批量操作的场景 |
面试题准备
如果一个业务系统需要调用第三方的5个接口，这5个接口中只要有3个接口返回成功了就认为成功，问如何设计并实现
周志明大佬的答复：
我看这题是个圈套呀，大多数的架构设计题目，固定答案往往都是不对的。因为做技术设计是为了解决实际问题，不能谈兵，所以方案要根据希望实现的目标而定：
如果目的是这项业务尽可能快速地完成，那就forking策略，5个一起调用，成功3个算过。
如果目的是这项业务尽可能少消耗资源，那就failfast策略，先对它们出错概率做个先验判断，排序后先调用最容易出错的，错够3次算失败，后面的不执行。
如果目的是这项业务尽可能高概率地完成，那就failover策略