浅谈过载保护

雪球:对于时延敏感的服务,当外部请求超过系统处理能力。假设系统没有做对应保护,可能导致历史累计的超时请求达到一定规模。像雪球一样形成恶性循环。由于系统处理的每一个请求都由于超时而无效。系统对外呈现的服务能力为0,且这样的情况下不能自己主动恢复。

作者bison,腾讯后台开发技术总监。

  过载保护,看似简单。可是要做好并不easy。这里用两个以前经历的反面案例。给出过载保护的直观展现,并附上一点感想。

案例一基本情况

  例如以下图。进程A是一个单进程系统。通过udp套接字接收前端请求进行处理。在处理过程中。须要訪问后端系统B,是同步的方式訪问后端系统B,依据后端系统B的SLA,超时时间设置是100ms。

前端用户请求的超时时间是1s。

  进程A的时序是:

Step1: 从socket接收缓冲区接收用户请求

Step2: 进行本地逻辑处理

Step3: 发送请求到后端系统B

Step4: 等待后端系统B返回

Step5: 接收后端系统B的应答

Step6: 应答前端用户,回到step1处理下一个请求

正常情况下的负载

  正常情况下:

1、前端请求报文大小约100Bytes。

前端请求的峰值每分钟1800次。即峰值每秒30次。

2、后端系统B并行能力较高。每秒能够处理10000次以上,绝大多数请求处理时延在20ms内。

3、进程A在处理请求的时候。主要时延是在等待后端系统B,其它本地运算耗时很少,小于1ms

  这个时候,我们能够看出,系统工作良好,由于处理时延在20ms内,每秒进程A每秒中能够处理50个请求,足以将用户每秒峰值30个请求及时处理完。

导火索

  某天,后端系统B进行了新特性公布,因为内部逻辑变复杂,导致每一个请求处理时延从20ms延长至50ms,依据sla的100ms超时时间,这个时延仍然在正常范围内。当用户请求达到峰值时间点时。灾难出现了。用户每次操作都是“server超时无响应”。整个服务不可用。

过载分析

  当后端系统B处理时延延长至50ms的时候,进程A每秒仅仅能处理20个请求(1s / 50ms = 20 )。小于正常情况下的用户请求峰值30次/s。这个时候操作失败的用户往往会重试,我们观察到前端用户请求添加了6倍以上,达到200次/s。是进程A最大处理能力(20次/s)的10倍。

   这个时候为什么全部用户发现操作都是失败的呢? 为什么不是1/10的用户发现操作能成功呢? 由于请求量和处理能力之间巨大的差异使得5.6s内就迅速填满了socket接收缓冲区(平均能缓存1000个请求,1000/(200-20)=5.6s)。而且该缓冲区将一直保持满的状态。

这意味着,一个请求被追加到缓冲区里后。要等待50s(缓存1000个请求。每秒处理20个。须要50s)后才干被进程A 取出来处理,这个时候用户早就看到操作超时了。换句话说。进程A每次处理的请求,都已经是50s曾经产生的。进程A一直在做无用功。

雪球产生了。

案例二基本情况

  前端系统C通过udp訪问后端serverD,后端server D的udp套接字缓冲区为4MB。每一个请求大小约400字节。后端serverD偶尔处理超时情况下。前端系统C会重试。最多重试2次。

正常情况下的负载

  正常情况,后端serverD单机收到请求峰值为300次/s,后端serverD单机处理能力是每秒1500次。时延10ms左右。

这个时候工作正常。

导火索

  因为产品特性(比如提前通知大量用户,未来某某时刻将进行一项秒杀活动;类似奥运门票,大量用户提前得知信息:某日開始发售门票),大量的用户聚集在同一时刻发起了大量请求,超出了后台serverD的最大负载能力。操作响应失败的用户又重试, 中间系统的重试,进一步带来了更大量的请求(正常情况下的9倍)。导致全部用户操作都是失败的。

过载分析

  仅仅是导火索不一样。同案例一。巨大的请求和处理能力之间的鸿沟。导致后端serverD的4M大小的接收缓冲区迅速填满(4秒就填满)。且过载时间内,接收缓冲区一直都是满的。而处理完缓冲区内的请求,ServerD须要6秒以上(4MB / 400 / 1500 = 6.7S)。

所以serverD处理的请求都是6s之前放入缓冲区的,而该请求在最前端早已经超时。雪球形成了。

启发

1、  每一个系统,自己的最大处理能力是多少要做到清清楚楚。比如案例一中的前端进程A。他的最大处理能力不是50次/s,也不是20次/S,而是10次/S。由于它是单进程同步的訪问后端B, 且訪问后端B的超时时间是100ms,所以他的处理能力就是1S/100ms=10次/S。而平时处理能力表现为50次/S,仅仅是运气好。

2、  每一个系统要做好自我保护,量力而为。而不是尽力而为。

对于超出自己处理能力范围的请求。要勇于拒绝。

3、  每一个系统要有能力发现哪些是有效的请求,哪些是无效的请求。

上面两个案例中。过载的系统都不具备这中慧眼,逮着请求做死的处理。雪球时事实上是做无用功。

4、  前端系统有保护后端系统的义务。sla中承诺多大的能力。就仅仅给到后端多大的压力。这就要求每个前后端接口的地方,都有明白的负载约定,一环扣一环。

5、  当过载发生时。该拒绝的请求(1、超出整个系统处理能力范围的。2、已经超时的无效请求)越早拒绝越好。就像上海机场到市区的快速上。刚出机场就有电子公示牌显示,进入市区某某路段拥堵,请绕行。

6、  对于用户的重试行为,要适当的延缓。

比如登录发现后端响应失败,再又一次展现登录页面前,能够适当延时几秒钟,并展现进度条等友好界面。当多次重试还失败的情况下,要安抚用户。

7、  产品特性设计和公布上,要尽量避免某个时刻导致大量用户集体触发某些请求的设计。

公布的时候注意灰度。

8、  中间层server对后端发送请求。重试机制要慎用,一定要用的话要有严格频率控制。

9、  当雪球发生了,直接清空雪球队列(比如重新启动进程能够清空socket 缓冲区)可能是高速恢复的有效方法。

10、过载保护非常重要的一点,不是说要加强系统性能、容量,成功应答全部请求。而是保证在高压下,系统的服务能力不要陡降到0,而是顽强的对外展现最大有效处理能力。

  对于“每一个系统要有能力发现哪些是有效的请求。哪些是雪球无效的请求”。这里推荐一种方案:在该系统每一个机器上新增一个进程:interface进程。Interface进程可以高速的从socket缓冲区中取得请求,打上当前时间戳。压入channel。

业务处理进程从channel中获取请求和该请求的时间戳,假设发现时间戳早于当前时间减去超时时间(即已经超时,处理也没有意义)。就直接丢弃该请求,或者应答一个失败报文。

  Channel是一个先进先出的通信方式。能够是socket。也能够是共享内存、消息队列、或者管道,不限。

  Socket缓冲区要设置合理。假设过大,导致及时interface进程都须要处理长时间才干清空该队列,就不合适了。建议的大小上限是:缓存住超时时间内interface进程可以处理掉的请求个数(注意考虑网络通讯中的元数据)。

时间: 2024-10-13 09:33:52

浅谈过载保护的相关文章

.net中对象序列化技术浅谈

.net中对象序列化技术浅谈 2009-03-11 阅读2756评论2 序列化是将对象状态转换为可保持或传输的格式的过程.与序列化相对的是反序列化,它将流转换为对象.这两个过程结合起来,可以轻松地存储和传输数 据.例如,可以序列化一个对象,然后使用 HTTP 通过 Internet 在客户端和服务器之间传输该对象.反之,反序列化根据流重新构造对象.此外还可以将对象序列化后保存到本地,再次运行的时候可以从本地文件 中“恢复”对象到序列化之前的状态.在.net中有提供了几种序列化的方式:二进制序列化

浅谈——页面静态化

现在互联网发展越来越迅速,对网站的性能要求越来越高,也就是如何应对高并发量.像12306需要应付上亿人同时来抢票,淘宝双十一--所以,如何提高网站的性能,是做网站都需要考虑的. 首先网站性能优化的方面有很多:1,使用缓存,最传统的一级二级缓存:2,将服务和数据库分开,使用不同的服务器,分工更加明确,效率更加高:3,分布式,提供多台服务器,利用反向代理服务器nginx进行反向代理,将请求分散开来:4,数据库的读写分离,不同的数据库,将读操作和写操作分开,并实时同步即可:5,分布式缓存,使用memc

单页应用SEO浅谈

单页应用SEO浅谈 前言 单页应用(Single Page Application)越来越受web开发者欢迎,单页应用的体验可以模拟原生应用,一次开发,多端兼容.单页应用并不是一个全新发明的技术,而是随着互联网的发展,满足用户体验的一种综合技术. SEO 一直以来,搜索引擎优化(SEO)是开发者容易忽略的部分.SEO是针对搜索(Google.百度.雅虎搜索等)在技术细节上的优化,例如语义.搜索关键词与内容相关性.收录量.搜索排名等.SEO也是同行.市场竞争常用的的营销手段.Google.百度的搜

浅谈html标签

浅谈html各常用标签用法 标题标签:<h1>-<h6>来表示,使标题字体变粗. <br />换行标记 <hr />水平分隔符 &nbsp空格符 &copy版权符 <a href>a标签超链接 href可接链接地址 <p>段落标签<blockquote>引用标签及可用做缩进 <table>表格中的<ul>无序列表<ol>有序列表<dl>自定义列表<row

浅谈二维中的树状数组与线段树

一般来说,树状数组可以实现的东西线段树均可胜任,实际应用中也是如此.但是在二维中,线段树的操作变得太过复杂,更新子矩阵时第一维的lazy标记更是麻烦到不行. 但是树状数组在某些询问中又无法胜任,如最值等不符合区间减法的询问.此时就需要根据线段树与树状数组的优缺点来选择了. 做一下基本操作的对比,如下图. 因为线段树为自上向下更新,从而可以使用lazy标记使得矩阵的更新变的高校起来,几个不足就是代码长,代码长和代码长. 对于将将矩阵内元素变为某个值,因为树状数组自下向上更新,且要满足区间加法等限制

[nRF51822] 14、浅谈蓝牙低功耗(BLE)的几种常见的应用场景及架构(科普类干货)

蓝牙在短距离无线通信领域占据举足轻重的地位—— 从手机.平板.PC到车载设备, 到耳机.游戏手柄.音响.电视, 再到手环.电子秤.智能医疗器械(血糖仪.数字血压计.血气计.数字脉搏/心率监视器.数字体温计.耳温枪.皮肤水分计等), 再到智能家居等领域均占有一席之地. 而蓝牙低功耗(BLE)是在蓝牙4.0协议上修改以适用低功耗应用场景的一种蓝牙协议. 随着上一股智能消费类电子大潮的到来,BLE的各种应用也像雨后春笋般在市场上铺开. 如果想 紧跟蓝牙协议的最新动态 ,可以在https://www.b

浅谈C++容器动态内存管理的优化

在信息学竞赛中,C++的容器的用途非常广泛,但经常因常数过大而超时.怎样才能提高它们的效率呢? 我们知道,容器是存储同一类对象的对象,既然"对象"我们无法改变,那么我们只能从"存储"入手,不难想到,不同容器在实现上的根本区别是它们对应着不同的内存组织方式,内存管理无疑是这种实现的核心,所以优化内存管理是加快容器效率的最好途径之一. 一.内存分配器简介 怎样才能优化内存管理呢?很简单,C++为我们提供了这样的接口,我们可以通过自定义容器模板中的最后一个allocato

张小龙浅谈微信公众平台的意义

腾讯高级副总裁张小龙表示:微信公众平台,就是在移动互联网时代,让企业和个人以更简捷的形式提供服务给有需要的人. 张小龙浅谈微信公众平台的意义,布布扣,bubuko.com

浅谈数据库系统中的cache(转)

http://www.cnblogs.com/benshan/archive/2013/05/26/3099719.html 浅谈数据库系统中的cache(转) Cache和Buffer是两个不同的概念,简单的说,Cache是加速"读",而buffer是缓冲"写",前者解决读的问题,保存从磁盘上读出 的数据,后者是解决写的问题,保存即将要写入到磁盘上的数据.在很多情况下,这两个名词并没有严格区分,常常把读写混合类型称为buffer cache,本文后续的论述中,统一