- VisualStudio2022插件的安装及使用-编程手把手系列文章
- pprof-在现网场景怎么用
- C#实现的下拉多选框,下拉多选树,多级节点
- 【学习笔记】基础数据结构:猫树
这是小卷对分布式系统架构学习的第4篇文章,虽然知道大家都不喜欢看纯技术文章,写了也没多少阅读量,但是为了个人要成长,小卷最近每天都会更新分布式的文章 。
容错策略,指的是“面对故障,我们该做些什么”;而容错设计模式,指的是“要实现某种容错策略,我们该如何去做”.
上一篇已经讲了7种容错策略,为了实现各种策略,开发总结了一些容错设计模式,包括微服务常见的:断路器模式、舱壁隔离模式、超时重试模式.
概念:借鉴了电路中的断路器工作原理,用于防止一个子系统的故障蔓延到整个系统。通过在服务之间增加一个断路器机制,当服务调用频繁失败时,断路器会切换到OPEN状态,拒绝进一步调用,避免浪费资源。并且断路器会定期尝试重连目标服务,如果服务恢复正常,则恢复调用.
断路器本质是一种快速失败策略的实现方式 。
断路器有三种状态:
关闭状态 (Closed):断路器关闭,请求正常调用。如果调用失败次数超过设定阈值,断路器会切换到打开状态.
打开状态 (Open):阻断调用请求,直接返回失败。此状态下,系统不会继续调用目标服务,避免资源浪费.
半开状态 (Half-Open):是一种中间状态,断路器需要带有自动故障恢复功能,进入OPEN状态一段时间后,断路器会尝试放行一次请求测试服务是否恢复。如果成功,切换回关闭状态;否则,保持打开状态.
示例:
Netflix Hystrix可以设置一段时间内请求故障率达到阈值(10秒内20个请求,失败率50%),断路器的状态就会变为OPEN 。
概念:灵感来源于船舶设计,通过为每个模块或服务分配独立的资源池,防止一个模块的故障或资源耗尽影响整个系统。其核心思想是“隔离问题”。简而言之就是:避免某一个远程服务的局部失败影响到全局 。
主流的网络访问大多是基于 TPR 并发模型(Thread per Request)来实现的,只要请求一直不结束(无论是以成功结束还是以失败结束),就要一直占用着某个线程不能释放.
比如:“服务 I”发生了超时,假设平均 1 秒钟内会调用这个服务 50 次,就意味着该服务如果长时间不结束的话,每秒会有 50 条用户线程被阻塞.
Tomcat默认HTTP超时时间是20秒,20秒内会阻塞1000条用户线程,而java应用的线程池通常最大设置为200~400,且Java本身是将线程映射为操作系统内核线程来实现的语言环境。这就意味着从外部看,服务已经全面瘫痪了。不仅是服务1,而是整个Tomcat服务.
解决办法就是为每个服务设立单独的线程池,这样服务1即使阻塞了,比如阻塞5条用户线程,也不影响全局.
应用案例:阿里内部RPC中间件的HSF线程池隔离 。
适用场景:系统中存在多个高并发调用的服务,需根据用户等级、用户VIP、用户来访区域等因素隔离到不同的服务实例的场景.
概念:适用于解决系统的瞬间故障,如:网络抖动、服务临时过载问题。通过设定调用超时时间和重试次数,在调用失败后自动重试,提升服务调用成功率.
使用重试模式时,实现很简单,需避免滥用,适用场景的条件:
模式 | 优点 | 缺点 | 适用场景 |
---|---|---|---|
断路器模式 | 防止服务雪崩,保护系统稳定性 | 服务恢复检测需要额外开销 | 服务调用失败率高,可能影响全局性能的场景 |
舱壁隔离模式 | 故障隔离,防止系统资源被耗尽 | 增加系统设计复杂性 | 多模块、多服务共享资源的场景 |
重试模式 | 提高服务调用成功率,适应短期故障 | 可能增加系统负载,不适合高实时性场景 | 临时网络波动、偶发性调用失败 |
服务熔断:一种保护机制,用于防止一个服务的连续失败导致整个系统的崩溃,属于一种快速失败的容错策略的实现方法。当失败率达到一定阈值时,断路器会“熔断”请求,直接返回错误响应或默认值 。
服务降级:通过降低非核心服务的优先级、简化服务逻辑或直接返回备用响应,保证核心服务和主要业务功能的稳定性。通常是基于业务优先级主动触发的 。
维度 | 服务熔断 | 服务降级 |
---|---|---|
触发方式 | 被动触发:根据失败率、超时或异常次数达到阈值后触发 | 主动触发:根据系统压力、业务优先级或异常情况手动触发 |
作用范围 | 面向单个服务的调用链,避免单点问题影响全局 | 面向全局系统,通过调整业务优先级释放资源 |
目标 | 保护目标服务及调用方的资源,避免雪崩效应 | 保护核心服务的稳定性,尽量降低对用户的影响 |
恢复机制 | 自动恢复:断路器从打开到半开,再到关闭状态逐步恢复 | 手动恢复:根据系统压力或异常消失后调整业务优先级 |
实现复杂度 | 需要监控调用失败率、超时等数据并动态调整 | 需要结合业务场景设计具体的降级策略 |
典型场景 | 下游服务超时、故障,调用方通过熔断保护自己 | 高并发、大流量或下游服务不可用时主动释放资源 |
最后此篇关于分布式系统架构4:容错设计模式的文章就讲到这里了,如果你想了解更多关于分布式系统架构4:容错设计模式的内容请搜索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
我是一名优秀的程序员,十分优秀!