分布式系统架构3：服务容错

这是小卷对分布式系统架构学习的第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策略