在開發高并發系統的時候，我們一般通過三種方式去保障系統服務穩定：服務降級、服務限流和緩存。對于緩存在實際開發中使用的比較多，這個是大家的共識沒有什么異議的。今天我們的主角是服務限流，在此之前我們先來看下服務限流 和 服務降級 的區別：

服務降級

服務降級是在服務器壓力陡增的情況下，利用現有的資源，關閉一些服務接口或者頁面，以此來釋放服務器資源保證核心任務的正常運行。

服務限流

限流本質上是減少流量的訪問，而服務的處理能力不變；而對于服務降級來說是降低了部分服務的處理能力，增加另一部分服務處理能力，訪問量不變。

本篇文章中說到的服務限流不是 nginx 層面的限流，而是業務代碼中的邏輯限流。

那么，我們為什么要服務限流？

從服務調用方來說，可以把服務簡單的劃分為以下幾種類型的服務

1.與用戶打交道的服務

比如 web 服務，對外 API,這種類型的服務有以下幾種可能會導致服務器壓力變大：

用戶增長過快

熱點事件

惡意的攻擊/刷單

爬蟲
這些情況都是無法預知的，我們不知道什么時候請求流量會突增，如果真的要是碰到這種情況，擴容根本是來不及的

2.對內的 RPC 服務

一個服務 A 的接口可能會被其他 BCDE 多個服務調用，如果其中一個服務的流量突增比如 B 服務，導致 A 服務壓力變大甚至掛掉，那么這個時候也不能給 CDE 服務提供服務。
這種情況在實際開發中時常發生。

常見的限流算法

下面我們來看幾種實際業務場景中常用的幾種限流算法：計數器算法、漏桶算法、令牌桶算法。

計數器算法

計數器算法應該是最簡單，最容易想到的限流策略。限流的本質是限制某一個 API 在某個維度單位時間內處理請求的次數。我們可以設置一個計數器對某一時間段內的請求進行計數，當請求量超過事先設定好的閾值，拒絕用戶的請求。比如限流的 QPS 是100，算法的實現思路是從第一個請求進來開始計數，在接下來的 1s 內，每來一個請求計數器自動加 1，如果累加的數字超過 100，那么后續的請求就會被拒絕，等到 1s 結束后，計數器開始重置為 0，重新開始計數。

這種方式存在弊端

弊端1：如果在 1s 的前 10ms 請求數已經達到了 100，那么剩下的 990ms，服務調用方就要眼巴巴的看著請求被拒絕。

弊端2：如果有一個惡意的用戶在 999ms 的時候瞬間發送了 100 次請求，并且又在 1000ms 時瞬間發送了 100 次請求，那么其實這個用戶在 1s 內發送了 200 次請求。利用時間窗口的重置節點處突發請求，可以瞬間超過我們服務本身能承受的壓力，瞬間壓垮服務。

針對計數器算法的漏洞一個比較經典的處理方案是采用 滑動窗口。比如我們把上面的 1min 內 100 次請求上限看成是一個大的時間窗口，然后把這個窗口進一步細分，比如每 10 s 一個小窗口，該窗口的頻率上限同樣設置成 100，這樣大窗口包含 16 個小窗口，并且每過 10s 大窗口就移動一個小窗口長度。如果一個惡意用戶在 09:59:30~09:59:59 之間發送了 100 次請求，等到了10:00:00~10:00:30 時 100 次計數仍然是有效的，所以，這個時間段新的請求仍然會被拒絕。

漏桶算法

漏桶算法是限流方面比較經典的算法?？梢园言撍惴撓氤梢粋€具體的漏桶模型，漏桶始終以一個恒定的速率往外排水，如果桶被裝滿的話則后來涌入的水會溢出。對應到接口限流來說，用戶的請求可以看做是水，不管用戶的請求量有多大多不均衡，能夠被處理的請求速率是恒定的，而且能夠接受的請求數也是有上限的，超出上限的請求會被拒絕，在算法實現方面可以準備一個隊列來作為漏桶的實現，用這個隊列保存請求，通過一個線程池定期從隊列中獲取請求并執行，也可以一次性獲取多個并發請求，如下圖：

漏桶算法也存在一個弊端：無法應對短時間的突發流量

令牌桶算法

在令牌桶算法中，存在一個桶，用來存放固定數量的令牌。算法中存在一種機制，以一定的速率往桶中放令牌。每次請求調用需要先獲取令牌，只有拿到令牌才有機會繼續執行，否則請求選擇等待或者服務直接拒絕請求。

放令牌這個動作是持續不斷的進行，如果桶中令牌數量達到上限，就丟棄令牌，所以，會存在這樣的一種情況，桶中一直有大量的令牌，這時進來的請求就可以直接拿到令牌執行。比如我們把 QPS 設置成 100，那么限流器完成初始化 1s 后，桶中已經有 100 個令牌，這時候服務還未完全啟動好，等啟動完成功對外提供服務時，該限流器可以抵擋瞬時的 100 個請求。所以，當桶中沒有令牌時請求才會等待或者被拒絕，當沒有請求申請令牌時，那么這個令牌桶會溢出。在這里令牌桶類似一個 buffer,請求密度比較低或者處于冷卻狀態下，令牌桶會溢出，當請求流量突增時，則過去積累的結余資源直接可以拿來借用，從這里可以看出這點彌補了漏桶算法的不足。

實現思路：可以準備一個隊列，用于存放令牌，另外通過一個線程池定期生成令牌存放到隊列中，沒來一個請求就從隊列中取出一個令牌，并繼續執行。

上面我們提到的限流算法主要是針對于單機限流，實際業務場景更加的復雜，業務的需求五花八門，簡單的單機限流很難滿足需求。

比如為了限制某個資源被某個用戶訪問的次數，10 s 只能訪問 3 次，或者一天只能訪問 100 次，這種需求通過單機限流是無法實現的，這時就需要通過集群限流的方式實現。

如何實現?為了實現對訪問次數的限制，肯定需要一個計數器，那么我們需要把這個計數器放在哪里呢？因為這個限流是在集群層面實現的，集群形式存在的情況才需要分布式限流，由于 redis 天生對分布式支持非常友好，所以 redis 成了一個很好的選擇。

大致思路：每次有相關的操作時候，我們就向 redis 服務器發送一個 incr 命令。比如限制某個用戶訪問接口的次數，當用戶請求過來時我們使用用戶 ID 和 接口名稱生成對應 key,每次該用戶訪問這個接口時，只需要對這個 key 增加 1，并且給這個 key 設置有效期，這樣就可以簡單的實現指定時間內的訪問效率。