限流、熔斷、高可用的思路與方法

日常生活中，有哪些需要限流的地方?像我旁邊有一個(gè)國家景區(qū)，平時(shí)可能根本沒什么人前往，但是一到五一或者春節(jié)就人滿為患，這時(shí)候景區(qū)管理人員就會(huì)實(shí)行一系列的政策來限制進(jìn)入人流量，為什么要限流呢?假如景區(qū)能容納一萬人，現(xiàn)在進(jìn)去了三萬人，勢必摩肩接踵，整不好還會(huì)有事故發(fā)生，這樣的結(jié)果就是所有人的體驗(yàn)都不好，如果發(fā)生了事故景區(qū)可能還要關(guān)閉，導(dǎo)致對(duì)外不可用，這樣的后果就是所有人都覺得體驗(yàn)糟糕透了。限流的思想就是，在保證可用的情況下盡可能多增加進(jìn)入的人數(shù)，其余的人在外面排隊(duì)等待，保證里面的一萬人可以正常游玩。回到網(wǎng)絡(luò)上，同樣也是這個(gè)道理，例如某某明星公布了戀情，訪問從平時(shí)的50萬增加到了500萬，系統(tǒng)最多可以支撐200萬訪問，那么就要執(zhí)行限流規(guī)則，保證是一個(gè)可用的狀態(tài)，不至于服務(wù)器崩潰導(dǎo)致所有請求不可用。限流思路對(duì)系統(tǒng)服務(wù)進(jìn)行限流，一般有如下幾個(gè)模式：熔斷系統(tǒng)在設(shè)計(jì)之初就把熔斷措施考慮進(jìn)去。當(dāng)系統(tǒng)出現(xiàn)問題時(shí)，如果短時(shí)間內(nèi)無法修復(fù)，系統(tǒng)要自動(dòng)做出判斷，開啟熔斷開關(guān)，拒絕流量訪問，避免大流量對(duì)后端的過載請求。系統(tǒng)也應(yīng)該能夠動(dòng)態(tài)監(jiān)測后端程序的修復(fù)情況，當(dāng)程序已恢復(fù)穩(wěn)定時(shí)，可以關(guān)閉熔斷開關(guān)，恢復(fù)正常服務(wù)。常見的熔斷組件有Hystrix以及阿里的Sentinel，兩種互有優(yōu)缺點(diǎn)，可以根據(jù)業(yè)務(wù)的實(shí)際情況進(jìn)行選擇。服務(wù)降級(jí)將系統(tǒng)的所有功能服務(wù)進(jìn)行一個(gè)分級(jí)，當(dāng)系統(tǒng)出現(xiàn)問題需要緊急限流時(shí)，可將不是那么重要的功能進(jìn)行降級(jí)處理，停止服務(wù)，這樣可以釋放出更多的資源供給核心功能的去用。例如在電商平臺(tái)中，如果突發(fā)流量激增，可臨時(shí)將商品評(píng)論、積分等非核心功能進(jìn)行降級(jí)，停止這些服務(wù)，釋放出機(jī)器和CPU等資源來保障用戶正常下單，而這些降級(jí)的功能服務(wù)可以等整個(gè)系統(tǒng)恢復(fù)正常后，再來啟動(dòng)，進(jìn)行補(bǔ)單/補(bǔ)償處理。除了功能降級(jí)以外，還可以采用不直接操作數(shù)據(jù)庫，而全部讀緩存、寫緩存的方式作為臨時(shí)降級(jí)方案。延遲處理這個(gè)模式需要在系統(tǒng)的前端設(shè)置一個(gè)流量緩沖池，將所有的請求全部緩沖進(jìn)這個(gè)池子，不立即處理。然后后端真正的業(yè)務(wù)處理程序從這個(gè)池子中取出請求依次處理，常見的可以用隊(duì)列模式來實(shí)現(xiàn)。這就相當(dāng)于用異步的方式去減少了后端的處理壓力，但是當(dāng)流量較大時(shí)，后端的處理能力有限，緩沖池里的請求可能處理不及時(shí)，會(huì)有一定程度延遲。后面具體的漏桶算法以及令牌桶算法就是這個(gè)思路。特權(quán)處理這個(gè)模式需要將用戶進(jìn)行分類，通過預(yù)設(shè)的分類，讓系統(tǒng)優(yōu)先處理需要高保障的用戶群體，其它用戶群的請求就會(huì)延遲處理或者直接不處理。緩存、降級(jí)、限流區(qū)別緩存，是用來增加系統(tǒng)吞吐量，提升訪問速度提供高并發(fā)。降級(jí)，是在系統(tǒng)某些服務(wù)組件不可用的時(shí)候、流量暴增、資源耗盡等情況下，暫時(shí)屏蔽掉出問題的服務(wù)，繼續(xù)提供降級(jí)服務(wù)，給用戶盡可能的友好提示，返回兜底數(shù)據(jù)，不會(huì)影響整體業(yè)務(wù)流程，待問題解決再重新上線服務(wù)限流，是指在使用緩存和降級(jí)無效的場景。比如當(dāng)達(dá)到閾值后限制接口調(diào)用頻率，訪問次數(shù)，庫存?zhèn)€數(shù)等，在出現(xiàn)服務(wù)不可用之前，提前把服務(wù)降級(jí)。只服務(wù)好一部分用戶。限流的算法限流算法很多，常見的有三類，分別是計(jì)數(shù)器算法、漏桶算法、令牌桶算法，下面逐一講解。計(jì)數(shù)器算法簡單粗暴,比如指定線程池大小，指定數(shù)據(jù)庫連接池大小、nginx連接數(shù)等,這都屬于計(jì)數(shù)器算法。計(jì)數(shù)器算法是限流算法里最簡單也是最容易實(shí)現(xiàn)的一種算法。舉個(gè)例子,比如我們規(guī)定對(duì)于A接口，我們1分鐘的訪問次數(shù)不能超過100個(gè)。那么我們可以這么做：在一開始的時(shí)候，我們可以設(shè)置一個(gè)計(jì)數(shù)器counter，每當(dāng)一個(gè)請求過來的時(shí)候，counter就加1，如果counter的值大于100并且該請求與第一個(gè)請求的間隔時(shí)間還在1分鐘之內(nèi)，那么說明請求數(shù)過多,拒絕訪問；如果該請求與第一個(gè)請求的間隔時(shí)間大于1分鐘，且counter的值還在限流范圍內(nèi)，那么就重置counter,就是這么簡單粗暴。漏桶算法漏桶算法思路很簡單，水（請求）先進(jìn)入到漏桶里，漏桶以一定的速度出水，當(dāng)水流入速度過大會(huì)超過桶可接納的容量時(shí)直接溢出，可以看出漏桶算法能強(qiáng)行限制數(shù)據(jù)的傳輸速率。削峰：有大量流量進(jìn)入時(shí)，會(huì)發(fā)生溢出，從而限流保護(hù)服務(wù)可用緩沖：不至于直接請求到服務(wù)器，緩沖壓力，消費(fèi)速度固定，因?yàn)橛?jì)算性能固定令牌桶算法令牌桶與漏桶相似,不同的是令牌桶桶中放了一些令牌,服務(wù)請求到達(dá)后,要獲取令牌之后才會(huì)得到服務(wù),舉個(gè)例子,我們平時(shí)去食堂吃飯,都是在食堂內(nèi)窗口前排隊(duì)的,這就好比是漏桶算法,大量的人員聚集在食堂內(nèi)窗口外,以一定的速度享受服務(wù),如果涌進(jìn)來的人太多,食堂裝不下了,可能就有一部分人站到食堂外了,這就沒有享受到食堂的服務(wù),稱之為溢出,溢出可以繼續(xù)請求,也就是繼續(xù)排隊(duì),那么這樣有什么問題呢?如果這時(shí)候有特殊情況,比如有些趕時(shí)間的志愿者啦、或者高三要高考啦,這種情況就是突發(fā)情況,如果也用漏桶算法那也得慢慢排隊(duì),這也就沒有解決我們的需求,對(duì)于很多應(yīng)用場景來說，除了要求能夠限制數(shù)據(jù)的平均傳輸速率外，還要求允許某種程度的突發(fā)傳輸。這時(shí)候漏桶算法可能就不合適了，令牌桶算法更為適合。如圖所示，令牌桶算法的原理是系統(tǒng)會(huì)以一個(gè)恒定的速度往桶里放入令牌，而如果請求需要被處理，則需要先從桶里獲取一個(gè)令牌，當(dāng)桶里沒有令牌可取時(shí)，則拒絕服務(wù)。并發(fā)限流簡單來說就是設(shè)置系統(tǒng)閾值總的QPS個(gè)數(shù),這些也挺常見的,就拿Tomcat來說,很多參數(shù)就是出于這個(gè)考慮,例如配置的acceptCount設(shè)置響應(yīng)連接數(shù),maxConnections設(shè)置瞬時(shí)最大連接數(shù),maxThreads設(shè)置最大線程數(shù)，在各個(gè)框架或者組件中，并發(fā)限流體現(xiàn)在下面幾個(gè)方面：?限制總并發(fā)數(shù)（如數(shù)據(jù)庫連接池、線程池）。?限制瞬時(shí)并發(fā)數(shù)（nginx的limit_conn模塊，用來限制瞬時(shí)并發(fā)連接數(shù)）。?限制時(shí)間窗口內(nèi)的平均速率（如Guava的RateLimiter、nginx的limit_req模塊，限制每秒的平均速率）。?其他的還有限制遠(yuǎn)程接口調(diào)用速率、限制MQ的消費(fèi)速率。?另外還可以根據(jù)網(wǎng)絡(luò)連接數(shù)、網(wǎng)絡(luò)流量、CPU或內(nèi)存負(fù)載等來限流。有了并發(fā)限流，就意味著在處理高并發(fā)的時(shí)候多了一種保護(hù)機(jī)制，不用擔(dān)心瞬間流量導(dǎo)致系統(tǒng)掛掉或雪崩，最終做到有損服務(wù)而不是不服務(wù)；但是限流需要評(píng)估好，不能亂用，否則一些正常流量出現(xiàn)一些奇怪的問題而導(dǎo)致用戶體驗(yàn)很差造成用戶流失。接口限流接口限流分為兩個(gè)部分，一是限制一段時(shí)間內(nèi)接口調(diào)用次數(shù),，參照前面限流算法的計(jì)數(shù)器算法,，二是設(shè)置滑動(dòng)時(shí)間窗口算法。接口總數(shù)控制一段時(shí)間內(nèi)接口被調(diào)用的總數(shù)量，可以參考前面的計(jì)數(shù)器算法，不再贅述。接口時(shí)間窗口固定時(shí)間窗口算法(也就是前面提到的計(jì)數(shù)器算法)的問題是統(tǒng)計(jì)區(qū)間太大，限流不夠精確，而且在第二個(gè)統(tǒng)計(jì)區(qū)間時(shí)沒有考慮與前一個(gè)統(tǒng)計(jì)區(qū)間的關(guān)系與影響（第一個(gè)區(qū)間后半段+第二個(gè)區(qū)間前半段也是一分鐘）。為了解決上面我們提到的臨界問題，我們試圖把每個(gè)統(tǒng)計(jì)區(qū)間分為更小的統(tǒng)計(jì)區(qū)間，更精確的統(tǒng)計(jì)計(jì)數(shù)。在上面的例子中，假設(shè)QPS可以接受100次查詢/秒，前一分鐘前40秒訪問很低，后20秒突增，并且這個(gè)持續(xù)了一段時(shí)間，直到第二分鐘的第40秒才開始降下來，根據(jù)前面的計(jì)數(shù)方法，前一秒的QPS為94，后一秒的QPS為92，那么沒有超過設(shè)定參數(shù)，但是！但是在中間區(qū)域，QPS達(dá)到了142，這明顯超過了我們的允許的服務(wù)請求數(shù)目，所以固定窗口計(jì)數(shù)器不太可靠，需要滑動(dòng)窗口計(jì)數(shù)器。計(jì)數(shù)器算法其實(shí)就是固定窗口算法,只是它沒有對(duì)時(shí)間窗口做進(jìn)一步地劃分，所以只有1格；由此可見，當(dāng)滑動(dòng)窗口的格子劃分的越多，也就是將秒精確到毫秒或者納秒,那么滑動(dòng)窗口的滾動(dòng)就越平滑，限流的統(tǒng)計(jì)就會(huì)越精確。需要注意的是,消耗的空間就越多。限流實(shí)現(xiàn)這一部分是限流的具體實(shí)現(xiàn),簡單說說,畢竟長篇代碼沒人愿意看。guava實(shí)現(xiàn)引入包<!--

/artifact/com.google.guava/guava

-->

<dependency>

<groupId>com.google.guava</groupId>

<artifactId>guava</artifactId>

<version>28.1-jre</version>

</dependency>核心代碼LoadingCache<Long,

AtomicLong>

counter

=

CacheBuilder.newBuilder().

expireAfterWrite(2,

TimeUnit.SECONDS)

.build(new

CacheLoader<Long,

AtomicLong>()

{

@Override

public

AtomicLong

load(Long

secend)

throws

Exception

{

//

TODO

Auto-generated

method

stub

return

new

AtomicLong(0);

}

});

counter.get(1l).incrementAndGet();令牌桶實(shí)現(xiàn)穩(wěn)定模式(SmoothBursty:令牌生成速度恒定)public

static

void

main(String[]

args)

{

//

RateLimiter.create(2)每秒產(chǎn)生的令牌數(shù)

RateLimiter

limiter

=

RateLimiter.create(2);

//

limiter.acquire()

阻塞的方式獲取令牌

System.out.println(limiter.acquire());;

try

{

Thread.sleep(2000);

}

catch

(InterruptedException

e)

{

//

TODO

Auto-generated

catch

block

e.printStackTrace();

}

System.out.println(limiter.acquire());;

System.out.println(limiter.acquire());;

System.out.println(limiter.acquire());;

System.out.println(limiter.acquire());;

System.out.println(limiter.acquire());;

System.out.println(limiter.acquire());;

}RateLimiter.create(2)容量和突發(fā)量，令牌桶算法允許將一段時(shí)間內(nèi)沒有消費(fèi)的令牌暫存到令牌桶中，用來突發(fā)消費(fèi)。漸進(jìn)模式(SmoothWarmingUp:令牌生成速度緩慢提升直到維持在一個(gè)穩(wěn)定值)//

平滑限流，從冷啟動(dòng)速率（滿的）到平均消費(fèi)速率的時(shí)間間隔

RateLimiter

limiter

=

RateLimiter.create(2,1000l,TimeUnit.MILLISECONDS);

System.out.println(limiter.acquire());;

try

{

Thread.sleep(2000);

}

catch

(InterruptedException

e)

{

//

TODO

Auto-generated

catch

block

e.printStackTrace();

}

System.out.println(limiter.acquire());

System.out.println(limiter.acquire());

System.out.println(limiter.acquire());

System.out.println(limiter.acquire());

System.out.println(limiter.acquire());

System.out.println(limiter.acquire());超時(shí)boolean

tryAcquire

=

limiter.tryAcquire(Duration.ofMillis(11));

在timeout時(shí)間內(nèi)是否能夠獲得令牌，異步執(zhí)行分布式系統(tǒng)限流Nginx+Lua實(shí)現(xiàn)可以使用resty.lock保持原子特性，請求之間不會(huì)產(chǎn)生鎖的重入使用lua_shared_dict存儲(chǔ)數(shù)據(jù)local

locks

=

require

"resty.lock"

local

function

acquire()

local

lock

=locks:new("locks")

local

elapsed,

err

=lock:lock("limit_key")

--

互斥鎖

保證原子特性

local

limit_counter

=ngx.shared.limit_counter

--

計(jì)數(shù)器

local

key

=

"ip:"

..os.time()

local

limit

=

5

--

限流大小

local

current

=limit_counter:get(key)

if

current

~=

nil

and

current

+

1>

limit

the