在開發高併發系統時有三把利器用來保護系統：快取、降級和限流。之前已經有一些文章介紹過快取和限流了。本文將詳細聊聊降級。當訪問量劇增、服務出現問題（如響應時間慢或不響應）或非核心服務影響到核心流程的效能時，仍然需要保證服務還是可用的，即使是有損服務。系統可以根據一些關鍵資料進行自動降級，也可以配置開關實現人工降級。本文將介紹一些筆者在實際工作中遇到的或見到過的一些降級方案供大家參考。

降級的最終目的是保證核心服務可用，即使是有損的。而且有些服務是無法降級的（如加入購物車、結算）。

降級預案

在進行降級之前要對系統進行梳理，看看系統是不是可以丟卒保帥；從而梳理出哪些必須誓死保護，哪些可降級；比如可以參考日誌級別設定預案：

一般：比如有些服務偶爾因為網路抖動或者服務正在上線而超時，可以自動降級；

警告：有些服務在一段時間內成功率有波動（如在95~100%之間），可以自動降級或人工降級，併發送告警；

錯誤：比如可用率低於90%，或者資料庫連線池被打爆了，或者訪問量突然猛增到系統能承受的最大閥值，此時可以根據情況自動降級或者人工降級；

嚴重錯誤：比如因為特殊原因資料錯誤了，此時需要緊急人工降級。

降級按照是否自動化可分為：自動開關降級和人工開關降級。

降級按照功能可分為：讀服務降級、寫服務降級。

降級按照處於的系統層次可分為：多級降級。

降級的功能點主要從服務端鏈路考慮，即根據使用者訪問的服務呼叫鏈路來梳理哪裡需要降級：

頁面降級：在大促或者某些特殊情況下，某些頁面佔用了一些稀缺服務資源，在緊急情況下可以對其整個降級，以達到丟卒保帥；

頁面片段降級：比如商品詳情頁中的商家部分因為資料錯誤了，此時需要對其進行降級；

頁面非同步請求降級：比如商品詳情頁上有推薦資訊/配送至等非同步載入的請求，如果這些資訊響應慢或者後端服務有問題，可以進行降級；

服務功能降級：比如渲染商品詳情頁時需要呼叫一些不太重要的服務：相關分類、熱銷榜等，而這些服務在異常情況下直接不獲取，即降級即可；

讀降級：比如多級快取模式，如果後端服務有問題，可以降級為只讀快取，這種方式適用於對讀一致性要求不高的場景；

寫降級：

爬蟲降級：在大促活動時，可以將爬蟲流量導向靜態頁或者返回空資料，從而保護後端稀缺資源。

自動開關降級

自動降級是根據系統負載、資源使用情況、SLA等指標進行降級。

超時降級

當訪問的資料庫/http服務/遠端呼叫響應慢或者長時間響應慢，且該服務不是核心服務的話可以在超時後自動降級；比如商品詳情頁上有推薦內容/評價，但是推薦內容/評價暫時不展示對使用者購物流程不會產生很大的影響；對於這種服務是可以超時降級的。如果是呼叫別人的遠端服務，和對方定義一個服務響應最大時間，如果超時了則自動降級。

統計失敗次數降級

有時候依賴一些不穩定的API，比如呼叫外部機票服務，當失敗呼叫次數達到一定閥值自動降級；然後通過非同步執行緒去探測服務是否恢復了，則取消降級。

故障降級

比如要呼叫的遠端服務掛掉了（網路故障、DNS故障、http服務返回錯誤的狀態碼、rpc服務丟擲異常），則可以直接降級。降級後的處理方案有：預設值（比如庫存服務掛了，返回預設現貨）、兜底資料（比如廣告掛了，返回提前準備好的一些靜態頁面）、快取（之前暫存的一些快取資料）。

限流降級

當我們去秒殺或者搶購一些限購商品時，此時可能會因為訪問量太大而導致系統崩潰，此時開發者會使用限流來進行限制訪問量，當達到限流閥值，後續請求會被降級；降級後的處理方案可以是：排隊頁面（將使用者導流到排隊頁面等一會重試）、無貨（直接告知使用者沒貨了）、錯誤頁（如活動太火爆了，稍後重試）。

人工開關降級

在大促期間通過監控發現線上的一些服務存在問題，這個時候需要暫時將這些服務摘掉；還有有時候通過任務系統呼叫一些服務，但是服務依賴的資料庫可能存在：網絡卡被打滿了、掛掉了或者很多慢查詢，此時需要暫停下任務系統讓服務方進行處理；還有發現突然呼叫量太大，可能需要改變處理方式（比如同步轉換為非同步）；此時就可以使用開關來完成降級。開關可以存放到配置檔案、存放到資料庫、存放到Redis/ZooKeeper；如果不是存放在本地，可以定期同步開關資料（比如1秒同步一次）。然後通過判斷某個KEY的值來決定是否降級。

另外對於新開發的服務想上線進行灰度測試；但是不太確定該服務的邏輯是否正確，此時就需要設定開關，當新服務有問題可以通過開關切換回老服務。還有多機房服務，如果某個機房掛掉了，此時需要將一個機房的服務切到另一個機房，此時也可以通過開關完成切換。

還有一些是因為功能問題需要暫時遮蔽掉某些功能，比如商品規格引數資料有問題，資料問題不能用回滾解決，此時需要開關控制降級。

讀服務降級

對於讀服務降級一般採用的策略有：暫時切換讀（降級到讀快取、降級到走靜態化）、暫時遮蔽讀（遮蔽讀入口、遮蔽某個讀服務）。在《應用多級快取模式支撐海量讀服務》中曾經介紹過讀服務，即接入層快取-->應用層本地快取-->分散式快取-->RPC服務/DB，我們會在接入層、應用層設定開關，當分散式快取、RPC服務/DB有問題自動降級為不呼叫。當然這種情況適用於對讀一致性要求不高的場景。

頁面降級、頁面片段降級、頁面非同步請求降級都是讀服務降級，目的是丟卒保帥（比如因為這些服務也要使用核心資源、或者佔了頻寬影響到核心服務）或者因資料問題暫時遮蔽。

還有一種是頁面靜態化場景：

動態化降級為靜態化：比如平時網站可以走動態化渲染商品詳情頁，但是到了大促來臨之際可以將其切換為靜態化來減少對核心資源的佔用，而且可以提升效能；其他還有如列表頁、首頁、頻道頁都可以這麼玩；可以通過一個程式定期的推送靜態頁到快取或者生成到磁碟，出問題時直接切過去；

靜態化降級為動態化：比如當使用靜態化來實現商品詳情頁架構時，平時使用靜態化來提供服務，但是因為特殊原因靜態化頁面有問題了，需要暫時切換回動態化來保證服務正確性。

以上都保證出問題了有預案，使用者還是可以使用網站，不影響使用者購物。

寫服務降級

寫服務在大多數場景下是不可降級的，不過可以通過一些迂迴戰術來解決問題。比如將同步操作轉換為非同步操作，或者限制寫的量/比例。

比如扣減庫存一般這樣操作：

方案1：

1、扣減DB庫存，2、扣減成功後更新redis中的庫存；

方案2：

1、扣減Redis庫存，2、同步扣減DB庫存，如果扣減失敗則回滾Redis庫存；

前兩種方案非常依賴DB，假設此時DB效能跟不上則扣減庫存就會遇到問題；因此我們可以想到方案3：

1、扣減Redis庫存，2、正常同步扣減DB庫存，效能扛不住時降級為傳送一條扣減DB庫存的訊息，然後非同步進行DB庫存扣減實現最終一致即可；

這種方式傳送扣減DB庫存訊息也可能成為瓶頸；這種情況我們可以考慮方案4：

1、扣減Redis庫存，2、正常同步扣減DB庫存，效能扛不住時降級為寫扣減DB庫存訊息到本機，然後本機通過非同步進行DB庫存扣減來實現最終一致性。

也就是說正常情況可以同步扣減庫存，在效能扛不住時降級為非同步；另外如果是秒殺場景可以直接降級為非同步，從而保護系統。還有如下單操作可以在大促時暫時降級將下單資料寫入Redis，然後等峰值過去了再同步回DB，當然也有更好的解決方案，但是更復雜，不是本文的重點。

還有如使用者評價，如果評價量太大，也可以把評價從同步寫降級為非同步寫。當然也可以對評價按鈕進行按比例開放（比如一些人的看不到評價操作按鈕）。比如評價成功後會發一些獎勵，在必要的時候降級同步到非同步。

多級降級

快取是離使用者最近越高效；而降級是離使用者越近越能對系統保護的好。因為業務的複雜性導致越到後端QPS/TPS越低。

頁面js降級開關：主要控制頁面功能的降級，在頁面中通過JS指令碼部署功能降級開關，在適當時機開啟/關閉開關；

接入層降級開關：主要控制請求入口的降級，請求進入後會首先進入接入層，在接入層可以配置功能降級開關，可以根據實際情況進行自動/人工降級；這個可以參考《京東商品詳情頁服務閉環實踐》，尤其在後端應用服務出問題時，通過接入層降級從而給應用服務有足夠的時間恢復服務；

應用層降級開關：主要控制業務的降級，在應用中配置相應的功能開關，根據實際業務情況進行自動/人工降級。

部落格分類：  
• 架構

在開發高併發系統時有三把利器用來保護系統：快取、降級和限流。快取的目的是提升系統訪問速度和增大系統能處理的容量，可謂是抗高併發流量的銀彈；而降級是當服務出問題或者影響到核心流程的效能則需要暫時遮蔽掉，待高峰或者問題解決後再開啟；而有些場景並不能用快取和降級來解決，比如稀缺資源（秒殺、搶購）、寫服務（如評論、下單）、頻繁的複雜查詢（評論的最後幾頁），因此需有一種手段來限制這些場景的併發/請求量，即限流。

限流的目的是通過對併發訪問/請求進行限速或者一個時間視窗內的的請求進行限速來保護系統，一旦達到限制速率則可以拒絕服務（定向到錯誤頁或告知資源沒有了）、排隊或等待（比如秒殺、評論、下單）、降級（返回兜底資料或預設資料，如商品詳情頁庫存預設有貨）。

一般開發高併發系統常見的限流有：限制總併發數（比如資料庫連線池、執行緒池）、限制瞬時併發數（如nginx的limit_conn模組，用來限制瞬時併發連線數）、限制時間視窗內的平均速率（如Guava的RateLimiter、nginx的limit_req模組，限制每秒的平均速率）；其他還有如限制遠端介面呼叫速率、限制MQ的消費速率。另外還可以根據網路連線數、網路流量、CPU或記憶體負載等來限流。

先有快取這個銀彈，後有限流來應對618、雙十一高併發流量，在處理高併發問題上可以說是如虎添翼，不用擔心瞬間流量導致系統掛掉或雪崩，最終做到有損服務而不是不服務；限流需要評估好，不可亂用，否則會正常流量出現一些奇怪的問題而導致使用者抱怨。

在實際應用時也不要太糾結演算法問題，因為一些限流演算法實現是一樣的只是描述不一樣；具體使用哪種限流技術還是要根據實際場景來選擇，不要一味去找最佳模式，白貓黑貓能解決問題的就是好貓。

因在實際工作中遇到過許多人來問如何進行限流，因此本文會詳細介紹各種限流手段。那麼接下來我們從限流演算法、應用級限流、分散式限流、接入層限流來詳細學習下限流技術手段。

限流演算法

常見的限流演算法有：令牌桶、漏桶。計數器也可以進行粗暴限流實現。

令牌桶演算法

令牌桶演算法是一個存放固定容量令牌的桶，按照固定速率往桶裡新增令牌。令牌桶演算法的描述如下：

• 假設限制2r/s，則按照500毫秒的固定速率往桶中新增令牌；

• 桶中最多存放b個令牌，當桶滿時，新新增的令牌被丟棄或拒絕；

• 當一個n個位元組大小的資料包到達，將從桶中刪除n個令牌，接著資料包被髮送到網路上；

• 如果桶中的令牌不足n個，則不會刪除令牌，且該資料包將被限流（要麼丟棄，要麼緩衝區等待）。

漏桶演算法

漏桶作為計量工具（The Leaky Bucket Algorithm as a Meter）時，可以用於流量整形（Traffic Shaping）和流量控制（TrafficPolicing），漏桶演算法的描述如下：

• 一個固定容量的漏桶，按照常量固定速率流出水滴；

• 如果桶是空的，則不需流出水滴；

• 可以以任意速率流入水滴到漏桶；

• 如果流入水滴超出了桶的容量，則流入的水滴溢位了（被丟棄），而漏桶容量是不變的。

令牌桶和漏桶對比：

• 令牌桶是按照固定速率往桶中新增令牌，請求是否被處理需要看桶中令牌是否足夠，當令牌數減為零時則拒絕新的請求；

• 漏桶則是按照常量固定速率流出請求，流入請求速率任意，當流入的請求數累積到漏桶容量時，則新流入的請求被拒絕；

• 令牌桶限制的是平均流入速率（允許突發請求，只要有令牌就可以處理，支援一次拿3個令牌，4個令牌），並允許一定程度突發流量；

• 漏桶限制的是常量流出速率（即流出速率是一個固定常量值，比如都是1的速率流出，而不能一次是1，下次又是2），從而平滑突發流入速率；

• 令牌桶允許一定程度的突發，而漏桶主要目的是平滑流入速率；

• 兩個演算法實現可以一樣，但是方向是相反的，對於相同的引數得到的限流效果是一樣的。

另外有時候我們還使用計數器來進行限流，主要用來限制總併發數，比如資料庫連線池、執行緒池、秒殺的併發數；只要全域性總請求數或者一定時間段的總請求數設定的閥值則進行限流，是簡單粗暴的總數量限流，而不是平均速率限流。

到此基本的演算法就介紹完了，接下來我們首先看看應用級限流。

應用級限流

限流總併發/連線/請求數

對於一個應用系統來說一定會有極限併發/請求數，即總有一個TPS/QPS閥值，如果超了閥值則系統就會不響應使用者請求或響應的非常慢，因此我們最好進行過載保護，防止大量請求湧入擊垮系統。

如果你使用過Tomcat，其Connector其中一種配置有如下幾個引數：

acceptCount：如果Tomcat的執行緒都忙於響應，新來的連線會進入佇列排隊，如果超出排隊大小，則拒絕連線；

maxConnections：瞬時最大連線數，超出的會排隊等待；

maxThreads：Tomcat能啟動用來處理請求的最大執行緒數，如果請求處理量一直遠遠大於最大執行緒數則可能會僵死。

詳細的配置請參考官方文件。另外如MySQL（如max_connections）、Redis（如tcp-backlog）都會有類似的限制連線數的配置。

限流總資源數

如果有的資源是稀缺資源（如資料庫連線、執行緒），而且可能有多個系統都會去使用它，那麼需要限制應用；可以使用池化技術來限制總資源數：連線池、執行緒池。比如分配給每個應用的資料庫連線是100，那麼本應用最多可以使用100個資源，超出了可以等待或者拋異常。

限流某個介面的總併發/請求數

如果介面可能會有突發訪問情況，但又擔心訪問量太大造成崩潰，如搶購業務；這個時候就需要限制這個介面的總併發/請求數總請求數了；因為粒度比較細，可以為每個介面都設定相應的閥值。可以使用Java中的AtomicLong進行限流：

try {
    if(atomic.incrementAndGet() > 限流數) {
        //拒絕請求
}
    //處理請求
} finally {
    atomic.decrementAndGet();
}

適合對業務無損的服務或者需要過載保護的服務進行限流，如搶購業務，超出了大小要麼讓使用者排隊，要麼告訴使用者沒貨了，對使用者來說是可以接受的。而一些開放平臺也會限制使用者呼叫某個介面的試用請求量，也可以用這種計數器方式實現。這種方式也是簡單粗暴的限流，沒有平滑處理，需要根據實際情況選擇使用；

限流某個介面的時間窗請求數

即一個時間視窗內的請求數，如想限制某個介面/服務每秒/每分鐘/每天的請求數/呼叫量。如一些基礎服務會被很多其他系統呼叫，比如商品詳情頁服務會呼叫基礎商品服務呼叫，但是怕因為更新量比較大將基礎服務打掛，這時我們要對每秒/每分鐘的呼叫量進行限速；一種實現方式如下所示：

LoadingCache<Long, AtomicLong> counter =
        CacheBuilder.newBuilder()
                .expireAfterWrite(2, TimeUnit.SECONDS)
                .build(new CacheLoader<Long, AtomicLong>() {
                    @Override
                    public AtomicLong load(Long seconds) throws Exception {
                        return new AtomicLong(0);
                    }
                });
long limit = 1000;
while(true) {
    //得到當前秒
    long currentSeconds = System.currentTimeMillis() / 1000;
    if(counter.get(currentSeconds).incrementAndGet() > limit) {
        System.out.println("限流了:" + currentSeconds);
        continue;
    }
    //業務處理
}

 我們使用Guava的Cache來儲存計數器，過期時間設定為2秒（保證1秒內的計數器是有的），然後我們獲取當前時間戳然後取秒數來作為KEY進行計數統計和限流，這種方式也是簡單粗暴，剛才說的場景夠用了。

平滑限流某個介面的請求數

之前的限流方式都不能很好地應對突發請求，即瞬間請求可能都被允許從而導致一些問題；因此在一些場景