双 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. 用户洪峰
刚刚我们描述的情形，其实就属于用户洪峰。对于这种洪峰，我们需要考虑的因素是:
a) 允许访问的速率
b) 系统承受的最大洪峰
c) 洪峰爆发的间隔时间
对于这种流量，我们的处理是: 令牌桶限流
a) 允许访问的速率：令牌桶发放的速度 r
b) 系统承受的最大洪峰：当令牌桶满的时候，洪峰到达，这个时候应用会承受最大的qps冲击 桶的容量+该秒令牌桶发放的速度r
c) 洪峰爆发的间隔时间，也就是说，什么时候令牌桶会再次满, m<r，否则洪峰不会到来
2. 回调洪峰
除了0点0分的这种流量洪峰，还有系统之间的回调引起的洪峰。想象一下这样的场景，物流系统为了处理发货信息，会隔一段时间调用交易系统来获取交易信息。为了提高效率，它每次批量查询交易系统的数据。这样，对交易系统也带来了流量的冲击。如果对这种回调不加以限制，那么可能交易系统忙于处理这种回调洪峰，对用户洪峰会疏于处理。
对于这种洪峰，有三种特色:
a) 有间隔频率
b) 每次调用量大
c) 允许有延迟
对于这种洪峰，我们的处理方式是使用漏桶算法
这种算法也类似一个水桶，随机的往水桶里面放水，但是以固定的速度往下漏水。和上一种的算法不一样，主要是塑形。达到的效果是放给应用的流量，永远是固定的。
那么回答这个场景的问题,一个请求最迟延迟多久得到处理: τ/(