限流基本概念

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

時(shí)間 限流基于某段時(shí)間范圍或者某個(gè)時(shí)間點(diǎn)，也就是我們常說的“時(shí)間窗口”，比如對每分鐘、每秒鐘的時(shí)間窗口做限定

資源 基于可用資源的限制，比如設(shè)定最大訪問次數(shù)，或最高可用連接數(shù)

上面兩個(gè)維度結(jié)合起來看，限流就是在某個(gè)時(shí)間窗口對資源訪問做限制，比如設(shè)定每秒最多100個(gè)訪問請求。但在真正的場景里，我們不止設(shè)置一種限流規(guī)則，而是會(huì)設(shè)置多個(gè)限流規(guī)則共同作用，主要的幾種限流規(guī)則如下：

QPS和連接數(shù)控制

對于連接數(shù)和QPS)限流來說，我們可設(shè)定IP維度的限流，也可以設(shè)置基于單個(gè)服務(wù)器的限流。

在真實(shí)環(huán)境中通常會(huì)設(shè)置多個(gè)維度的限流規(guī)則，比如設(shè)定同一個(gè)IP每秒訪問頻率小于10，連接數(shù)小于5，再設(shè)定每臺(tái)機(jī)器QPS最高1000，連接數(shù)最大保持200。更進(jìn)一步，我們可以把某個(gè)服務(wù)器組或整個(gè)機(jī)房的服務(wù)器當(dāng)做一個(gè)整體，設(shè)置更high-level的限流規(guī)則，這些所有限流規(guī)則都會(huì)共同作用于流量控制。

傳輸速率

對于“傳輸速率”大家都不會(huì)陌生，比如資源的下載速度。有的網(wǎng)站在這方面的限流邏輯做的更細(xì)致，比如普通注冊用戶下載速度為100k/s，購買會(huì)員后是10M/s，這背后就是基于用戶組或者用戶標(biāo)簽的限流邏輯。

黑白名單

黑白名單是各個(gè)大型企業(yè)應(yīng)用里很常見的限流和放行手段，而且黑白名單往往是動(dòng)態(tài)變化的。舉個(gè)例子，如果某個(gè)IP在一段時(shí)間的訪問次數(shù)過于頻繁，被系統(tǒng)識(shí)別為機(jī)器人用戶或流量攻擊，那么這個(gè)IP就會(huì)被加入到黑名單，從而限制其對系統(tǒng)資源的訪問，這就是我們俗稱的“封IP”。

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

有時(shí)我們還會(huì)發(fā)現(xiàn)公司的網(wǎng)絡(luò)無法訪問12306這類大型公共網(wǎng)站，這也是因?yàn)槟承┕镜某鼍W(wǎng)IP是同一個(gè)地址，因此在訪問量過高的情況下，這個(gè)IP地址就被對方系統(tǒng)識(shí)別，進(jìn)而被添加到了黑名單。使用家庭寬帶的同學(xué)們應(yīng)該知道，大部分網(wǎng)絡(luò)運(yùn)營商都會(huì)將用戶分配到不同出網(wǎng)IP段，或者時(shí)不時(shí)動(dòng)態(tài)更換用戶的IP地址。

白名單就更好理解了，相當(dāng)于御賜金牌在身，可以自由穿梭在各種限流規(guī)則里，暢行無阻。比如某些電商公司會(huì)將超大賣家的賬號加入白名單，因?yàn)檫@類賣家往往有自己的一套運(yùn)維系統(tǒng)，需要對接公司的IT系統(tǒng)做大量的商品發(fā)布、補(bǔ)貨等等操作。

分布式環(huán)境

分布式區(qū)別于單機(jī)限流的場景，它把整個(gè)分布式環(huán)境中所有服務(wù)器當(dāng)做一個(gè)整體來考量。比如說針對IP的限流，我們限制了1個(gè)IP每秒最多10個(gè)訪問，不管來自這個(gè)IP的請求落在了哪臺(tái)機(jī)器上，只要是訪問了集群中的服務(wù)節(jié)點(diǎn)，那么都會(huì)受到限流規(guī)則的制約。

我們最好將限流信息保存在一個(gè)“中心化”的組件上，這樣它就可以獲取到集群中所有機(jī)器的訪問狀態(tài)，目前有兩個(gè)比較主流的限流方案：

網(wǎng)關(guān)層限流 將限流規(guī)則應(yīng)用在所有流量的入口處

中間件限流 將限流信息存儲(chǔ)在分布式環(huán)境中某個(gè)中間件里（比如Redis緩存），每個(gè)組件都可以從這里獲取到當(dāng)前時(shí)刻的流量統(tǒng)計(jì)，從而決定是拒絕服務(wù)還是放行流量

sentinel，springcloud生態(tài)圈為微服務(wù)量身打造的一款用于分布式限流、熔斷降級等組件

基于 Spring Boot + MyBatis Plus + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項(xiàng)目地址：https://github.com/YunaiV/ruoyi-vue-pro

視頻教程：https://doc.iocoder.cn/video/

限流方案常用算法

令牌桶算法

Token Bucket令牌桶算法是目前應(yīng)用最為廣泛的限流算法，顧名思義，它有以下兩個(gè)關(guān)鍵角色：

令牌 獲取到令牌的Request才會(huì)被處理，其他Requests要么排隊(duì)要么被直接丟棄

桶 用來裝令牌的地方，所有Request都從這個(gè)桶里面獲取令牌 主要涉及到2個(gè)過程：

令牌生成

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

對于令牌生成器來說，它會(huì)根據(jù)一個(gè)預(yù)定的速率向桶中添加令牌，比如我們可以配置讓它以每秒100個(gè)請求的速率發(fā)放令牌，或者每分鐘50個(gè)。注意這里的發(fā)放速度是勻速，也就是說這50個(gè)令牌并非是在每個(gè)時(shí)間窗口剛開始的時(shí)候一次性發(fā)放，而是會(huì)在這個(gè)時(shí)間窗口內(nèi)勻速發(fā)放。

在令牌發(fā)放器就是一個(gè)水龍頭，假如在下面接水的桶子滿了，那么自然這個(gè)水（令牌）就流到了外面。在令牌發(fā)放過程中也一樣，令牌桶的容量是有限的，如果當(dāng)前已經(jīng)放滿了額定容量的令牌，那么新來的令牌就會(huì)被丟棄掉。

令牌獲取

每個(gè)訪問請求到來后，必須獲取到一個(gè)令牌才能執(zhí)行后面的邏輯。假如令牌的數(shù)量少，而訪問請求較多的情況下，一部分請求自然無法獲取到令牌，那么這個(gè)時(shí)候我們可以設(shè)置一個(gè)“緩沖隊(duì)列”來暫存這些多余的令牌。

緩沖隊(duì)列其實(shí)是一個(gè)可選的選項(xiàng)，并不是所有應(yīng)用了令牌桶算法的程序都會(huì)實(shí)現(xiàn)隊(duì)列。當(dāng)有緩存隊(duì)列存在的情況下，那些暫時(shí)沒有獲取到令牌的請求將被放到這個(gè)隊(duì)列中排隊(duì)，直到新的令牌產(chǎn)生后，再從隊(duì)列頭部拿出一個(gè)請求來匹配令牌。

當(dāng)隊(duì)列已滿的情況下，這部分訪問請求將被丟棄。在實(shí)際應(yīng)用中我們還可以給這個(gè)隊(duì)列加一系列的特效，比如設(shè)置隊(duì)列中請求的存活時(shí)間，或者將隊(duì)列改造為PriorityQueue，根據(jù)某種優(yōu)先級排序，而不是先進(jìn)先出。

漏桶算法

Leaky Bucket，又是個(gè)桶，限流算法是跟桶杠上了，那么漏桶和令牌桶有什么不同呢,

漏桶算法的前半段和令牌桶類似，但是操作的對象不同，令牌桶是將令牌放入桶里，而漏桶是將訪問請求的數(shù)據(jù)包放到桶里。同樣的是，如果桶滿了，那么后面新來的數(shù)據(jù)包將被丟棄。

漏桶算法的后半程是有鮮明特色的，它永遠(yuǎn)只會(huì)以一個(gè)恒定的速率將數(shù)據(jù)包從桶內(nèi)流出。打個(gè)比方，如果我設(shè)置了漏桶可以存放100個(gè)數(shù)據(jù)包，然后流出速度是1s一個(gè)，那么不管數(shù)據(jù)包以什么速率流入桶里，也不管桶里有多少數(shù)據(jù)包，漏桶能保證這些數(shù)據(jù)包永遠(yuǎn)以1s一個(gè)的恒定速度被處理。

漏桶 vs 令牌桶的區(qū)別

根據(jù)它們各自的特點(diǎn)不難看出來，這兩種算法都有一個(gè)“恒定”的速率和“不定”的速率。令牌桶是以恒定速率創(chuàng)建令牌，但是訪問請求獲取令牌的速率“不定”，反正有多少令牌發(fā)多少，令牌沒了就干等。而漏桶是以“恒定”的速率處理請求，但是這些請求流入桶的速率是“不定”的。

從這兩個(gè)特點(diǎn)來說，漏桶的天然特性決定了它不會(huì)發(fā)生突發(fā)流量，就算每秒1000個(gè)請求到來，那么它對后臺(tái)服務(wù)輸出的訪問速率永遠(yuǎn)恒定。而令牌桶則不同，其特性可以“預(yù)存”一定量的令牌，因此在應(yīng)對突發(fā)流量的時(shí)候可以在短時(shí)間消耗所有令牌，其突發(fā)流量處理效率會(huì)比漏桶高，但是導(dǎo)向后臺(tái)系統(tǒng)的壓力也會(huì)相應(yīng)增多。

滑動(dòng)窗口

比如說，我們在每一秒內(nèi)有5個(gè)用戶訪問，第5秒內(nèi)有10個(gè)用戶訪問，那么在0到5秒這個(gè)時(shí)間窗口內(nèi)訪問量就是15。如果我們的接口設(shè)置了時(shí)間窗口內(nèi)訪問上限是20，那么當(dāng)時(shí)間到第六秒的時(shí)候，這個(gè)時(shí)間窗口內(nèi)的計(jì)數(shù)總和就變成了10，因?yàn)?秒的格子已經(jīng)退出了時(shí)間窗口，因此在第六秒內(nèi)可以接收的訪問量就是20-10=10個(gè)。

滑動(dòng)窗口其實(shí)也是一種計(jì)算器算法，它有一個(gè)顯著特點(diǎn)，當(dāng)時(shí)間窗口的跨度越長時(shí)，限流效果就越平滑。打個(gè)比方，如果當(dāng)前時(shí)間窗口只有兩秒，而訪問請求全部集中在第一秒的時(shí)候，當(dāng)時(shí)間向后滑動(dòng)一秒后，當(dāng)前窗口的計(jì)數(shù)量將發(fā)生較大的變化，拉長時(shí)間窗口可以降低這種情況的發(fā)生概率

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項(xiàng)目地址：https://github.com/YunaiV/yudao-cloud

視頻教程：https://doc.iocoder.cn/video/

常用的限流方案

合法性驗(yàn)證限流

比如驗(yàn)證碼、IP 黑名單等，這些手段可以有效的防止惡意攻擊和爬蟲采集；

Guawa限流

在限流領(lǐng)域中，Guava在其多線程模塊下提供了以RateLimiter為首的幾個(gè)限流支持類，但是作用范圍僅限于“當(dāng)前”這臺(tái)服務(wù)器，也就是說Guawa的限流是單機(jī)的限流，跨了機(jī)器或者jvm進(jìn)程就無能為力了 比如說，目前我有2臺(tái)服務(wù)器[Server 1，Server 2]，這兩臺(tái)服務(wù)器都部署了一個(gè)登陸服務(wù)，假如我希望對這兩臺(tái)機(jī)器的流量進(jìn)行控制，比如將兩臺(tái)機(jī)器的訪問量總和控制在每秒20以內(nèi)，如果用Guava來做，只能獨(dú)立控制每臺(tái)機(jī)器的訪問量<=10。

盡管Guava不是面對分布式系統(tǒng)的解決方案，但是其作為一個(gè)簡單輕量級的客戶端限流組件，非常適合來講解限流算法

網(wǎng)關(guān)層限流

服務(wù)網(wǎng)關(guān)，作為整個(gè)分布式鏈路中的第一道關(guān)卡，承接了所有用戶來訪請求，因此在網(wǎng)關(guān)層面進(jìn)行限流是一個(gè)很好的切入點(diǎn) 上到下的路徑依次是：

用戶流量從網(wǎng)關(guān)層轉(zhuǎn)發(fā)到后臺(tái)服務(wù)

后臺(tái)服務(wù)承接流量，調(diào)用緩存獲取數(shù)據(jù)

緩存中無數(shù)據(jù)，則訪問數(shù)據(jù)庫

流量自上而下是逐層遞減的，在網(wǎng)關(guān)層聚集了最多最密集的用戶訪問請求，其次是后臺(tái)服務(wù)。

然后經(jīng)過后臺(tái)服務(wù)的驗(yàn)證邏輯之后，刷掉了一部分錯(cuò)誤請求，剩下的請求落在緩存上，如果緩存中沒有數(shù)據(jù)才會(huì)請求漏斗最下方的數(shù)據(jù)庫，因此數(shù)據(jù)庫層面請求數(shù)量最小（相比較其他組件來說數(shù)據(jù)庫往往是并發(fā)量能力最差的一環(huán)，阿里系的MySQL即便經(jīng)過了大量改造，單機(jī)并發(fā)量也無法和Redis、Kafka之類的組件相比）

目前主流的網(wǎng)關(guān)層有以軟件為代表的Nginx，還有Spring Cloud中的Gateway和Zuul這類網(wǎng)關(guān)層組件

Nginx限流

在系統(tǒng)架構(gòu)中，Nginx的代理與路由轉(zhuǎn)發(fā)是其作為網(wǎng)關(guān)層的一個(gè)很重要的功能，由于Nginx天生的輕量級和優(yōu)秀的設(shè)計(jì)，讓它成為眾多公司的首選，Nginx從網(wǎng)關(guān)這一層面考慮，可以作為最前置的網(wǎng)關(guān)，抵擋大部分的網(wǎng)絡(luò)流量，因此使用Nginx進(jìn)行限流也是一個(gè)很好的選擇，在Nginx中，也提供了常用的基于限流相關(guān)的策略配置.

Nginx 提供了兩種限流方法：一種是控制速率，另一種是控制并發(fā)連接數(shù)。

控制速率

我們需要使用 limit_req_zone 用來限制單位時(shí)間內(nèi)的請求數(shù)，即速率限制，

因?yàn)镹ginx的限流統(tǒng)計(jì)是基于毫秒的，我們設(shè)置的速度是 2r/s，轉(zhuǎn)換一下就是500毫秒內(nèi)單個(gè)IP只允許通過1個(gè)請求，從501ms開始才允許通過第2個(gè)請求。

控制速率優(yōu)化版

上面的速率控制雖然很精準(zhǔn)但是在生產(chǎn)環(huán)境未免太苛刻了，實(shí)際情況下我們應(yīng)該控制一個(gè)IP單位總時(shí)間內(nèi)的總訪問次數(shù)，而不是像上面那樣精確到毫秒，我們可以使用 burst 關(guān)鍵字開啟此設(shè)置

burst=4意思是每個(gè)IP最多允許4個(gè)突發(fā)請求

控制并發(fā)數(shù)

利用 limit_conn_zone 和 limit_conn 兩個(gè)指令即可控制并發(fā)數(shù)

其中 limit_conn perip 10 表示限制單個(gè) IP 同時(shí)最多能持有 10 個(gè)連接；limit_conn perserver 100 表示 server 同時(shí)能處理并發(fā)連接的總數(shù)為 100 個(gè)。

注意：只有當(dāng) request header 被后端處理后，這個(gè)連接才進(jìn)行計(jì)數(shù)。

中間件限流

對于分布式環(huán)境來說，無非是需要一個(gè)類似中心節(jié)點(diǎn)的地方存儲(chǔ)限流數(shù)據(jù)。打個(gè)比方，如果我希望控制接口的訪問速率為每秒100個(gè)請求，那么我就需要將當(dāng)前1s內(nèi)已經(jīng)接收到的請求的數(shù)量保存在某個(gè)地方，并且可以讓集群環(huán)境中所有節(jié)點(diǎn)都能訪問。那我們可以用什么技術(shù)來存儲(chǔ)這個(gè)臨時(shí)數(shù)據(jù)呢？

那么想必大家都能想到，必然是redis了，利用Redis過期時(shí)間特性，我們可以輕松設(shè)置限流的時(shí)間跨度（比如每秒10個(gè)請求，或者每10秒10個(gè)請求）。同時(shí)Redis還有一個(gè)特殊技能–腳本編程，我們可以將限流邏輯編寫成一段腳本植入到Redis中，這樣就將限流的重任從服務(wù)層完全剝離出來，同時(shí)Redis強(qiáng)大的并發(fā)量特性以及高可用集群架構(gòu)也可以很好的支持龐大集群的限流訪問?！緍eids + lua】

限流組件

除了上面介紹的幾種方式以外，目前也有一些開源組件提供了類似的功能，比如Sentinel就是一個(gè)不錯(cuò)的選擇。Sentinel是阿里出品的開源組件，并且包含在了Spring Cloud Alibaba組件庫中，Sentinel提供了相當(dāng)豐富的用于限流的API以及可視化管控臺(tái)，可以很方便的幫助我們對限流進(jìn)行治理

從架構(gòu)維度考慮限流設(shè)計(jì)

在真實(shí)的項(xiàng)目里，不會(huì)只使用一種限流手段，往往是幾種方式互相搭配使用，讓限流策略有一種層次感，達(dá)到資源的最大使用率。在這個(gè)過程中，限流策略的設(shè)計(jì)也可以參考前面提到的漏斗模型，上寬下緊，漏斗不同部位的限流方案設(shè)計(jì)要盡量關(guān)注當(dāng)前組件的高可用。

以我參與的實(shí)際項(xiàng)目為例，比如說我們研發(fā)了一個(gè)商品詳情頁的接口，通過手機(jī)淘寶導(dǎo)流，app端的訪問請求首先會(huì)經(jīng)過阿里的mtop網(wǎng)關(guān)，在網(wǎng)關(guān)層我們的限流會(huì)做的比較寬松，等到請求通過網(wǎng)關(guān)抵達(dá)后臺(tái)的商品詳情頁服務(wù)之后，再利用一系列的中間件+限流組件，對服務(wù)進(jìn)行更加細(xì)致的限流控制

具體的實(shí)現(xiàn)限流的手段

1）Tomcat 使用 maxThreads來實(shí)現(xiàn)限流。

2）Nginx的limit_req_zone和 burst來實(shí)現(xiàn)速率限流。

3）Nginx的limit_conn_zone和 limit_conn兩個(gè)指令控制并發(fā)連接的總數(shù)。

4）時(shí)間窗口算法借助 Redis的有序集合可以實(shí)現(xiàn)。

5）漏桶算法可以使用Redis-Cell來實(shí)現(xiàn)。

6）令牌算法可以解決Google的guava包來實(shí)現(xiàn)。

需要注意的是借助Redis實(shí)現(xiàn)的限流方案可用于分布式系統(tǒng)，而guava實(shí)現(xiàn)的限流只能應(yīng)用于單機(jī)環(huán)境。如果你覺得服務(wù)器端限流麻煩，可以在不改任何代碼的情況下直接使用容器限流（Nginx或Tomcat），但前提是能滿足項(xiàng)目中的業(yè)務(wù)需求。

Tomcat限流

Tomcat 8.5 版本的最大線程數(shù)在 conf/server.xml 配置中，maxThreads 就是 Tomcat 的最大線程數(shù)，當(dāng)請求的并發(fā)大于此值（maxThreads）時(shí)，請求就會(huì)排隊(duì)執(zhí)行，這樣就完成了限流的目的。

注意：

maxThreads 的值可以適當(dāng)?shù)恼{(diào)大一些，Tomcat默認(rèn)為 150（Tomcat 版本 8.5），但這個(gè)值也不是越大越好，要看具體的服務(wù)器配置，需要注意的是每開啟一個(gè)線程需要耗用 1MB 的 JVM 內(nèi)存空間用于作為線程棧之用，并且線程越多 GC 的負(fù)擔(dān)也越重。

最后需要注意一下，操作系統(tǒng)對于進(jìn)程中的線程數(shù)有一定的限制，Windows 每個(gè)進(jìn)程中的線程數(shù)不允許超過 2000，Linux 每個(gè)進(jìn)程中的線程數(shù)不允許超過 1000。

審核編輯 ：李倩