十分鐘搞懂限流及常見方案！

最近，收到幾位網友的面試回饋，都在面試中被問到限流相關問題，咱們今天就來聊聊我們專案中的各種限流解決方案。

限流基本概念

#對一般的限流場景來說它具有兩個維度的訊息：

• 時間限流是基於某段時間範圍或某個時間點，也就是我們常說的“時間視窗”，例如對每分鐘、每秒鐘的時間視窗做限定
• 資源是基於可用資源的限制，例如設定最大存取次數，或最高可用連線數

上面兩個維度結合起來看，限流就是在某個時間視窗對資源存取做限制，例如設定每秒最多100個存取請求。但在真正的場景裡，我們不只設定一種限流規則，而是會設定多個限流規則共同作用，主要的幾種限流規則如下：

QPS和連接數控制

對於（連線數和QPS)限流來說，我們可設定IP維度的限流，也可以設定基於單一伺服器的限流。

圖片

在真實環境中通常會設定多個維度的限流規則，例如設定同一個IP每秒存取頻率小於10，連接數小於5，再設定每台機器QPS最高1000，連線數最大保持200。更進一步，我們可以把某個伺服器群組或整個機房的伺服器當做一個整體，設定更high-level的限流規則，這些所有限流規則都會共同作用於流量控制。

傳輸速率

對於「傳輸速率」大家都不會陌生，例如資源的下載速度。有的網站在這方面的限流邏輯做的更細緻，例如一般註冊用戶下載速度為100k/s，購買會員後是10M/s，這背後就是基於用戶組或用戶標籤的限流邏輯。

黑白名單

黑白名單是各個大型企業應用裡很常見的限流和放行手段，黑白名單往往是動態變化的。舉個例子，如果某個IP在一段時間的訪問次數過於頻繁，被系統識別為機器人用戶或流量攻擊，那麼這個IP就會被加入到黑名單，從而限制其對系統資源的訪問，這就是我們俗稱的「封IP」。

我們平常見到的爬蟲程序，比如說爬知乎上的美女圖片，或者爬券商系統的股票分時信息，這類爬蟲程序都必須實現更換IP的功能，以防被加入黑名單。

有時我們也會發現公司的網路無法存取12306這類大型公共網站，這也是因為某些公司的出網IP是同一個位址，因此在訪問量過高的情況下，這個IP地址就被對方系統識別，進而被加到了黑名單。使用家庭寬頻的同學應該知道，大部分網路業者都會將使用者指派到不同出網IP段，或是時不時動態更換使用者的IP位址。

白名單就更好理解了，相當於禦賜金牌在身，可以自由穿梭在各種限流規則裡，暢行無阻。例如某些電商公司會將超大賣家的帳號加入白名單，因為這類賣家往往有自己的一套運維繫統，需要對接公司的IT系統做大量的商品發布、補貨等等操作。另外，搜尋公眾號程式設計技術圈後台回覆“Java”，取得一份驚喜禮包。

分散式環境

分散式區別於單機限流的場景，它把整個分散式環境中所有伺服器當作一個整體來考慮。比方說針對IP的限流，我們限制了1個IP每秒最多10個訪問，不管來自這個IP的請求落在了哪台機器上，只要是訪問了集群中的服務節點，那麼都會受到限流規則的製約。

我們最好將限流資訊保存在一個「中心化」的元件上，這樣它就可以取得到叢集中所有機器的存取狀態，目前有兩個比較主流的限流方案：

• 網關層限流將限流規則應用在所有流量的入口處
• 中間件限流將限流資訊儲存在分散式環境中某個中間件裡（例如Redis快取），每個元件都可以從這裡取得到當下時刻的流量統計，從而決定是拒絕服務還是放行流量
• sentinel， springcloud生態圈為微服務量身打造的一款用於分散式限流、熔斷降級等元件

限流方案常用演算法

令牌桶演算法

Token Bucket令牌桶演算法是目前應用最廣泛的限流演算法，顧名思義，它有以下兩個關鍵角色：

• 令牌取得到令牌的Request才會被處理，其他Requests要麼排隊要麼被直接丟棄
• ##桶用來裝令牌的地方，所有Request都從這個桶裡面取得令牌主要涉及到2個過程：
• #令牌產生

#這個流程涉及到令牌產生器和令牌桶，前面我們提到過令牌桶是一個裝令牌的地方，既然是個桶那麼必然有一個容量，也就是說令牌桶所能容納的令牌數量是一個固定的數值。

對於令牌產生器來說，它會根據一個預定的速率向桶中添加令牌，例如我們可以設定讓它以每秒100個請求的速率發放令牌，或每分鐘50個。注意這裡的發放速度是勻速，也就是說這50個令牌並非是在每個時間窗口剛開始的時候一次性發放，而是會在這個時間窗口內勻速發放。

在令牌發放器就是一個水龍頭，假如在下面接水的桶子滿了，那麼自然這個水（令牌）就流到了外面。在令牌發放過程中也一樣，令牌桶的容量是有限的，如果目前已經放滿了額定容量的令牌，那麼新來的令牌就會被丟棄掉。

• 令牌取得

#每個存取請求到來後，必須取得到一個令牌才能執行後面的邏輯。假如令牌的數量少，而存取請求較多的情況下，一部分請求自然無法取得到令牌，那麼這個時候我們可以設定一個「緩衝佇列」來暫存這些多餘的令牌。

緩衝佇列其實是一個可選的選項，並不是所有應用了令牌桶演算法的程式都會實作佇列。當有快取佇列存在的情況下，那些暫時沒有取得到令牌的請求將會被放到這個佇列中排隊，直到新的令牌產生後，再從佇列頭部拿出一個請求來符合令牌。

當佇列已滿的情況下，這部分存取請求將會被丟棄。在實際應用中我們也可以為這個佇列加一系列的特效，例如設定佇列中要求的存活時間，或是將佇列改造為PriorityQueue，依照某種優先權排序，而不是先進先出。

漏桶演算法

Leaky Bucket，又是個桶，限流演算法是跟桶槓上了，那麼漏桶和令牌桶有什麼不同呢,

漏桶演算法的前半段和令牌桶類似，但是操作的物件不同，令牌桶是將令牌放入桶裡，而漏桶是將存取請求的資料包放到桶裡。同樣的是，如果桶滿了，那麼後面新來的資料包將被丟棄。

漏桶演算法的後半程是有鮮明特色的，它永遠只會以一個恆定的速率將封包從桶內流出。打個比方，如果我設定了漏桶可以存放100個資料包，然後流出速度是1s一個，那麼不管資料包以什麼速率流入桶裡，也不管桶裡有多少資料包，漏桶能保證這些數據包永遠以1s一個的恆定速度被處理。另外，搜尋公眾號後端架構師後台回覆“架構整潔”，獲取一份驚喜禮包。

• 漏桶vs 令牌桶的差異

#根據它們各自的特徵不難看出來，這兩種演算法都有一個「恆定」的速率和「不定」的速率。令牌桶是以恆定速率創建令牌，但是訪問請求獲取令牌的速率“不定”，反正有多少令牌發多少，令牌沒了就乾等。而漏桶是以「恆定」的速率處理請求，但是這些請求流入桶的速率是「不定」的。

從這兩個特點來說，漏桶的天然特性決定了它不會發生突發流量，就算每秒1000個請求到來，那麼它對後台服務輸出的存取速率永遠恆定。而令牌桶則不同，其特性可以「預存」一定量的令牌，因此在應對突發流量的時候可以在短時間消耗所有令牌，其突發流量處理效率會比漏桶高，但是導向後台系統的壓力也會隨之增加。

滑動視窗

比如說，我們在每一秒內有5個用戶訪問，第5秒內有10個用戶訪問，那麼在0到5秒這個時間窗口內訪問量就是15。如果我們的介面設定了時間窗口內訪問上限是20，那麼當時間到第六秒的時候，這個時間窗口內的計數總和就變成了10，因為1秒的格子已經退出了時間窗口，因此在第六秒內可以接收的訪問量就是20-10=10個。

滑動視窗其實也是計算器演算法，它有一個顯著特點，當時間視窗的跨度越長時，限流效果就越平滑。打個比方，如果當前時間窗口只有兩秒，而訪問請求全部集中在第一秒的時候，當時間向後滑動一秒後，當前窗口的計數量將發生較大的變化，拉長時間窗口可以降低這種情況的發生機率

常用的限流方案

#合法性驗證限流

例如驗證碼、IP 黑名單等，這些手段可以有效的防止惡意攻擊和爬蟲採集；

Guawa限流

在限流領域中，Guava在其多線程模組下提供了以RateLimiter為首的幾個限流支援類，但是作用範圍僅限於「目前」這台伺服器，也就是說Guawa的限流是單機的限流，跨了機器或者jvm進程就無能為力了比如說，目前我有2台伺服器[Server 1，Server 2]，這兩台伺服器都部署了一個登陸服務，假如我希望對這兩台機器的流量進行控制，例如將兩台機器的訪問量總和控制在每秒20以內，如果用Guava來做，只能獨立控制每台機器的訪問量<=10。

儘管Guava不是面對分散式系統的解決方案，但其作為一個簡單輕量級的客戶端限流元件，非常適合來講解限流演算法

網關層限流

服務網關，作為整個分散式連結中的第一道關卡，承接了所有使用者造訪請求，因此在網關層面進行限流是一個很好的切入點上到下的路徑依次是：

1. 使用者流量從網關層轉送至後台服務
2. 後台服務承接流量，呼叫快取取得資料
3. 快取中無數據，則存取資料庫

流量自上而下是逐層遞減的，在網關層聚集了最多最密集的使用者存取請求，其次是後台服務。

然後經過後台服務的驗證邏輯之後，刷掉了一部分錯誤請求，剩下的請求落在快取上，如果快取中沒有資料才會請求漏斗最下方的資料庫，因此資料庫層級請求數量最小（相比較其他元件來說資料庫往往是並發量能力最差的一環，阿里系的MySQL即便經過了大量改造，單機並發量也無法和Redis、Kafka之類的元件相比）

目前主流的閘道層有以軟體為代表的Nginx，還有Spring Cloud中的Gateway和Zuul這類網關層元件

Nginx限流

#在系統架構中，Nginx的代理與路由轉送是其作為網關層的一個很重要的功能，由於Nginx天生的輕量級和優秀的設計，讓它成為眾多公司的首選，Nginx從網關這一層面考慮，可以作為最前置的網關，抵擋大部分的網路流量，因此使用Nginx進行限流也是一個很好的選擇，在Nginx中，也提供了常用的基於限流相關的策略配置.

Nginx 提供了兩種限流方法：一種是控制速率，另一種是控制並發連線數。

控制速率

我們需要使用limit_req_zone 用來限制單位時間內的請求數，也就是速率限制，

#因為Nginx的限流統計是基於毫秒的，我們設定的速度是2r/s，轉換一下就是500毫秒內單一IP只允許通過1個請求，從501ms開始才允許通過第2個請求。

• 控制速率優化版

#上面的速率控制雖然很精準但是在生產環境未免太苛刻了，實際情況下我們應該控制一個IP單位總時間內的總訪問次數，而不是像上面那樣精確到毫秒，我們可以使用burst 關鍵字開啟此設定

burst=4意思是每個IP最多允許4個突發請求

#控制並發數

利用limit_conn_zone 和limit_conn 兩個指令即可控制並發數

其中limit_conn perip 10 表示限制單一IP 同時最多能持有10 個連線；limit_conn perserver 100 表示server 同時能處理並發連線的總數為100 個。

注意：只有當 request header 被後端處理後，這個連線才會進行計數。

中間件限流

對於分散式環境來說，無非是需要一個類似中心節點的地方儲存限流資料。打個比方，如果我希望控制介面的存取速率為每秒100個請求，那麼我就需要將當前1s內已經接收到的請求的數量保存在某個地方，並且可以讓叢集環境中所有節點都能訪問。那我們可以用什麼技術來儲存這個臨時資料呢？

那麼想必大家都能想到，必然是redis了，利用Redis過期時間特性，我們可以輕鬆設定限流的時間跨度（比如每秒10個請求，或者每10秒10個請求）。同時Redis還有一個特殊技能–腳本編程，我們可以將限流邏輯編寫成一段腳本植入到Redis中，這樣就將限流的重任從服務層完全剝離出來，同時Redis強大的並發量特性以及高可用叢集架構也可以很好的支援龐大叢集的限流存取(reids lua)。

限流元件

除了上面介紹的幾種方式以外，目前也有一些開源元件提供了類似的功能，例如Sentinel就是一個不錯的選擇。 Sentinel是阿里出品的開源元件，並且包含在了Spring Cloud Alibaba元件庫中，Sentinel提供了相當豐富的用於限流的API以及可視化管控台，可以很方便的幫助我們對限流進行治理

從架構維度考慮限流設計

在真實的專案裡，不會只使用一種限流手段，往往是幾種方式互相搭配使用，讓限流策略有一種層次感，達到資源的最大使用率。在這個過程中，限流策略的設計也可以參考前面提到的漏斗模型，上寬下緊，漏斗不同部位的限流方案設計要盡量注意目前組件的高可用性。

以我參與的實際專案為例，比如說我們研發了一個商品詳情頁的接口，透過手機淘寶導流，app端的存取請求首先會經過阿里的mtop網關，在網關層我們的限流會做的比較寬鬆，等到請求通過網關抵達後台的商品詳情頁服務之後，再利用一系列的中間件限流組件，對服務進行更加細緻的限流控制

##具體的實作限流的手段

1）Tomcat 使用maxThreads來實現限流。

2）Nginx的

limit_req_zone和 burst來實現速率限流。

3）Nginx的

limit_conn_zone和 limit_conn兩個指令控制並發連接的總數。

4）時間窗口演算法借助 Redis的有序集合可以實現。

5）漏桶演算法可以使用Redis-Cell來實作。

6）令牌演算法可以解決Google的guava套件來實現。

需要注意的是藉助Redis實現的限流方案可用於分散式系統，而guava實現的限流只能應用於單機環境。如果你覺得伺服器端限流麻煩，可以在不改任何程式碼的情況下直接使用容器限流（Nginx或Tomcat），但前提是能滿足專案中的業務需求。

Tomcat限流

Tomcat 8.5 版本的最大執行緒數在

conf/server.xml 配置中，maxThreads 就是Tomcat 的最大執行緒數，當請求的並發大於此值（maxThreads）時，請求就會排隊執行，這樣就完成了限流的目的。

注意：

maxThreads 的值可以適當的調大一些，Tomcat預設為150（Tomcat 版本8.5），但這個值也不是越大越好，要看具體的伺服器配置，需要注意的是每開啟一個線程需要耗用1MB 的JVM 記憶體空間作為執行緒棧之用，且執行緒越多GC 的負擔越重。

最後要注意一下，作業系統對於行程中的執行緒數有一定的限制，Windows 每個行程中的執行緒數不允許超過2000，Linux 每個行程中的執行緒數不允許超過1000。

以上是十分鐘搞懂限流及常見方案！的詳細內容。更多資訊請關注PHP中文網其他相關文章！