- VisualStudio2022插件的安装及使用-编程手把手系列文章
- pprof-在现网场景怎么用
- C#实现的下拉多选框,下拉多选树,多级节点
- 【学习笔记】基础数据结构:猫树
这是小卷对分布式系统架构学习的第3篇文章,虽然知道大家都不喜欢看纯技术文章,写了也没多少阅读量,但是个人要成长的话,还是需要往深一点的技术上去探索的 。
分布式系统的本质是不可靠的,一个大的服务集群中,程序可能崩溃、节点可能宕机、网络可能中断,这些“意外情况”其实全部都在“意料之中”。故障的发生是必然的,所以需要设计一套健壮的容错机制来应对这些问题.
容错策略,指的是“面对故障,我们该做些什么”;而容错设计模式,指的是“要实现某种容错策略,我们该如何去做”。下面介绍7种常见的容错策略.
7种常见的容错策略:故障转移、快速失败、安全失败、沉默失败、故障恢复、并行调用和广播调用 。
概念:分布式服务中,服务会有多个副本。如果调用的服务器出现故障,系统不会直接返回失败,而是切换到其他服务副本上,保证返回调用成功的结果.
故障转移需要设置重试次数,并且需根据实际业务场景考虑是否设置故障转移。示例:
现在有 Service A → Service B → Service C 这么一条调用链。假设 A 的超时阈值为 100ms,而 B 调用 C 需要 60ms,然后不幸失败了,这时候做故障转移其实已经没有太大意义了。因为即使B调用C故障转移成功了,调用耗时至少增加60ms,A已经超时了,这种故障转移对系统无利.
适用场景:读多写少的采集,如:电商商品查询;对成功率要求高的采集 。
当业务场景不允许,或者服务是非幂等时,重复调用会产生脏数据,就不能用故障转移了,需要用到快速失败.
概念:服务在调用失败后,立即返回错误,不做任何重试 。
示例:支付场景中,调用银行扣款接口,返回结果是网络异常。这时候无法区分是否已扣款了,为避免重复扣款,只能服务抛出异常报错,不能重试 。
适用场景:高实时性场景、交易支付场景 。
缺点:调用方需有较高容错能力 。
服务也区分主路和旁路,旁路的特点是服务失败了也不影响核心业务。比如spring项目中的日志、Debug信息等。旁路逻辑不影响最终结果。因此,对这类逻辑的容错策略就是,即使旁路逻辑失败了,也当做正确返回.
概念:当服务调用失败时,忽略异常并返回一个默认的结果,确保系统继续运行.
适用场景:非核心业务场景,日志处理、监控采集 。
优点:最大化保证系统稳定性 。
示例:java中的try-catch,Dubbo中的failsafe策略 。
概念:大量请求如果都等到超时才失败,可能将系统的线程、内存、网络资源耗尽,影响整个服务稳定性。对该场景的失败策略是:当请求失败后,默认服务提供者一定时间内无法提供服务了,不再向它分配流量,将错误隔离开来.
实际应用场景:分布式系统中,单点故障时,流量调度系统不再给该节点分配流量,每隔5分钟自动检查节点是否恢复.
不是单独存在的,通常默认使用快速失败+故障恢复策略 。
概念:故障恢复是指在服务调用失败后,将失败的请求异步存储下来,存到数据库或消息队列中,并定时重试或补偿,直到调用成功。这种方式对业务具有一定的“追溯”能力。故障恢复也需有最大重试次数限制 。
适用场景:实时性要求不高,数据一致性要求高的场景。如:库存更新、订单状态同步 。
优点:提高系统最终一致性 。
缺点:系统需配合消息队列,实现复杂 。
小结:前面5种容错策略都是针对调用失败后如何进行弥补的,下面2种是调用之前如何提供成功率的 。
概念:同时调用多个服务节点,只要任意一个节点返回成功结果即认为调用成功。对于调用结果相同或相似的服务节点,这种方式可大幅提高调用成功率.
适用场景:多副本部署场景、调用耗时长且高可用要求的场景。如:数据库分片存储查询 。
优点:提供成功率,减少等待时间(取决于最先返回成功的节点) 。
缺点:增加系统开销 。
概念:请求发送给所有服务实例,并收集所有返回结果,要求所有请求全部成功才算成功。这种方式适用于需要对多个节点进行同步操作的场景 。
适用场景:刷新分布式缓存、配置同步 。
优点:所有节点都能执行操作 。
缺点:并行执行开销大 。
实现方式:Dubbo的broadcast策略支持广播调用 。
容错策略 | 优点 | 缺点 | 应用场景 |
---|---|---|---|
故障转移 | 系统自动处理,调用者对失败信息不可见 | 会增加调用时间,也会导致额外的资源开销 | 调用幂等服务,对调用时间不敏感的场景 |
快速失败 | 调用者有失败的处理完全控制,不依赖服务的幂等性 | 调用者必须正确处理失败逻辑,容易引起雪崩 | 调用非幂等的服务,超时阈值较低的场景 |
安全失败 | 不影响主逻辑 | 只适用于旁路调用 | 调用链中的旁路服务 |
沉默失败 | 控制错误不影响全局 | 出错的地方将有一段时间内不可用 | 频繁超时的服务 |
故障恢复 | 调用失败后自动重试,也不影响主逻辑 | 推荐用于旁路服务调用,重试任务可能堆积,重试仍然可能失败 | 调用链中的旁路服务,对实时性要求不高的主逻辑 |
并行调用 | 尽可能在最短时间内获得最高的成功率 | 额外消耗机器资源,大部分调用可能是无用功 | 资源充足且失效容忍度低的场景 |
广播调用 | 支持同时对批量的服务提供者发起调用 | 资源消耗大,失败概率高 | 只适用于批量操作的场景 |
如果一个业务系统需要调用第三方的5个接口,这5个接口中只要有3个接口返回成功了就认为成功,问如何设计并实现 。
周志明大佬的答复:
我看这题是个圈套呀,大多数的架构设计题目,固定答案往往都是不对的。因为做技术设计是为了解决实际问题,不能谈兵,所以方案要根据希望实现的目标而定:
如果目的是这项业务尽可能快速地完成,那就forking策略,5个一起调用,成功3个算过.
如果目的是这项业务尽可能少消耗资源,那就failfast策略,先对它们出错概率做个先验判断,排序后先调用最容易出错的,错够3次算失败,后面的不执行.
如果目的是这项业务尽可能高概率地完成,那就failover策略 。
最后此篇关于分布式系统架构3:服务容错的文章就讲到这里了,如果你想了解更多关于分布式系统架构3:服务容错的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
我有一个具有以下架构的网站: End user ---> Server A (PHP) ---> Server B (ASP.NET & Database)
是否有认证或某些权威来决定软核是否具有容错性? 另一个问题。我已经看到 LEON3-FT 只有在 RTAX Actel FPGA 上实现时才具有耐辐射性。那正确吗? 打扰一下,但我对此感到困惑,因为有
我正在使用 Data.Aeson 将一些 JSON 解析为 Record 类型。不时将数据添加到 JSON 中,这会破坏我的代码,因为 Aeson 会提示以下内容: expected Object w
我对分区模式下的 Ignite Cache 有几个问题 1)当Ignite集群中的节点发生故障时,如果故障节点是某个 key 的主节点,那么该节点的备份是否会成为新的主节点? 2) 故障节点中的备份副
我正在深入研究 Akka只是看着他们的 fault tolerance example ,并试图理解它。 为什么我不能在“纯 Java”中实现所有相同类型(Worker、Listener、Counte
Apache Kylin 看起来是一个很棒的工具,可以满足大量数据科学家的需求。这也是一个非常复杂的系统。我们正在开发一个内部解决方案,其目标完全相同,即具有低查询延迟的多维 OLAP 多维数据集。在
我需要将目录从一个集群复制到另一个具有类似 HDFS 的集群(两者都是 MAPR 集群)。 我计划使用 DistCp Java API。但我想避免目录中文件的重复副本。我想知道这些操作是否容错?也就是
有没有人拥有/制造/销售用于 .NET 的容错 XML 阅读器? 是的,我知道,XML 的设计目的不是为了在其中包含错误,如果它无效就应该被拒绝......等等等等。但遗憾的是,现实世界是不完美的,开
我试图在 akka Actors 中获得容错行为。我正在编写一些代码,这些代码依赖于系统中的 Actor 可用于长期处理。我发现我的处理在几个小时后停止(大约需要 10 小时)并且没有发生太多事情。我
我有兴趣了解 Spark 如何实现容错。在他们的paper他们描述了他们如何为“狭窄的依赖关系”做这件事,比如相当简单的 map 。但是,我没有说明如果节点在像排序操作这样的广泛依赖性之后崩溃时他们会
我目前正在通过离线访问在 Android 上实现 Google+ 身份验证。这需要请求一个一次性授权代码,该代码可以发送到服务器并兑换为刷新 token 。到目前为止一切顺利。 然而,假设在兑换代码和
我需要解析一个没有根元素、命名空间声明和实体声明的 xml block ,尽管包括所有这三个元素。 到目前为止,我一直在使用 Dom4j 并对内容进行一些包装,但不断出现新的实体和 namespace
我有一个 23 节点集群,在 AWS 上跨 4 个可用区运行 CoreOS Stable 681.2.0。所有节点都在运行 etcd2 和 flannel。在 23 个节点中,8 个是专用的 etcd
在我的办公室,我们正在使用 (https://docs.microsoft.com/en-us/dotnet/api/system.io.filesystemwatcher?view=netframe
我是一名优秀的程序员,十分优秀!