Java 限流及常用解決方案

[限流基本概念]

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

上面兩個維度結合起來看，限流就是在某個時間窗口對資源訪問做限制，比如設定每秒最多 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 系統做大量的商品發佈、補貨等等操作。

[分佈式環境]

分佈式區別於單機限流的場景，它把整個分佈式環境中所有服務器當做一個整體來考量。比如說針對 IP 的限流，我們限制了 1 個 IP 每秒最多 10 個訪問，不管來自這個 IP 的請求落在了哪臺機器上，只要是訪問了集羣中的服務節點，那麼都會受到限流規則的制約。我們最好將限流信息保存在一個 “中心化” 的組件上，這樣它就可以獲取到集羣中所有機器的訪問狀態，目前有兩個比較主流的限流方案：

[限流方案常用算法]

[令牌桶算法]

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

令牌生成

這個流程涉及到令牌生成器和令牌桶，前面我們提到過令牌桶是一個裝令牌的地方，既然是個桶那麼必然有一個容量，也就是說令牌桶所能容納的令牌數量是一個固定的數值。對於令牌生成器來說，它會根據一個預定的速率向桶中添加令牌，比如我們可以配置讓它以每秒 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。

作者：liuec1002

來源：blog.csdn.net/liuerchong/article/details/118882053

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/OjSet7jtPjfcxeaHKL_LKA

猜你喜歡