阿里管控系统靠什么扛住全球最大规模的流量洪峰?

双 11 不仅是一场全球消费者的狂欢,也是对中国互联网技术体系的实力检验。一下子几千万人涌进来买买买,这种真实的商业场景全世界一年也只有一次。

全球最大的支付平台之一, Visa,在实验室取得的测试数据是 5.6w 笔每秒;而双十一这天,支付宝在实战中达到了每秒钟 8.6 万笔,交易订单的创建量更是达到了每秒钟 14 万笔,刷新了网络交易峰值的世界纪录。 从 11 月 10 号深夜日常的交易数量陡然飙升到每秒钟提交 14 万笔订单,这中间经历了一个怎么样的过程?突然爆发的流量洪峰对业务链路的冲击又有多大?

除此之外,线上复杂性也是惊人的,仅仅一个购买动作,就包含从关键字搜索,挑选商品,再到购物车结算,优惠抵扣,生成订单,支付宝付款等一系列的流程,涉及上百个应用,链路上的任何一个"零件"出了问题,都有可能导致交易的失败。

限流的必要性

双十一从一开始,就会有这样的自带属性, 商家会提前1个星期甚至1个月,把自己参加活动的商品放出来;剁手党呢,也会提早把这些商品挑选出来放在购物车里面,但是他们一定是屏住不买,一直到0点0分才会开买。为什么?提前一秒买没有折扣,推迟一秒买可能商品就抢光了。

这个属性,换算成工程师的语言来说,就是前一秒的qps(request per second,每秒到达的请求量)非常低,但是下一秒请求量就会飙高。我们再用数据来看一下双十一当天的流量: 创建订单的峰值时14w笔,天猫天猫移动端销售金额突破1亿仅用了75秒,销售金额破百亿仅用了38分钟…这些数据,只是当天流量的冰山一角。

如果这些流量没有抗住,会出现什么呢?想象一下这样的场景,流量大,承载这些流量的机器负载会增高,如果这个应用的一两台机器没有率先扛不住了,那么本来应该这些机器承载的流量就间接由其他的机器承担了。本来这些机器就处于一种临界状态,这样雪上加霜,那么这些机器也挂了。就这样1变2,2变4,4变8,整个集群就如同雪崩一样,都挂了。这样谁也买不了东西了。

所以我们必须要有限流。

如何限流

每一年双十一0点0分的流量,对我们来说是宝贵的数据。有了这些数据,我们根据大数据对明年的双十一的峰值进行评估,容量规划。这是第一步。

第二步,就是梳理限流的用户体验了。一般来说,是不同的场景有不同的限流体验。比如说,双十一零点,用户可能看到这个页面,提示用户等待并且重试,从而达到限流的效果。

限流场景

1. 用户洪峰

刚刚我们描述的情形,其实就属于用户洪峰。对于这种洪峰,我们需要考虑的因素是:

  • 允许访问的速率

  • 系统承受的最大洪峰

  • 洪峰爆发的间隔时间

对于这种流量,我们的处理是:


令牌桶限流

对于这个算法,我们来看一下:

  • 允许访问的速率:令牌桶发放的速度 r

  • 系统承受的最大洪峰:当令牌桶满的时候,洪峰到达,这个时候应用会承受最大的qps冲击 桶的容量+该秒令牌桶发放的速度r

  • 洪峰爆发的间隔时间,也就是说,什么时候令牌桶会再次满,m<r,否则洪峰不会到来

2. 回调洪峰

除了0点0分的这种流量洪峰,还有系统之间的回调引起的洪峰。想象一下这样的场景,物流系统为了处理发货信息,会隔一段时间调用交易系统来获取交易信息。为了提高效率,它每次批量查询交易系统的数据。这样,对交易系统也带来了流量的冲击。如果对这种回调不加以限制,那么可能交易系统忙于处理这种回调洪峰,对用户洪峰会疏于处理。

对于这种洪峰,有三种特色:

  • 有间隔频率

  • 每次调用量大

  • 允许有延迟

对于这种洪峰,我们的处理方式是使用漏桶算法


这种算法也类似一个水桶,随机的往水桶里面放水,但是以固定的速度往下漏水。和上一种的算法不一样,主要是塑形。达到的效果是放给应用的流量,永远是固定的。

那么回答这个场景的问题,一个请求最迟延迟多久得到处理:τ/(Τ—σ),τ是桶的容量,T是请求到来的速度,σ是输出的速率

3. 其他场景

其实上面两种场景,只是限流场景的非常少的部分。对于不同的场景,需要使用不同的算法来进行限流。

例如,根据特定资源,比方说数据库,缓存的运行情况来限流,或者根据线程池的使用情况来限流等等;从保护自己的服务水位的角度出发来限流,从保护自身应用不被不可靠的下游应用托斯的角度来划分,等等。

不同的场景,不同的目的,限流的方式一定是不一样的。

限流框架

限流框架主要由下面几个部分组成

  1. 监控模块

  2. 决策模块

  3. 规则变更模块

  4. 限流模块

监控模块主要用于采集系统的运行状况。有了这些数据,才能对外进行处理。决策模块主要是用于决定什么场景用什么限流方式,例如对待用户洪峰,我们应该用令牌桶算法;对待系统回调,我们应该用漏桶算法。另外,做了决策之后,这些决策要能够快速的推送到各个不同的机器。限流模块则是对超过预期的请求的处理方式,可以简单的限流,也可以排队等。

处理的流程:


总结

限流不是一招鲜的,但是限流的原则都是一样的:

  1. 不同的场景不同的考虑因素

  2. 系统必须能够迅速的对线上的情况做出快速响应

  3. 对超出预期的流量的处理方式要根据不同的场景来处理

另外,限流不是一个单独作战的系统,它需要结合其他的系统才能发挥更大的作用,例如强弱依赖,例如容量规划,等等。


文章标签: 阿里巴巴 管控 限流


关注微信公众号“架构说”,加入Q群微群,让架构师带你飞︿( ̄︶ ̄)︿。


原文链接: 阅读原文
免责申明: 架构说任何转载的文章都会明确标注原文链接。如有侵权,请与本站联系。
转载说明: 架构说原创文章转载时请务必注明文章作者、链接和来源。