概要
在大數據量高並發訪問時，經常會出現服務或接口面對暴漲的請求而不可用的情況，甚至引發連鎖反映導致整個系統崩潰。此時你需要使用的技術手段之一就是限流，當請求達到一定的並發數或速率，就進行等待、排隊、降級、拒絕服務等。
對一般的限流場景來說它具有兩個維度的信息：
時間：限流基於某段時間范圍或者某個時間點，也就是我們常說的“時間窗口”，比如對每分鍾、每秒鍾的時間窗口做限定
資源：基於可用資源的限制，比如設定最大訪問次數，或最高可用連接數
上面兩個維度結合起來看，限流就是在某個時間窗口對資源訪問做限制，比如設定每秒最多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不是面對分布式系統的解決方案，但是其作為一個簡單輕量級的客戶端限流組件，非常適合來講解限流算法
網關層限流
在整個分布式系統中，如果有這么一個“一夫當關，萬夫莫開”的角色，非網關層莫屬。服務網關，作為整個分布式鏈路中的第一道關卡，承接了所有用戶來訪請求，因此在網關層面進行限流是一個很好的切入點
網關層限流的架構思考
如果我們將這個系統的模型想象成為一個漏斗模型的話，抽象出來大概如下面的結構：
上面是一個最普通的流量模型，從上到下的路徑依次是：
- 用戶流量從網關層轉發到后台服務
- 后台服務承接流量，調用緩存獲取數據
- 緩存中無數據，則訪問數據庫
為什么說它是一個漏斗模型，因為流量自上而下是逐層遞減的，在網關層聚集了最多最密集的用戶訪問請求，其次是后台服務。
然后經過后台服務的驗證邏輯之后，刷掉了一部分錯誤請求，剩下的請求落在緩存上，如果緩存中沒有數據才會請求漏斗最下方的數據庫，因此數據庫層面請求數量最小（相比較其他組件來說數據庫往往是並發量能力最差的一環，阿里系的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】https://blog.csdn.net/zhangcongyi420/article/details/108690911