63分59秒1000億，如何抗住雙11高并發流量？

作者：邴越，某電商平臺架構師，曾任阿里巴巴中臺資深開發工程師，云棲社區專家，關注分布式系統和高可用架構。

前言

今年雙 11 全民購物狂歡節進入第十一個年頭，1 分 36 秒，交易額沖到 100 億 ！比 2018 年快了近 30 秒，比 2017 年快了近 1 分半！這個速度再次刷新天貓雙 11 成交總額破 100 億的紀錄。

那么如何抗住雙 11 高并發流量？接下來讓我們一起來聊聊高可用的“大殺器”限流降級技術。

服務等級協議

我們常說的 N 個 9，就是對 SLA 的一個描述。SLA 全稱是 Service Level Agreement，翻譯為服務水平協議，也稱服務等級協議，它表明了公有云提供服務的等級以及質量。

例如阿里云對外承諾的就是一個服務周期內集群服務可用性不低于 99.99%，如果低于這個標準，云服務公司就需要賠償客戶的損失。

做到 4 個 9 夠好了嗎

對互聯網公司來說，SLA 就是網站或者 API 服務可用性的一個保證。

9 越多代表全年服務可用時間越長服務更可靠，4 個 9 的服務可用性，聽起來已經很高了，但對于實際的業務場景，這個值可能并不夠。

我們來做一個簡單的計算，假設一個核心鏈路依賴 20 個服務，強依賴同時沒有配置任何降級，并且這 20 個服務的可用性達到 4 個 9，也就是 99.99%。

那這個核心鏈路的可用性只有 99.99 的 20 次方=99.8%，如果有 10 億次請求則有 3,000,000 次的失敗請求，理想狀況下，每年還是有 17 小時服務不可用。

這是一個理想的估算，在實際的生產環境中，由于服務發布，宕機等各種各樣的原因，情況肯定會比這個更差。

對于一些比較敏感的業務，比如金融，或是對服務穩定要求較高的行業，比如訂單或者支付業務，這樣的情況是不能接受的。

微服務的雪崩效應

除了對服務可用性的追求，微服務架構一個繞不過去的問題就是服務雪崩。

在一個調用鏈路上，微服務架構各個服務之間組成了一個松散的整體，牽一發而動全身，服務雪崩是一個多級傳導的過程。

首先是某個服務提供者不可用，由于大量超時等待，繼而導致服務調用者不可用，并且在整個鏈路上傳導，繼而導致系統癱瘓。

限流降級怎么做

如同上面我們分析的，在大規模微服務架構的場景下，避免服務出現雪崩，要減少停機時間，要盡可能的提高服務可用性。

提高服務可用性，可以從很多方向入手，比如緩存、池化、異步化、負載均衡、隊列和降級熔斷等手段。

緩存以及隊列等手段，增加系統的容量。限流和降級則是關心在到達系統瓶頸時系統的響應，更看重穩定性。

緩存和異步等提高系統的戰力，限流降級關注的是防御。限流和降級，具體實施方法可以歸納為八字箴言，分別是限流，降級，熔斷和隔離。

限流和降級

限流顧名思義，提前對各個類型的請求設置最高的 QPS 閾值，若高于設置的閾值則對該請求直接返回，不再調用后續資源。

限流需要結合壓測等，了解系統的最高水位，也是在實際開發中應用最多的一種穩定性保障手段。

降級則是當服務器壓力劇增的情況下，根據當前業務情況及流量對一些服務和頁面有策略的降級，以此釋放服務器資源以保證核心任務的正常運行。

從降級配置方式上，降級一般可以分為主動降級和自動降級。主動降級是提前配置，自動降級則是系統發生故障時，如超時或者頻繁失敗，自動降級。

其中，自動降級，又可以分為以下策略：

• 超時降級

• 失敗次數降級

• 故障降級

在系統設計中，降級一般是結合系統配置中心，通過配置中心進行推送，下面是一個典型的降級通知設計。

熔斷隔離

如果某個目標服務調用慢或者有大量超時，此時熔斷該服務的調用，對于后續調用請求，不在繼續調用目標服務，直接返回，快速釋放資源。

熔斷一般需要設置不同的恢復策略，如果目標服務情況好轉則恢復調用。歡迎大家關注我的公種浩【程序員追風】，文章都會在里面更新，整理的資料也會放在里面。

服務隔離與前面的三個略有區別，我們的系統通常提供了不止一個服務，但是這些服務在運行時是部署在一個實例，或者一臺物理機上面的。

如果不對服務資源做隔離，一旦一個服務出現了問題，整個系統的穩定性都會受到影響！服務隔離的目的就是避免服務之間相互影響。

一般來說，隔離要關注兩方面，一個是在哪里進行隔離，另外一個是隔離哪些資源。

何處隔離：一次服務調用，涉及到的是服務提供方和調用方，我們所指的資源，也是兩方的服務器等資源，服務隔離通常可以從提供方和調用方兩個方面入手。

隔離什么：廣義的服務隔離，不僅包括服務器資源，還包括數據庫分庫，緩存，索引等，這里我們只關注服務層面的隔離。

降級和熔斷的區別

服務降級和熔斷在概念上比較相近，通過兩個場景，談談我自己的理解。

熔斷，一般是停止服務：典型的就是股市的熔斷，如果大盤不受控制，直接休市，不提供服務，是保護大盤的一種方式。

降級，通常是有備用方案：從北京到濟南，下雨導致航班延誤，我可以乘坐高鐵，如果高鐵票買不到，也可以乘坐汽車或者開車過去。

兩者的區別：降級一般是主動的，有預見性的，熔斷通常是被動的，服務 A 降級以后，一般會有服務 B 來代替，而熔斷通常是針對核心鏈路的處理。

在實際開發中，熔斷的下一步通常就是降級。

常用限流算法設計

剛才講了限流的概念，那么怎樣判斷系統到達設置的流量閾值了？這就需要一些限流策略來支持，不同的限流算法有不同的特點，平滑程度也不同。

計數器法

計數器法是限流算法里最簡單也是最容易實現的一種算法。

假設一個接口限制一分鐘內的訪問次數不能超過 100 個，維護一個計數器，每次有新的請求過來，計數器加一。

這時候判斷，如果計數器的值小于限流值，并且與上一次請求的時間間隔還在一分鐘內，允許請求通過，否則拒絕請求，如果超出了時間間隔，要將計數器清零。

public?class?CounterLimiter?{

????//初始時間
????private?static?long?startTime?=?System.currentTimeMillis();

????//初始計數值
????private?static?final?AtomicInteger?ZERO?=?new?AtomicInteger(0);

????//時間窗口限制
????private?static?final?long?interval?=?10000;

????//限制通過請求
????private?static?int?limit?=?100;

????//請求計數
????private?AtomicInteger?requestCount?=?ZERO;

????//獲取限流
????public?boolean?tryAcquire()?{

????????long?now?=?System.currentTimeMillis();

????????//在時間窗口內
????????if?(now?<?startTime?+?interval)?{

????????????//判斷是否超過最大請求
????????????if?(requestCount.get()?<?limit)?{
????????????????requestCount.incrementAndGet();
????????????????return?true;
????????????}
????????????return?false;

????????}?else?{

????????????//超時重置
????????????startTime?=?now;
????????????requestCount?=?ZERO;
????????????return?true;
????????}

????}
}

計數器限流可以比較容易的應用在分布式環境中，用一個單點的存儲來保存計數值，比如用 Redis，并且設置自動過期時間，這時候就可以統計整個集群的流量，并且進行限流。

計數器方式的缺點是不能處理臨界問題，或者說限流策略不夠平滑。歡迎大家關注我的公種浩【程序員追風】，文章都會在里面更新，整理的資料也會放在里面。

假設在限流臨界點的前后，分別發送 100 個請求，實際上在計數器置 0 前后的極短時間里，處理了 200 個請求，這是一個瞬時的高峰，可能會超過系統的限制。

計數器限流允許出現 2*permitsPerSecond 的突發流量，可以使用滑動窗口算法去優化，具體不展開。

漏桶算法

假設我們有一個固定容量的桶，桶底部可以漏水（忽略氣壓等，不是物理問題），并且這個漏水的速率可控的，那么我們可以通過這個桶來控制請求速度，也就是漏水的速度。

我們不關心流進來的水，也就是外部請求有多少，桶滿了之后，多余的水會溢出。

漏桶算法的示意圖如下：

將算法中的水換成實際應用中的請求，可以看到漏桶算法從入口限制了請求的速度。

使用漏桶算法，我們可以保證接口會以一個常速速率來處理請求，所以漏桶算法不會出現臨界問題。

這里簡單實現一下，也可以使用 Guava 的 SmoothWarmingUp 類，可以更好的控制漏桶算法：

public?class?LeakyLimiter?{

????//桶的容量
????private?int?capacity;

????//漏水速度
????private?int?ratePerMillSecond;

????//水量
????private?double?water;

????//上次漏水時間
????private?long?lastLeakTime;

????public?LeakyLimiter(int?capacity,?int?ratePerMillSecond)?{

????????this.capacity?=?capacity;
????????this.ratePerMillSecond?=?ratePerMillSecond;
????????this.water?=?0;
????}


????//獲取限流
????public?boolean?tryAcquire()?{

????????//執行漏水，更新剩余水量
????????refresh();

????????//嘗試加水，水滿則拒絕
????????if?(water?+?1?>?capacity)?{
????????????return?false;
????????}

????????water?=?water?+?1;
????????return?true;

????}

????private?void?refresh()?{
????????//當前時間
????????long?currentTime?=?System.currentTimeMillis();

????????if?(currentTime?>?lastLeakTime)?{

????????????//距上次漏水的時間間隔
????????????long?millisSinceLastLeak?=?currentTime?-?lastLeakTime;
????????????long?leaks?=?millisSinceLastLeak?*?ratePerMillSecond;

????????????//允許漏水
????????????if?(leaks?>?0)?{
????????????????//已經漏光
????????????????if?(water?<=?leaks)?{
????????????????????water?=?0;
????????????????}?else?{
????????????????????water?=?water?-?leaks;
????????????????}
????????????????this.lastLeakTime?=?currentTime;
????????????}
????????}
????}
}

令牌桶算法

漏桶是控制水流入的速度，令牌桶則是控制留出，通過控制 Token，調節流量。

假設一個大小恒定的桶，桶里存放著令牌（Token）。桶一開始是空的，現在以一個固定的速率往桶里填充，直到達到桶的容量，多余的令牌將會被丟棄。

如果令牌不被消耗，或者被消耗的速度小于產生的速度，令牌就會不斷地增多，直到把桶填滿。后面再產生的令牌就會從桶中溢出。

最后桶中可以保存的最大令牌數永遠不會超過桶的大小，每當一個請求過來時，就會嘗試從桶里移除一個令牌，如果沒有令牌的話，請求無法通過。

public?class?TokenBucketLimiter?{

????private?long?capacity;
????private?long?windowTimeInSeconds;
????long?lastRefillTimeStamp;
????long?refillCountPerSecond;
????long?availableTokens;

????public?TokenBucketLimiter(long?capacity,?long?windowTimeInSeconds)?{
????????this.capacity?=?capacity;
????????this.windowTimeInSeconds?=?windowTimeInSeconds;
????????lastRefillTimeStamp?=?System.currentTimeMillis();
????????refillCountPerSecond?=?capacity?/?windowTimeInSeconds;
????????availableTokens?=?0;
????}

????public?long?getAvailableTokens()?{
????????return?this.availableTokens;
????}

????public?boolean?tryAcquire()?{

????????//更新令牌桶
????????refill();

????????if?(availableTokens?>?0)?{
????????????--availableTokens;
????????????return?true;
????????}?else?{
????????????return?false;
????????}
????}


????private?void?refill()?{
????????long?now?=?System.currentTimeMillis();

????????if?(now?>?lastRefillTimeStamp)?{

????????????long?elapsedTime?=?now?-?lastRefillTimeStamp;

????????????int?tokensToBeAdded?=?(int)?((elapsedTime?/?1000)?*?refillCountPerSecond);

????????????if?(tokensToBeAdded?>?0)?{
????????????????availableTokens?=?Math.min(capacity,?availableTokens?+?tokensToBeAdded);
????????????????lastRefillTimeStamp?=?now;
????????????}
????????}
????}

}

這兩種算法的主要區別在于漏桶算法能夠強行限制數據的傳輸速率，而令牌桶算法在能夠限制數據的平均傳輸速率外，還允許某種程度的突發傳輸。

在令牌桶算法中，只要令牌桶中存在令牌，那么就允許突發地傳輸數據直到達到用戶配置的門限，因此它適合于具有突發特性的流量。

漏桶和令牌桶的比較

漏桶和令牌桶算法實現可以一樣，但是方向是相反的，對于相同的參數得到的限流效果是一樣的。

主要區別在于令牌桶允許一定程度的突發，漏桶主要目的是平滑流入速率，考慮一個臨界場景，令牌桶內積累了 100 個 Token，可以在一瞬間通過。

但是因為下一秒產生 Token 的速度是固定的，所以令牌桶允許出現瞬間出現 permitsPerSecond 的流量，但是不會出現 2*permitsPerSecond 的流量，漏桶的速度則始終是平滑的。

使用 RateLimiter 實現限流

Google 開源工具包 Guava 提供了限流工具類 RateLimiter，該類基于令牌桶算法實現流量限制，使用方便。

RateLimiter 使用的是令牌桶的流控算法，RateLimiter 會按照一定的頻率往桶里扔令牌，線程拿到令牌才能執行。歡迎大家關注我的公種浩【程序員追風】，文章都會在里面更新，整理的資料也會放在里面。

比如你希望自己的應用程序 QPS 不要超過 1000，那么 RateLimiter 設置 1000 的速率后，就會每秒往桶里扔 1000 個令牌，看下方法的說明：

RateLimter 提供的 API 可以直接應用，其中 acquire 會阻塞，類似 JUC 的信號量 Semphore，tryAcquire 方法則是非阻塞的：

public?class?RateLimiterTest?{

????public?static?void?main(String[]?args)?throws?InterruptedException?{

????????//允許10個，permitsPerSecond
????????RateLimiter?limiter?=?RateLimiter.create(10);

????????for(int?i=1;i<20;i++){
????????????if?(limiter.tryAcquire(1)){
????????????????System.out.println("第"+i+"次請求成功");
????????????}else{
????????????????System.out.println("第"+i+"次請求拒絕");
????????????}
????????}
????}
}

總結

本文從服務可用性開始，分析了在業務高峰期通過限流降級保障服務高可用的重要性。

接下來分別探討了限流，降級，熔斷，隔離的概念和應用，并且介紹了常用的限流策略。