分布式系统架构：服务容错
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 种容错策略对比
文章转载自：卷福同学
还未添加个人签名 2023-06-19 加入
还未添加个人简介
评论