雙 11 不僅是一場全球消費者的狂歡，也是對中國網際網路技術體系的實力檢驗。一下子幾千萬人湧進來買買買，這種真實的商業場景全世界一年也隻有一次。全球最大的支付平台之一， visa，在實驗室取得的測試資料是 5.6w 筆每秒；而雙十一這天，支付寶在實戰中達到了每秒鐘 8.6 萬筆，交易訂單的建立量更是達到了每秒鐘 14 萬筆，重新整理了網絡交易峰值的世界紀錄。 從 11 月 10 号深夜日常的交易數量陡然飙升到每秒鐘送出 14 萬筆訂單，這中間經曆了一個怎麼樣的過程？突然爆發的流量洪峰對業務鍊路的沖擊又有多大？除此之外，線上複雜性也是驚人的，僅僅一個購買動作，就包含從關鍵字搜尋，挑選商品，再到購物車結算，優惠抵扣，生成訂單，支付寶付款等一系列的流程，涉及上百個應用，鍊路上的任何一個”零件”出了問題，都有可能導緻交易的失敗。
其實我們的高可用架構團隊是由多個系統組成的，例如強弱依賴，彈性等，他們一定是互相作戰的。這個系列會主要介紹和雙十一比較密切的阿裡管控系統。 這個體系主要是由下面幾個系統組成的: 限流，降級以及流量排程，預案開關。
這篇文章裡面，我們先來看一下限流。
<a></a>
雙十一從一開始，就會有這樣的自帶屬性, 商家會提前1個星期甚至1個月，把自己參加活動的商品放出來；剁手黨呢，也會提早把這些商品挑選出來放在購物車裡面，但是他們一定是屏住不買，一直到0點0分才會開買。為什麼？提前一秒買沒有折扣，推遲一秒買可能商品就搶光了。
這個屬性，換算成工程師的語言來說，就是前一秒的qps(request per second,每秒到達的請求量)非常低，但是下一秒請求量就會飙高。我們再用資料來看一下雙十一當天的流量: 建立訂單的峰值時14w筆，天貓天貓移動端銷售金額突破1億僅用了75秒，銷售金額破百億僅用了38分鐘…這些資料，隻是當天流量的冰山一角。
如果這些流量沒有抗住，會出現什麼呢？想象一下這樣的場景，流量大，承載這些流量的機器負載會增高，如果這個應用的一兩台機器沒有率先扛不住了，那麼本來應該這些機器承載的流量就間接由其他的機器承擔了。本來這些機器就處于一種臨界狀态，這樣雪上加霜，那麼這些機器也挂了。就這樣1變2，2變4，4變8，整個叢集就如同雪崩一樣，都挂了。這樣誰也買不了東西了。
是以我們必須要有限流.
每一年雙十一0點0分的流量，對我們來說是寶貴的資料。有了這些資料，我們根據大資料對明年的雙十一的峰值進行評估，容量規劃。這是第一步。
第二步，就是梳理限流的使用者體驗了。一般來說，是不同的場景有不同的限流體驗。比如說，雙十一零點，使用者可能看到這個頁面，提示使用者等待并且重試，進而達到限流的效果
剛剛我們描述的情形，其實就屬于使用者洪峰。對于這種洪峰，我們需要考慮的因素是:
a) 允許通路的速率
b) 系統承受的最大洪峰
c) 洪峰爆發的間隔時間
對于這種流量，我們的處理是: 令牌桶限流
a) 允許通路的速率：令牌桶發放的速度 r
b) 系統承受的最大洪峰：當令牌桶滿的時候，洪峰到達，這個時候應用會承受最大的qps沖擊 桶的容量+該秒令牌桶發放的速度r
c) 洪峰爆發的間隔時間，也就是說，什麼時候令牌桶會再次滿, m<r，否則洪峰不會到來
除了0點0分的這種流量洪峰，還有系統之間的回調引起的洪峰。想象一下這樣的場景，物流系統為了處理發貨資訊，會隔一段時間調用交易系統來擷取交易資訊。為了提高效率，它每次批量查詢交易系統的資料。這樣，對交易系統也帶來了流量的沖擊。如果對這種回調不加以限制，那麼可能交易系統忙于處理這種回調洪峰，對使用者洪峰會疏于處理。
對于這種洪峰，有三種特色:
a) 有間隔頻率
b) 每次調用量大
c) 允許有延遲
對于這種洪峰，我們的處理方式是使用漏桶算法
這種算法也類似一個水桶，随機的往水桶裡面放水，但是以固定的速度往下漏水。和上一種的算法不一樣，主要是塑形。達到的效果是放給應用的流量，永遠是固定的。
那麼回答這個場景的問題,一個請求最遲延遲多久得到處理: τ/(𝑇−𝜎) τ是桶的容量，t是請求到來的速度，𝜎是輸出的速率
其實上面兩種場景，隻是限流場景的非常少的部分。對于不同的場景，需要使用不同的算法來進行限流。
例如，根據特定資源，比方說資料庫，緩存的運作情況來限流，或者根據線程池的使用情況來限流等等；從保護自己的服務水位的角度出發來限流，從保護自身應用不被不可靠的下遊應用托斯的角度來劃分，等等。
不同的場景，不同的目的，限流的方式一定是不一樣的。
限流架構主要由下面幾個部分組成
監控子產品
決策子產品
規則變更子產品
限流子產品
監控子產品主要用于采集系統的運作狀況。有了這些資料，才能對外進行處理。決策子產品主要是用于決定什麼場景用什麼限流方式，例如對待使用者洪峰，我們應該用令牌桶算法；對待系統回調，我們應該用漏桶算法。另外，做了決策之後，這些決策要能夠快速的推送到各個不同的機器。限流子產品則是對超過預期的請求的處理方式，可以簡單的限流，也可以排隊等。
處理的流程:
限流不是一招鮮的，但是限流的原則都是一樣的:
不同的場景不同的考慮因素
系統必須能夠迅速的對線上的情況做出快速響應
對超出預期的流量的處理方式要根據不同的場景來處理
另外，限流不是一個單獨作戰的系統，它需要結合其他的系統才能發揮更大的作用，例如強弱依賴，例如容量規劃，等等。
我們會在下一篇文章裡面介紹其他的系統。
最後給耐心看到這裡的讀者一個彩蛋，
這張圖是我們部門在2015年雙十一戰鬥結束的黎明的合影。請找出其中的若幹個技術大牛！說不定你心儀已久的大牛已經在你眼前了，聯系我們來驗證你的猜想是否正确！
歡迎加入我們的團隊，請聯系： shutong.dy[at]alibaba-inc.com 叔同