不會(huì)高并發(fā)系統(tǒng)限流,肯定進(jìn)不了大廠(chǎng)!
開(kāi)濤大神在博客中說(shuō)過(guò):在開(kāi)發(fā)高并發(fā)系統(tǒng)時(shí)有三把利器用來(lái)保護(hù)系統(tǒng):緩存、降級(jí)和限流。本文結(jié)合作者的一些經(jīng)驗(yàn)介紹限流的相關(guān)概念、算法和常規(guī)的實(shí)現(xiàn)方式。
圖片來(lái)自 Pexel
緩存
緩存比較好理解,在大型高并發(fā)系統(tǒng)中,如果沒(méi)有緩存數(shù)據(jù)庫(kù)將分分鐘被爆,系統(tǒng)也會(huì)瞬間癱瘓。
使用緩存不單單能夠提升系統(tǒng)訪(fǎng)問(wèn)速度、提高并發(fā)訪(fǎng)問(wèn)量,也是保護(hù)數(shù)據(jù)庫(kù)、保護(hù)系統(tǒng)的有效方式。大型網(wǎng)站一般主要是“讀”,緩存的使用很容易被想到。
在大型“寫(xiě)”系統(tǒng)中,緩存也常常扮演著非常重要的角色。比如累積一些數(shù)據(jù)批量寫(xiě)入,內(nèi)存里面的緩存隊(duì)列(生產(chǎn)消費(fèi)),以及 HBase 寫(xiě)數(shù)據(jù)的機(jī)制等等也都是通過(guò)緩存提升系統(tǒng)的吞吐量或者實(shí)現(xiàn)系統(tǒng)的保護(hù)措施。
甚至消息中間件,你也可以認(rèn)為是一種分布式的數(shù)據(jù)緩存。
降級(jí)
服務(wù)降級(jí)是當(dāng)服務(wù)器壓力劇增的情況下,根據(jù)當(dāng)前業(yè)務(wù)情況及流量對(duì)一些服務(wù)和頁(yè)面有策略的降級(jí),以此釋放服務(wù)器資源以保證核心任務(wù)的正常運(yùn)行。
降級(jí)往往會(huì)指定不同的級(jí)別,面臨不同的異常等級(jí)執(zhí)行不同的處理。根據(jù)服務(wù)方式:可以拒接服務(wù),可以延遲服務(wù),也有時(shí)候可以隨機(jī)服務(wù)。
根據(jù)服務(wù)范圍:可以砍掉某個(gè)功能,也可以砍掉某些模塊??傊?wù)降級(jí)需要根據(jù)不同的業(yè)務(wù)需求采用不同的降級(jí)策略。主要的目的就是服務(wù)雖然有損但是總比沒(méi)有好。
限流
限流可以認(rèn)為是服務(wù)降級(jí)的一種,限流就是限制系統(tǒng)的輸入和輸出流量以達(dá)到保護(hù)系統(tǒng)的目的。
一般來(lái)說(shuō),系統(tǒng)的吞吐量是可以被測(cè)算的,為了保證系統(tǒng)的穩(wěn)定運(yùn)行,一旦達(dá)到需要限制的閾值,就需要限制流量并采取一些措施以完成限制流量的目的。
比如:延遲處理,拒絕處理,或者部分拒絕處理等等。
限流的算法
常見(jiàn)的限流算法有:計(jì)數(shù)器、漏桶和令牌桶算法。
計(jì)數(shù)器
計(jì)數(shù)器是最簡(jiǎn)單粗暴的算法。比如某個(gè)服務(wù)最多只能每秒鐘處理 100 個(gè)請(qǐng)求。
我們可以設(shè)置一個(gè) 1 秒鐘的滑動(dòng)窗口,窗口中有 10 個(gè)格子,每個(gè)格子 100 毫秒,每 100 毫秒移動(dòng)一次,每次移動(dòng)都需要記錄當(dāng)前服務(wù)請(qǐng)求的次數(shù)。
內(nèi)存中需要保存 10 次的次數(shù),可以用數(shù)據(jù)結(jié)構(gòu) LinkedList 來(lái)實(shí)現(xiàn)。格子每次移動(dòng)的時(shí)候判斷一次,當(dāng)前訪(fǎng)問(wèn)次數(shù)和 LinkedList 中最后一個(gè)相差是否超過(guò) 100,如果超過(guò)就需要限流了。
很明顯,當(dāng)滑動(dòng)窗口的格子劃分的越多,那么滑動(dòng)窗口的滾動(dòng)就越平滑,限流的統(tǒng)計(jì)就會(huì)越精確。
示例代碼如下:
- //服務(wù)訪(fǎng)問(wèn)次數(shù),可以放在Redis中,實(shí)現(xiàn)分布式系統(tǒng)的訪(fǎng)問(wèn)計(jì)數(shù)
- Long counter = 0L;
- //使用LinkedList來(lái)記錄滑動(dòng)窗口的10個(gè)格子。
- LinkedList<Long> ll = new LinkedList<Long>();
- public static void main(String[] args)
- {
- Counter counter = new Counter();
- counter.doCheck();
- }
- private void doCheck()
- {
- while (true)
- {
- ll.addLast(counter);
- if (ll.size() > 10)
- {
- ll.removeFirst();
- }
- //比較最后一個(gè)和第一個(gè),兩者相差一秒
- if ((ll.peekLast() - ll.peekFirst()) > 100)
- {
- //To limit rate
- }
- Thread.sleep(100);
- }
- }
漏桶算法
漏桶算法即 leaky bucket 是一種非常常用的限流算法,可以用來(lái)實(shí)現(xiàn)流量整形(Traffic Shaping)和流量控制(Traffic Policing)。
貼了一張維基百科上示意圖幫助大家理解:
漏桶算法的主要概念如下:
- 一個(gè)固定容量的漏桶,按照常量固定速率流出水滴。
- 如果桶是空的,則不需流出水滴。
- 可以以任意速率流入水滴到漏桶。
- 如果流入水滴超出了桶的容量,則流入的水滴溢出了(被丟棄),而漏桶容量是不變的。
漏桶算法比較好實(shí)現(xiàn),在單機(jī)系統(tǒng)中可以使用隊(duì)列來(lái)實(shí)現(xiàn)(.Net 中 TPL DataFlow 可以較好的處理類(lèi)似的問(wèn)題,你可以在這里找到相關(guān)的介紹),在分布式環(huán)境中消息中間件或者 Redis 都是可選的方案。
令牌桶算法
令牌桶算法是一個(gè)存放固定容量令牌(token)的桶,按照固定速率往桶里添加令牌。
令牌桶算法基本可以用下面的幾個(gè)概念來(lái)描述:
- 令牌將按照固定的速率被放入令牌桶中。比如每秒放 10 個(gè)。
- 桶中最多存放 b 個(gè)令牌,當(dāng)桶滿(mǎn)時(shí),新添加的令牌被丟棄或拒絕。
- 當(dāng)一個(gè) n 個(gè)字節(jié)大小的數(shù)據(jù)包到達(dá),將從桶中刪除 n 個(gè)令牌,接著數(shù)據(jù)包被發(fā)送到網(wǎng)絡(luò)上。
- 如果桶中的令牌不足 n 個(gè),則不會(huì)刪除令牌,且該數(shù)據(jù)包將被限流(要么丟棄,要么緩沖區(qū)等待)。
如下圖:
令牌算法是根據(jù)放令牌的速率去控制輸出的速率,也就是上圖的 to network 的速率。to network 我們可以理解為消息的處理程序,執(zhí)行某段業(yè)務(wù)或者調(diào)用某個(gè) RPC。
漏桶和令牌桶的比較
令牌桶可以在運(yùn)行時(shí)控制和調(diào)整數(shù)據(jù)處理的速率,處理某時(shí)的突發(fā)流量。
放令牌的頻率增加可以提升整體數(shù)據(jù)處理的速度,而通過(guò)每次獲取令牌的個(gè)數(shù)增加或者放慢令牌的發(fā)放速度可以降低整體數(shù)據(jù)處理速度。
而漏桶不行,因?yàn)樗牧鞒鏊俾适枪潭ǖ模绦蛱幚硭俣纫彩枪潭ǖ?。整體而言,令牌桶算法更優(yōu),但是實(shí)現(xiàn)更為復(fù)雜一些。
限流算法實(shí)現(xiàn)
Guava
Guava 是一個(gè) Google 開(kāi)源項(xiàng)目,包含了若干被 Google 的 Java 項(xiàng)目廣泛依賴(lài)的核心庫(kù),其中的 RateLimiter 提供了令牌桶算法實(shí)現(xiàn):平滑突發(fā)限流(SmoothBursty)和平滑預(yù)熱限流(SmoothWarmingUp)實(shí)現(xiàn)。
①常規(guī)速率:創(chuàng)建一個(gè)限流器,設(shè)置每秒放置的令牌數(shù):2 個(gè)。
返回的 RateLimiter 對(duì)象可以保證 1 秒內(nèi)不會(huì)給超過(guò) 2 個(gè)令牌,并且是固定速率的放置。達(dá)到平滑輸出的效果:
- public void test()
- {
- /**
- * 創(chuàng)建一個(gè)限流器,設(shè)置每秒放置的令牌數(shù):2個(gè)。速率是每秒可以2個(gè)的消息。
- * 返回的RateLimiter對(duì)象可以保證1秒內(nèi)不會(huì)給超過(guò)2個(gè)令牌,并且是固定速率的放置。達(dá)到平滑輸出的效果
- */
- RateLimiter r = RateLimiter.create(2);
- while (true)
- {
- /**
- * acquire()獲取一個(gè)令牌,并且返回這個(gè)獲取這個(gè)令牌所需要的時(shí)間。如果桶里沒(méi)有令牌則等待,直到有令牌。
- * acquire(N)可以獲取多個(gè)令牌。
- */
- System.out.println(r.acquire());
- }
- }
上面代碼執(zhí)行的結(jié)果如下圖,基本是 0.5 秒一個(gè)數(shù)據(jù)。拿到令牌后才能處理數(shù)據(jù),達(dá)到輸出數(shù)據(jù)或者調(diào)用接口的平滑效果。
acquire() 的返回值是等待令牌的時(shí)間,如果需要對(duì)某些突發(fā)的流量進(jìn)行處理的話(huà),可以對(duì)這個(gè)返回值設(shè)置一個(gè)閾值,根據(jù)不同的情況進(jìn)行處理,比如過(guò)期丟棄。
②突發(fā)流量:突發(fā)流量可以是突發(fā)的多,也可以是突發(fā)的少。首先來(lái)看個(gè)突發(fā)多的例子。還是上面例子的流量,每秒 2 個(gè)數(shù)據(jù)令牌。
如下代碼使用 acquire 方法,指定參數(shù):
- System.out.println(r.acquire(2));
- System.out.println(r.acquire(1));
- System.out.println(r.acquire(1));
- System.out.println(r.acquire(1));
得到如下類(lèi)似的輸出。
如果要一次新處理更多的數(shù)據(jù),則需要更多的令牌。代碼首先獲取 2 個(gè)令牌,那么下一個(gè)令牌就不是 0.5 秒之后獲得了,還是 1 秒以后,之后又恢復(fù)常規(guī)速度。
這是一個(gè)突發(fā)多的例子,如果是突發(fā)沒(méi)有流量,如下代碼:
- System.out.println(r.acquire(1));
- Thread.sleep(2000);
- System.out.println(r.acquire(1));
- System.out.println(r.acquire(1));
- System.out.println(r.acquire(1));
得到如下類(lèi)似的結(jié)果:
等了兩秒鐘之后,令牌桶里面就積累了 3 個(gè)令牌,可以連續(xù)不花時(shí)間的獲取出來(lái)。處理突發(fā)其實(shí)也就是在單位時(shí)間內(nèi)輸出恒定。
這兩種方式都是使用的 RateLimiter 的子類(lèi) SmoothBursty。另一個(gè)子類(lèi)是 SmoothWarmingUp,它提供的有一定緩沖的流量輸出方案。
- /**
- * 創(chuàng)建一個(gè)限流器,設(shè)置每秒放置的令牌數(shù):2個(gè)。速率是每秒可以210的消息。
- * 返回的RateLimiter對(duì)象可以保證1秒內(nèi)不會(huì)給超過(guò)2個(gè)令牌,并且是固定速率的放置。達(dá)到平滑輸出的效果
- * 設(shè)置緩沖時(shí)間為3秒
- */
- RateLimiter r = RateLimiter.create(2,3,TimeUnit.SECONDS);
- while (true) {
- /**
- * acquire()獲取一個(gè)令牌,并且返回這個(gè)獲取這個(gè)令牌所需要的時(shí)間。如果桶里沒(méi)有令牌則等待,直到有令牌。
- * acquire(N)可以獲取多個(gè)令牌。
- */
- System.out.println(r.acquire(1));
- System.out.println(r.acquire(1));
- System.out.println(r.acquire(1));
- System.out.println(r.acquire(1));
- }
輸出結(jié)果如下圖,由于設(shè)置了緩沖的時(shí)間是 3 秒,令牌桶一開(kāi)始并不會(huì) 0.5 秒給一個(gè)消息,而是形成一個(gè)平滑線(xiàn)性下降的坡度,頻率越來(lái)越高,在 3 秒鐘之內(nèi)達(dá)到原本設(shè)置的頻率,以后就以固定的頻率輸出。
圖中紅線(xiàn)圈出來(lái)的 3 次累加起來(lái)正好是 3 秒左右。這種功能適合系統(tǒng)剛啟動(dòng)需要一點(diǎn)時(shí)間來(lái)“熱身”的場(chǎng)景。
Nginx
對(duì)于 Nginx 接入層限流可以使用 Nginx 自帶的兩個(gè)模塊:
- 連接數(shù)限流模塊:ngx_http_limit_conn_module
- 漏桶算法實(shí)現(xiàn)的請(qǐng)求限流模塊:ngx_http_limit_req_module
①ngx_http_limit_conn_module
我們經(jīng)常會(huì)遇到這種情況,服務(wù)器流量異常,負(fù)載過(guò)大等等。對(duì)于大流量惡意的攻擊訪(fǎng)問(wèn),會(huì)帶來(lái)帶寬的浪費(fèi),服務(wù)器壓力,影響業(yè)務(wù),往往考慮對(duì)同一個(gè) IP 的連接數(shù),并發(fā)數(shù)進(jìn)行限制。
ngx_http_limit_conn_module 模塊來(lái)實(shí)現(xiàn)該需求。該模塊可以根據(jù)定義的鍵來(lái)限制每個(gè)鍵值的連接數(shù),如同一個(gè) IP 來(lái)源的連接數(shù)。
并不是所有的連接都會(huì)被該模塊計(jì)數(shù),只有那些正在被處理的請(qǐng)求(這些請(qǐng)求的頭信息已被完全讀入)所在的連接才會(huì)被計(jì)數(shù)。
我們可以在 nginx_conf 的 http{} 中加上如下配置實(shí)現(xiàn)限制:
- #限制每個(gè)用戶(hù)的并發(fā)連接數(shù),取名one
- limit_conn_zone $binary_remote_addr zone=one:10m;
- #配置記錄被限流后的日志級(jí)別,默認(rèn)error級(jí)別
- limit_conn_log_level error;
- #配置被限流后返回的狀態(tài)碼,默認(rèn)返回503
- limit_conn_status 503;
然后在 server{} 里加上如下代碼:
- #限制用戶(hù)并發(fā)連接數(shù)為1
- limit_conn one 1;
然后我們是使用 ab 測(cè)試來(lái)模擬并發(fā)請(qǐng)求:
ab -n 5 -c 5 http://10.23.22.239/index.html
得到下面的結(jié)果,很明顯并發(fā)被限制住了,超過(guò)閾值的都顯示 503:
另外剛才是配置針對(duì)單個(gè) IP 的并發(fā)限制,還是可以針對(duì)域名進(jìn)行并發(fā)限制,配置和客戶(hù)端 IP 類(lèi)似。
- #http{}段配置
- limit_conn_zone $ server_name zone=perserver:10m;
- #server{}段配置
- limit_conn perserver 1;
②ngx_http_limit_req_module
上面我們使用到了 ngx_http_limit_conn_module 模塊,來(lái)限制連接數(shù)。那么請(qǐng)求數(shù)的限制該怎么做呢?
這就需要通過(guò) ngx_http_limit_req_module 模塊來(lái)實(shí)現(xiàn),該模塊可以通過(guò)定義的鍵值來(lái)限制請(qǐng)求處理的頻率。
特別的,可以限制來(lái)自單個(gè) IP 地址的請(qǐng)求處理頻率。限制的方法是使用了漏斗算法,每秒固定處理請(qǐng)求數(shù),推遲過(guò)多請(qǐng)求。
如果請(qǐng)求的頻率超過(guò)了限制域配置的值,請(qǐng)求處理會(huì)被延遲或被丟棄,所以所有的請(qǐng)求都是以定義的頻率被處理的。
在 http{} 中配置,#區(qū)域名稱(chēng)為 one,大小為 10m,平均處理的請(qǐng)求頻率不能超過(guò)每秒一次。
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
在 server{} 中配置:
- 設(shè)置每個(gè)IP桶的數(shù)量為5
- limit_req zone=one burst=5;
上面設(shè)置定義了每個(gè) IP 的請(qǐng)求處理只能限制在每秒 1 個(gè)。并且服務(wù)端可以為每個(gè) IP 緩存 5 個(gè)請(qǐng)求,如果操作了 5 個(gè)請(qǐng)求,請(qǐng)求就會(huì)被丟棄。
使用 ab 測(cè)試模擬客戶(hù)端連續(xù)訪(fǎng)問(wèn) 10 次:
ab -n 10 -c 10 http://10.23.22.239/index.html
如下圖,設(shè)置了桶的個(gè)數(shù)為 5 個(gè)。一共 10 個(gè)請(qǐng)求,第一個(gè)請(qǐng)求馬上被處理。第 2-6 個(gè)被存放在桶中。
由于桶滿(mǎn)了,沒(méi)有設(shè)置 nodelay 因此,余下的 4 個(gè)請(qǐng)求被丟棄: