分布式系统架构4:容错设计模式

简介: 这是小卷对分布式系统架构学习的第4篇文章,重点介绍了三种常见的容错设计模式:断路器模式、舱壁隔离模式和重试模式。断路器模式防止服务故障蔓延,舱壁隔离模式通过资源隔离避免全局影响,重试模式提升短期故障下的调用成功率。文章还对比了这些模式的优缺点及适用场景,并解释了服务熔断与服务降级的区别。尽管技术文章阅读量不高,但小卷坚持每日更新以促进个人成长。

这是小卷对分布式系统架构学习的第4篇文章,虽然知道大家都不喜欢看纯技术文章,写了也没多少阅读量,但是为了个人要成长,小卷最近每天都会更新分布式的文章

1.概念

容错策略,指的是“面对故障,我们该做些什么”;而容错设计模式,指的是“要实现某种容错策略,我们该如何去做”。

上一篇已经讲了7种容错策略,为了实现各种策略,开发总结了一些容错设计模式,包括微服务常见的:断路器模式、舱壁隔离模式、超时重试模式。

2.断路器模式

概念:借鉴了电路中的断路器工作原理,用于防止一个子系统的故障蔓延到整个系统。通过在服务之间增加一个断路器机制,当服务调用频繁失败时,断路器会切换到OPEN状态,拒绝进一步调用,避免浪费资源。并且断路器会定期尝试重连目标服务,如果服务恢复正常,则恢复调用。

断路器本质是一种快速失败策略的实现方式

容错设计模式1.png

工作原理

断路器有三种状态:

  • 关闭状态 (Closed):断路器关闭,请求正常调用。如果调用失败次数超过设定阈值,断路器会切换到打开状态。

  • 打开状态 (Open):阻断调用请求,直接返回失败。此状态下,系统不会继续调用目标服务,避免资源浪费。

  • 半开状态 (Half-Open):是一种中间状态,断路器需要带有自动故障恢复功能,进入OPEN状态一段时间后,断路器会尝试放行一次请求测试服务是否恢复。如果成功,切换回关闭状态;否则,保持打开状态。

容错设计模式2.png

示例:

Netflix Hystrix可以设置一段时间内请求故障率达到阈值(10秒内20个请求,失败率50%),断路器的状态就会变为OPEN

3.舱壁隔离模式(服务隔离)

概念:灵感来源于船舶设计,通过为每个模块或服务分配独立的资源池,防止一个模块的故障或资源耗尽影响整个系统。其核心思想是“隔离问题”。简而言之就是:避免某一个远程服务的局部失败影响到全局

具体场景

主流的网络访问大多是基于 TPR 并发模型(Thread per Request)来实现的,只要请求一直不结束(无论是以成功结束还是以失败结束),就要一直占用着某个线程不能释放。

比如:“服务 I”发生了超时,假设平均 1 秒钟内会调用这个服务 50 次,就意味着该服务如果长时间不结束的话,每秒会有 50 条用户线程被阻塞。

Tomcat默认HTTP超时时间是20秒,20秒内会阻塞1000条用户线程,而java应用的线程池通常最大设置为200~400,且Java本身是将线程映射为操作系统内核线程来实现的语言环境。这就意味着从外部看,服务已经全面瘫痪了。不仅是服务1,而是整个Tomcat服务。

容错设计模式3.png

工作原理

解决办法就是为每个服务设立单独的线程池,这样服务1即使阻塞了,比如阻塞5条用户线程,也不影响全局。

容错设计模式4.png

应用案例:阿里内部RPC中间件的HSF线程池隔离

适用场景:系统中存在多个高并发调用的服务,需根据用户等级、用户VIP、用户来访区域等因素隔离到不同的服务实例的场景。

4.重试模式

概念:适用于解决系统的瞬间故障,如:网络抖动、服务临时过载问题。通过设定调用超时时间和重试次数,在调用失败后自动重试,提升服务调用成功率。

使用重试模式时,实现很简单,需避免滥用,适用场景的条件:

  • 只在主路关键服务上进行同步重试
  • 仅瞬间故障引起的失败进行重试
  • 仅对幂等性服务进行重试
  • 重试需要有明确终止条件

5.容错设计模式对比

模式 优点 缺点 适用场景
断路器模式 防止服务雪崩,保护系统稳定性 服务恢复检测需要额外开销 服务调用失败率高,可能影响全局性能的场景
舱壁隔离模式 故障隔离,防止系统资源被耗尽 增加系统设计复杂性 多模块、多服务共享资源的场景
重试模式 提高服务调用成功率,适应短期故障 可能增加系统负载,不适合高实时性场景 临时网络波动、偶发性调用失败

其他问题

1. 服务熔断和服务降级之间的联系与差别?

服务熔断:一种保护机制,用于防止一个服务的连续失败导致整个系统的崩溃,属于一种快速失败的容错策略的实现方法。当失败率达到一定阈值时,断路器会“熔断”请求,直接返回错误响应或默认值

服务降级:通过降低非核心服务的优先级、简化服务逻辑或直接返回备用响应,保证核心服务和主要业务功能的稳定性。通常是基于业务优先级主动触发的

维度 服务熔断 服务降级
触发方式 被动触发:根据失败率、超时或异常次数达到阈值后触发 主动触发:根据系统压力、业务优先级或异常情况手动触发
作用范围 面向单个服务的调用链,避免单点问题影响全局 面向全局系统,通过调整业务优先级释放资源
目标 保护目标服务及调用方的资源,避免雪崩效应 保护核心服务的稳定性,尽量降低对用户的影响
恢复机制 自动恢复:断路器从打开到半开,再到关闭状态逐步恢复 手动恢复:根据系统压力或异常消失后调整业务优先级
实现复杂度 需要监控调用失败率、超时等数据并动态调整 需要结合业务场景设计具体的降级策略
典型场景 下游服务超时、故障,调用方通过熔断保护自己 高并发、大流量或下游服务不可用时主动释放资源
相关文章
|
27天前
|
存储 缓存 NoSQL
分布式系统架构8:分布式缓存
本文介绍了分布式缓存的理论知识及Redis集群的应用,探讨了AP与CP的区别,Redis作为AP系统具备高性能和高可用性但不保证强一致性。文章还讲解了透明多级缓存(TMC)的概念及其优缺点,并详细分析了memcached和Redis的分布式实现方案。此外,针对缓存穿透、击穿、雪崩和污染等常见问题提供了应对策略,强调了Cache Aside模式在解决数据一致性方面的作用。最后指出,面试中关于缓存的问题多围绕Redis展开,建议深入学习相关知识点。
166 8
|
1月前
|
存储 Prometheus Cloud Native
分布式系统架构6:链路追踪
本文深入探讨了分布式系统中的链路追踪理论,涵盖追踪与跨度的概念、追踪系统的模块划分及数据收集的三种方式。链路追踪旨在解决复杂分布式系统中请求流转路径不清晰的问题,帮助快速定位故障和性能瓶颈。文中介绍了基于日志、服务探针和边车代理的数据收集方法,并简述了OpenTracing、OpenCensus和OpenTelemetry等链路追踪协议的发展历程及其特点。通过理解这些概念,可以更好地掌握开源链路追踪框架的使用。
97 41
|
30天前
|
存储 缓存 安全
分布式系统架构7:本地缓存
这是小卷关于分布式系统架构学习的第10篇文章,主要介绍本地缓存的基础理论。文章分析了引入缓存的利弊,解释了缓存对CPU和I/O压力的缓解作用,并讨论了缓存的吞吐量、命中率、淘汰策略等属性。同时,对比了几种常见的本地缓存工具(如ConcurrentHashMap、Ehcache、Guava Cache和Caffeine),详细介绍了它们的访问控制、淘汰策略及扩展功能。
76 6
|
1月前
|
存储 关系型数据库 分布式数据库
[PolarDB实操课] 01.PolarDB分布式版架构介绍
《PolarDB实操课》之“PolarDB分布式版架构介绍”由阿里云架构师王江颖主讲。课程涵盖PolarDB-X的分布式架构、典型业务场景(如实时交易、海量数据存储等)、分布式焦点问题(如业务连续性、一致性保障等)及技术架构详解。PolarDB-X基于Share-Nothing架构,支持HTAP能力,具备高可用性和容错性,适用于多种分布式改造和迁移场景。课程链接:[https://developer.aliyun.com/live/253957](https://developer.aliyun.com/live/253957)。更多内容可访问阿里云培训中心。
[PolarDB实操课] 01.PolarDB分布式版架构介绍
|
2月前
|
设计模式 存储 算法
分布式系统架构5:限流设计模式
本文是小卷关于分布式系统架构学习的第5篇,重点介绍限流器及4种常见的限流设计模式:流量计数器、滑动窗口、漏桶和令牌桶。限流旨在保护系统免受超额流量冲击,确保资源合理分配。流量计数器简单但存在边界问题;滑动窗口更精细地控制流量;漏桶平滑流量但配置复杂;令牌桶允许突发流量。此外,还简要介绍了分布式限流的概念及实现方式,强调了限流的代价与收益权衡。
94 11
|
2月前
|
设计模式 前端开发 搜索推荐
前端必须掌握的设计模式——模板模式
模板模式(Template Pattern)是一种行为型设计模式,父类定义固定流程和步骤顺序,子类通过继承并重写特定方法实现具体步骤。适用于具有固定结构或流程的场景,如组装汽车、包装礼物等。举例来说,公司年会节目征集时,蜘蛛侠定义了歌曲的四个步骤:前奏、主歌、副歌、结尾。金刚狼和绿巨人根据此模板设计各自的表演内容。通过抽象类定义通用逻辑,子类实现个性化行为,从而减少重复代码。模板模式还支持钩子方法,允许跳过某些步骤,增加灵活性。
137 11
|
3月前
|
设计模式 安全 Java
Kotlin教程笔记(51) - 改良设计模式 - 构建者模式
Kotlin教程笔记(51) - 改良设计模式 - 构建者模式
|
24天前
|
设计模式
「全网最细 + 实战源码案例」设计模式——模式扩展(配置工厂)
该设计通过配置文件和反射机制动态选择具体工厂,减少硬编码依赖,提升系统灵活性和扩展性。配置文件解耦、反射创建对象,新增产品族无需修改客户端代码。示例中,`CoffeeFactory`类加载配置文件并使用反射生成咖啡对象,客户端调用时只需指定名称即可获取对应产品实例。
86 40
|
5月前
|
设计模式 数据库连接 PHP
PHP中的设计模式:提升代码的可维护性与扩展性在软件开发过程中,设计模式是开发者们经常用到的工具之一。它们提供了经过验证的解决方案,可以帮助我们解决常见的软件设计问题。本文将介绍PHP中常用的设计模式,以及如何利用这些模式来提高代码的可维护性和扩展性。我们将从基础的设计模式入手,逐步深入到更复杂的应用场景。通过实际案例分析,读者可以更好地理解如何在PHP开发中应用这些设计模式,从而写出更加高效、灵活和易于维护的代码。
本文探讨了PHP中常用的设计模式及其在实际项目中的应用。内容涵盖设计模式的基本概念、分类和具体使用场景,重点介绍了单例模式、工厂模式和观察者模式等常见模式。通过具体的代码示例,展示了如何在PHP项目中有效利用设计模式来提升代码的可维护性和扩展性。文章还讨论了设计模式的选择原则和注意事项,帮助开发者在不同情境下做出最佳决策。
|
25天前
|
设计模式 关系型数据库
「全网最细 + 实战源码案例」设计模式——简单工厂模式
简单工厂模式是一种创建型设计模式,通过工厂类根据传入参数创建不同类型的对象,也称“静态工厂方法”模式。其结构包括工厂类、产品接口和具体产品类。优点是封装性强、代码复用性好;缺点是扩展性差,增加新产品时需修改工厂类代码,违反开闭原则。适用于对象种类较少且调用者无需关心创建细节的场景。
53 19

热门文章

最新文章