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的請求落在了哪臺機器上，只要是訪問了集羣中的服務節點，那麼都會受到限流規則的制約。

從上面例子不難看出，咱們最好將限流信息保存在一個「中心化」的組件上，這樣它就能夠獲取到集羣中全部機器的訪問狀態，目前有兩個比較主流的限流方案：

網關層限流 將限流規則應用在全部流量的入口處
中間件限流 將限流信息存儲在分佈式環境中某個中間件裏（好比Redis緩存），每一個組件均可以從這裏獲取到當前時刻的流量統計，從而決定是拒絕服務仍是放行流量
sentinel，springcloud生態圈爲微服務量身打造的一款用於分佈式限流、熔斷降級等組件

限流方案經常使用算法介紹

說到限流，至少咱們須要對限流的底層原理有個大體的瞭解，纔好更深刻的進行學習，下面咱們挑選令牌桶算法、漏桶算法、滑動窗口和計數器算法來講一下

令牌桶算法

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

令牌 獲取到令牌的Request纔會被處理，其餘Requests要麼排隊要麼被直接丟棄
桶 用來裝令牌的地方，全部Request都從這個桶裏面獲取令牌
用圖簡單描述以下

主要涉及到2個過程：

令牌生成

這個流程涉及到令牌生成器和令牌桶，前面咱們提到過令牌桶是一個裝令牌的地方，既然是個桶那麼必然有一個容量，也就是說令牌桶所能容納的令牌數量是一個固定的數值。
對於令牌生成器來講，它會根據一個預約的速率向桶中添加令牌，好比咱們能夠配置讓它以每秒100個請求的速率發放令牌，或者每分鐘50個。注意這裏的發放速度是勻速，也就是說這50個令牌並不是是在每一個時間窗口剛開始的時候一次性發放，而是會在這個時間窗口內勻速發放。
在令牌發放器就是一個水龍頭，假如在下面接水的桶子滿了，那麼天然這個水（令牌）就流到了外面。在令牌發放過程當中也同樣，令牌桶的容量是有限的，若是當前已經放滿了額定容量的令牌，那麼新來的令牌就會被丟棄掉。

令牌獲取

每一個訪問請求到來後，必須獲取到一個令牌才能執行後面的邏輯。假如令牌的數量少，而訪問請求較多的狀況下，一部分請求天然沒法獲取到令牌，那麼這個時候咱們能夠設置一個「緩衝隊列」來暫存這些多餘的令牌。
緩衝隊列實際上是一個可選的選項，並非全部應用了令牌桶算法的程序都會實現隊列。當有緩存隊列存在的狀況下，那些暫時沒有獲取到令牌的請求將被放到這個隊列中排隊，直到新的令牌產生後，再從隊列頭部拿出一個請求來匹配令牌。
當隊列已滿的狀況下，這部分訪問請求將被丟棄。在實際應用中咱們還能夠給這個隊列加一系列的特效，好比設置隊列中請求的存活時間，或者將隊列改造爲PriorityQueue，根據某種優先級排序，而不是先進先出。

漏桶算法

Leaky Bucket，又是個桶，限流算法是跟桶槓上了，那麼漏桶和令牌桶有什麼不一樣呢？咱們來看圖說話：

漏桶算法的前半段和令牌桶相似，可是操做的對象不一樣，令牌桶是將令牌放入桶裏，而漏桶是將訪問請求的數據包放到桶裏。一樣的是，若是桶滿了，那麼後面新來的數據包將被丟棄。
漏桶算法的後半程是有鮮明特點的，它永遠只會以一個恆定的速率將數據包從桶內流出。打個比方，若是我設置了漏桶能夠存放100個數據包，而後流出速度是1s一個，那麼無論數據包以什麼速率流入桶裏，也無論桶裏有多少數據包，漏桶能保證這些數據包永遠以1s一個的恆定速度被處理。
漏桶 vs 令牌桶的區別

根據它們各自的特色不難看出來，這兩種算法都有一個「恆定」的速率和「不定」的速率。令牌桶是以恆定速率建立令牌，可是訪問請求獲取令牌的速率「不定」，反正有多少令牌發多少，令牌沒了就乾等。而漏桶是以「恆定」的速率處理請求，可是這些請求流入桶的速率是「不定」的。
從這兩個特色來講，漏桶的自然特性決定了它不會發生突發流量，就算每秒1000個請求到來，那麼它對後臺服務輸出的訪問速率永遠恆定。而令牌桶則不一樣，其特性能夠「預存」必定量的令牌，所以在應對突發流量的時候能夠在短期消耗全部令牌，其突發流量處理效率會比漏桶高，可是導向後臺系統的壓力也會相應增多。

滑動窗口

根據圖示，咱們將時間窗口的限流原理拆解描述一下其過程：

黑色的大框就是時間窗口，咱們設定窗口時間爲5秒，它會隨着時間推移向後滑動。咱們將窗口內的時間劃分爲五個小格子，每一個格子表明1秒鐘，同時這個格子還包含一個計數器，用來計算在當前時間內訪問的請求數量。那麼這個時間窗口內的總訪問量就是全部格子計數器累加後的數值。
好比說，咱們在每一秒內有5個用戶訪問，第5秒內有10個用戶訪問，那麼在0到5秒這個時間窗口內訪問量就是15。若是咱們的接口設置了時間窗口內訪問上限是20，那麼當時間到第六秒的時候，這個時間窗口內的計數總和就變成了10，由於1秒的格子已經退出了時間窗口，所以在第六秒內能夠接收的訪問量就是20-10=10個。
滑動窗口其實也是一種計算器算法，它有一個顯著特色，當時間窗口的跨度越長時，限流效果就越平滑。打個比方，若是當前時間窗口只有兩秒，而訪問請求所有集中在第一秒的時候，當時間向後滑動一秒後，當前窗口的計數量將發生較大的變化，拉長時間窗口能夠下降這種狀況的發生機率
那麼有了上面的基礎理論以後，咱們來簡單總結下目前經常使用的限流方案有哪些呢？

Guawa限流

提及Guava你們必定不陌生，它是Google出品的一款工具包，咱們常常用它作一些集合操做好比Lists.newArrayList()等，它最先源於2007的"Google Collections Library"項目。Guava不甘於將本身平凡的一輩子都耗費在Collections上面，因而乎它開始了轉型，慢慢擴展了本身在Java領域的影響力，從反射工具、函數式編程、安全驗證、數學運算等等方面，都提供了響應的工具包

在限流領域中，Guava也貢獻了一份綿薄之力，在其多線程模塊下提供了以RateLimiter爲首的幾個限流支持類，可是做用範圍僅限於「當前」這臺服務器，也就是說Guawa的限流是單機的限流，跨了機器或者jvm進程就無能爲力了

好比說，目前我有2臺服務器[Server 1，Server 2]，這兩臺服務器都部署了一個登錄服務，假如我但願對這兩臺機器的流量進行控制，好比將兩臺機器的訪問量總和控制在每秒20之內，若是用Guava來作，只能獨立控制每臺機器的訪問量<=10。

儘管Guava不是面對分佈式系統的解決方案，可是其做爲一個簡單輕量級的客戶端限流組件，很是適合來說解限流算法

網關層限流

在整個分佈式系統中，若是有這麼一個「一夫當關，萬夫莫開」的角色，非網關層莫屬。服務網關，做爲整個分佈式鏈路中的第一道關卡，承接了全部用戶來訪請求，所以在網關層面進行限流是一個很好的切入點

網關層限流的架構思考

若是咱們將這個系統的模型想象成爲一個漏斗模型的話，抽象出來大概以下面的結構：
上面是一個最普通的流量模型，從上到下的路徑依次是：

1. 用戶流量從網關層轉發到後臺服務
2. 後臺服務承接流量，調用緩存獲取數據
3. 緩存中無數據，則訪問數據庫

爲何說它是一個漏斗模型，由於流量自上而下是逐層遞減的，在網關層彙集了最多最密集的用戶訪問請求，其次是後臺服務。

而後通過後臺服務的驗證邏輯以後，刷掉了一部分錯誤請求，剩下的請求落在緩存上，若是緩存中沒有數據纔會請求漏斗最下方的數據庫，所以數據庫層面請求數量最小（相比較其餘組件來講數據庫每每是併發量能力最差的一環，阿里系的MySQL即使通過了大量改造，單機併發量也沒法和Redis、Kafka之類的組件相比）

若是在上面這個漏斗模型中作流量限制，網關層首當其衝對不對？由於它是整個訪問鏈路的源頭，是全部流量途徑的第一站。目前主流的網關層有以軟件爲表明的Nginx，還有Spring Cloud中的Gateway和Zuul這類網關層組件，也有以硬件+軟件爲表明的F5（F5價錢貴到你懷疑人生）

Nginx限流

在系統架構中，Nginx的代理與路由轉發是其做爲網關層的一個很重要的功能，因爲Nginx天生的輕量級和優秀的設計，讓它成爲衆多公司的首選，Nginx從網關這一層面考慮，能夠做爲最前置的網關，抵擋大部分的網絡流量，所以使用Nginx進行限流也是一個很好的選擇，在Nginx中，也提供了經常使用的基於限流相關的策略配置，後續咱們將會使用簡單的案例進行說明

中間件限流

對於分佈式環境來講，無非是須要一個相似中心節點的地方存儲限流數據。打個比方，若是我但願控制接口的訪問速率爲每秒100個請求，那麼我就須要將當前1s內已經接收到的請求的數量保存在某個地方，而且可讓集羣環境中全部節點都能訪問。那咱們能夠用什麼技術來存儲這個臨時數據呢？

那麼想必你們都能想到，必然是redis了，利用Redis過時時間特性，咱們能夠輕鬆設置限流的時間跨度（好比每秒10個請求，或者每10秒10個請求）。同時Redis還有一個特殊技能–腳本編程，咱們能夠將限流邏輯編寫成一段腳本植入到Redis中，這樣就將限流的重任從服務層徹底剝離出來，同時Redis強大的併發量特性以及高可用集羣架構也能夠很好的支持龐大集羣的限流訪問。【reids + lua】

限流組件

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

從架構維度考慮限流設計
在真實的項目裏，不會只使用一種限流手段，每每是幾種方式互相搭配使用，讓限流策略有一種層次感，達到資源的最大使用率。在這個過程當中，限流策略的設計也能夠參考前面提到的漏斗模型，上寬下緊，漏斗不一樣部位的限流方案設計要儘可能關注當前組件的高可用。以我參與的實際項目爲例，好比說咱們研發了一個商品詳情頁的接口，經過手機淘寶導流，app端的訪問請求首先會通過阿里的mtop網關，在網關層咱們的限流會作的比較寬鬆，等到請求經過網關抵達後臺的商品詳情頁服務以後，再利用一系列的中間件+限流組件，對服務進行更加細緻的限流控制

參考文章：
【1】http://www.javashuo.com/article/p-qbznhehr-vw.html