架构设计之防止或缓解雪崩效应

熔断

当某个服务调用慢或者有大量超时现象(过载),系统停止后续针对该服务的调用而直接返回,直至情况好转才恢复调用。这通常是为防止造成整个系统故障而采取的一种保护措施,也称过载保护。很多时候刚开始,可能只是出现了局部小规模系统故障,但后来故障影响的范围越来越大,最终导致了全局性的后果。

限流

对某个服务调用设置最高QPS阈值,高于阈值的请求放弃调用直接返回。这种模式不能解决服务依赖的问题,只能解决系统整体资源分配问题,因为没有被限流的请求依然有可能造成雪崩效应。

限流处理方案

  • 限制最大并发数;
  • 限制时间窗内最大请求数;
  • 令牌桶算法。该算法描述如下:

    1)限制用户平均发送速率为r 字节/s,则以r 个/s的速度往桶中放入令牌,即为每一个字节配备一个令牌。2)假设桶的最大容量为b,如果令牌桶已满,则丢弃这个令牌。3)当流入速率为v 字节/s,则从桶中取令牌的速率为v 个/s。拿到令牌的流量通过,拿不到的则执行限制逻辑。

    该算法具有如下特点:

    1)长期来看,流入速率受令牌添加速率的影响,被稳定为r。
    2)令牌桶有一定的容量,可以抵挡一定的流量突发情况。
    3)假设最大流入速率为M,则 M > r。4)假设能承受最大流入速率M的持续时间为T,则 T = b / (M - r)。5)假设最大流入速率M持续时间内传输的流量为B,则 B = T * M。6)当一个n个字节大小的请求数据包到达,将从桶中删除n个令牌。但如果桶中余下令牌不足n个,  则不会删除令牌,该请求将被限流(要么丢弃,要么缓冲区等待)。7)当r极大,如r > 1000时,也就是匀速放一个令牌的时间间隔是小于1 ms的,这个精度不好控制;  可以采用流入事件触发方式来添加令牌,即下一个请求到来会先计算当前时间到上一次添加令  牌时间这个时间段内应该添加的令牌数(取整数部分),然后添加完令牌再决定通过或限制当前请求,  这样依然可以维持整体流入速率稳定在r。

    该算法具有的优点:

    1)流量比较平滑,并且可以抵挡一定的流量突发情况。
  • 漏桶算法。漏桶作为计量工具,可用于流量整形(Traffic Shaping)和流量控制(Traffic Policing)。该算法描述如下:

    1)一个固定容量的漏桶,以恒定的速率流出。
    2)如果漏桶是空的,则不需流出。
    3)如果流入超出了漏桶的容量,则溢出(被丢弃)。

    该算法具有的优点:

    1)该算法可平滑突发流量,是消灭突发状况的有效坚决办法。

限流可以在应用层实现,也可以在接入层实现,通常使用redis + lua或者nginx + lua来实现。

降级

当访问量剧增致服务出现问题(如响应时间慢或不响应),或非核心服务影响到核心流程的性能时,仍要保证服务是可用的;即使是有损的,且有些服务是无法降级的,如加入购物车、结算等。降级可以是自动降级或人工降级,可以是读服务降级或写服务降级,还可以是多级降级。自动降级可根据系统负载、资源使用情况、调用超时、失败重试次数、故障、限流阀值、SLA(Service-Level Agreement)等指标进行降级。

降级处理方案

  • 返回默认值:比如库存调用超时,返回默认现货;
  • 返回兜底数据:通常是异常或错误发生时最后适用的数据,比如预备的静态页面、默认的数据;
  • 返回缓存数据;
  • 返回空值;
  • 放弃调用。

降级发生场景

  • 读降级:多级缓存模式下,如接入层缓存-->应用层缓存-->分布式缓存(Redis Clusters)-->RPC / DB,可由远及近的顺序降级读缓存,这种方式适用于对读一致性要求不高的场景。另外,也可走静态页,或屏蔽读;
  • 写降级:只更新Cache,之后异步扣减库存到DB,保证最终一致性即可。

在大促活动期间,对某些占用了稀缺资源的次要页面或片段调用降级,同时也对爬虫返回静态页或者空数据,以保证核心业务正常开展。

隔离

下图展示了非隔离状态下单个用户请求被服务依赖I阻塞的情况:

下图展示了非隔离状态下服务依赖I阻塞了全部用户请求,而其他用户请求此时根本没有机会接受线程池的处理:

对请求按类型划分并分配不同数量的线程池来隔离处理,各自互不影响。当某个请求类型的线程池资源耗尽,则后续该类型请求可停止处理而直接返回,不影响其他请求类型线程的正常执行;这就避免了,非隔离状态下慢服务阻塞所有用户请求导致整个线程池处理能力下降。

Hystrix 是一个解决分布式系统交互超时处理和容错的类库,是 Netflix 的众多开源项目之一。Hystrix 采用线程池和信号量两种隔离方式,来限制并发访问量和故障扩散。

缓存

缓存通常用来加速数据访问,但缓存在大面积失效或负载过大或重启之后,导致数据访问穿透到DB,依然可能引起雪崩效应的发生。

时间: 2024-10-09 12:44:00

架构设计之防止或缓解雪崩效应的相关文章

高并发架构系列:如何解决Redis雪崩、穿透、并发等5大难题

别人用手机刷新闻.刷段子,你用手机刷知识.你会的越多,成功率就越高. 本篇分享大型网站高并发架构设计是如何解决Redis雪崩.穿透.并发等5大难题的,以下,enjoy~ 缓存雪崩 数据未加载到缓存中,或者缓存同一时间大面积的失效,从而导致所有请求都去查数据库,导致数据库CPU和内存负载过高,甚至宕机. 比如一个雪崩的简单过程: 1.redis集群大面积故障 2.缓存失效,但依然大量请求访问缓存服务redis 3.redis大量失效后,大量请求转向到mysql数据库 4.mysql的调用量暴增,很

【架构】分布式系统雪崩效应处理方案

分布式系统雪崩效应处理方案 异步 雪崩_百度搜索 如何应对并发(2) - 请求合并及异步处理 防雪崩利器:熔断器 Hystrix 的原理与使用 - 编程随笔 - SegmentFault 两种常见雪崩的原理及其避免方法_公园里de石头_新浪博客 [问底]徐汉彬:Web系统大规模并发--电商秒杀与抢购-CSDN.NET 漫谈雪崩 - mikeszhang的专栏 - 博客频道 - CSDN.NET 漫谈雪崩 - 系统其他栏目 - 红黑联盟 前言 分布式系统中经常会出现某个基础服务不可用造成整个系统不

电商峰值系统架构设计--转载

1.1 系统架构设计目录 摘要:双11来临之际,<程序员>以“电商峰值系统架构设计”为主题,力邀京东.当当.小米.1号店.海尔商城.唯品会.蘑菇街.麦包包等电商企业,及商派.基调网络等服务公司,分享电商峰值系统架构设计的最佳技术实践. 自2009年11月11日,淘宝商城(现名天猫)拉开网购狂欢节的序幕,各大电商的促销浪潮此起彼伏.此时的电商大战不仅是价格之争,更是技术的较量.如何设计电商峰值系统来更好地满足用户蜂拥而至的访问,如何在海量数据处理中实时发现有效信息并转化为商机,成为众多电商企业密

微服务架构设计

微服务 软件架构是一个包含各种组织的系统组织,这些组件包括 Web服务器, 应用服务器, 数据库,存储, 通讯层), 它们彼此或和环境存在关系.系统架构的目标是解决利益相关者的关注点. Conway’s law: Organizations which design systems[...] are constrained to produce designs which are copies of the communication structures of these organizati

【软件架构】IM架构设计(安卓版)

1. 架构总览 2. 模块介绍 2.1 协议封装与任务流程 2.1.1 协议与任务的封装 协议有协议头(协议头因为格式相同,被抽象出来)和协议体组成,协议有两类:请求协议(request)和回复协议(response): 任务(action)由请求协议.回复协议和任务回调(callback)组成: callback是针对客户端主动请求协议的相应处理,分别是成功回调.超时回调和失败回调: 2.1.2 消息(任务)流程 由UI或SYSTEM触发一个消息的生成,随之将其投递到发送队列中,等待发送: 消

Android-IM架构设计

###1. 架构总览 ###2. 模块介绍 ####2.1 协议封装与任务流程 #####1) 协议与任务的封装 a. 协议有协议头(协议头因为格式相同,被抽象出来)和协议体组成,协议有两类:请求协议(request)和回复协议(response): b. 任务(action)由请求协议.回复协议和任务回调(callback)组成: c. callback是针对客户端主动请求协议的相应处理,分别是成功回调.超时回调和失败回调: #####2) 消息(任务)流程 a. 由UI或SYSTEM触发一个

《大型分布式网站架构设计与实践》

读后感 逐字逐句看完<大型分布式网站架构设计与实践>第2章,意犹未尽!如标题所言,这是一本“真材实料的分布式资料”,它与我看过的分布式书籍(如<大型网站系统与Java中间件实践>)不同,本书重技术兼并理论,给了新人入手的方向. 我最最感动的是书中介绍了很多分布式的“干货”:分布式缓存可以用memcache.数据库水平/垂直拆分技术.分布式存储可以HBase/Redis等.消息通道可以用ActiveMQ.搜索引擎Lucene/Solr等.当然每一种技术都不是一本书能说完的,作者至少给

阿里P8级架构师浅析秒杀架构设计实践思路

一.前言 一提到秒杀,都会想到高性能.高并发.高可用.大流量-.在电商体系中,交易系统占据了环节中的半壁江山.比如里面特别迷人的秒杀系统,那秒杀涉及到什么架构设计?会涉及到什么业务? 泥瓦匠自言自语:秒杀这个东西,一篇文章也说不完.我这一篇起个头,实践系列还在后面,敬请期待. 二.秒杀业务难点 秒杀业务难点,总结为两点 并发多读 并发少写 这不同于一些场景,优惠营销系统,只会是一个用户读多个数据,但也会大流量的读操作.但没有啥写操作. 并发多读,多用户并发读一个数据.比如华为手机只有一个库存,活

分布式架构设计之电商平台

分布式架构设计之电商平台 何为软件架构?不同人的答案会有所不同,而我认为一个好的软件架构除了要具备业务功能外,还应该具备一定的高性能.高可用.高伸缩性及可拓展等非功能需求.而软件架构是由业务架构和技术架构两部分组成,因为有了业务结构才会催生出软件架构,进而来满足业务上的需求,所以,在做软件架构设计时,需要分为业务架构设计和技术软件架构设计,二者不可分离哦!那么,接下来就以本人实际工作中的电商平台为例,进行说明电商平台架构设计,因为不同行业产品系统不同业务不同,而催生的系统软件的实现要求及架构设计