在一個(gè)高并發(fā)系統(tǒng)中對(duì)流量的把控是非常重要的，當(dāng)巨大的流量直接請(qǐng)求到我們的服務(wù)器上沒(méi)多久就可能造成接口不可用，不處理的話(huà)甚至?xí)�造成整個(gè)應(yīng)用不可用。

比如最近就有個(gè)這樣的需求，我作為客戶(hù)端要向kafka生產(chǎn)數(shù)據(jù)，而kafka的消費(fèi)者則再源源不斷的消費(fèi)數(shù)據(jù)，并將消費(fèi)的數(shù)據(jù)全部請(qǐng)求到web服務(wù)器，雖說(shuō)做了負(fù)載(有4臺(tái)web服務(wù)器)但業(yè)務(wù)數(shù)據(jù)的量也是巨大的，每秒鐘可能有上萬(wàn)條數(shù)據(jù)產(chǎn)生。如果生產(chǎn)者直接生產(chǎn)數(shù)據(jù)的話(huà)極有可能把web服務(wù)器拖垮。

對(duì)此就必須要做限流處理，每秒鐘生產(chǎn)一定限額的數(shù)據(jù)到kafka，這樣就能極大程度的保證web的正常運(yùn)轉(zhuǎn)。

其實(shí)不管處理何種場(chǎng)景，本質(zhì)都是降低流量保證應(yīng)用的高可用。

常見(jiàn)算法

對(duì)于限流常見(jiàn)有兩種算法:

漏桶算法

令牌桶算法

漏桶算法比較簡(jiǎn)單，就是將流量放入桶中，漏桶同時(shí)也按照一定的速率流出，如果流量過(guò)快的話(huà)就會(huì)溢出(漏桶并不會(huì)提高流出速率)。溢出的流量則直接丟棄。

如下圖所示:

這種做法簡(jiǎn)單粗暴。

漏桶算法雖說(shuō)簡(jiǎn)單，但卻不能應(yīng)對(duì)實(shí)際場(chǎng)景，比如突然暴增的流量。

這時(shí)就需要用到令牌桶算法:

令牌桶會(huì)以一個(gè)恒定的速率向固定容量大小桶中放入令牌，當(dāng)有流量來(lái)時(shí)則取走一個(gè)或多個(gè)令牌。當(dāng)桶中沒(méi)有令牌則將當(dāng)前請(qǐng)求丟棄或阻塞。

相比之下令牌桶可以應(yīng)對(duì)一定的突發(fā)流量.

RateLimiter實(shí)現(xiàn)

對(duì)于令牌桶的代碼實(shí)現(xiàn)，可以直接使用Guava包中的RateLimiter。

調(diào)用結(jié)果如下:

代碼可以看出以每秒向桶中放入兩個(gè)令牌，請(qǐng)求一次消耗一個(gè)令牌。所以每秒鐘只能發(fā)送兩個(gè)請(qǐng)求。按照?qǐng)D中的時(shí)間來(lái)看也確實(shí)如此(返回值是獲取此令牌所消耗的時(shí)間，差不多也是每500ms一個(gè))。

使用有幾個(gè)值得注意的地方:

允許先消費(fèi)，后付款，意思就是它可以來(lái)一個(gè)請(qǐng)求的時(shí)候一次性取走幾個(gè)或者是剩下所有的令牌甚至多取，但是后面的請(qǐng)求就得為上一次請(qǐng)求買(mǎi)單，它需要等待桶中的令牌補(bǔ)齊之后才能繼續(xù)獲取令牌。

總結(jié)

針對(duì)于單個(gè)應(yīng)用的限流夠用了，如果是分布式環(huán)境可以借助Redis來(lái)完成。

本文鏈接：http://m.51huadong.com/cloundnews/11002949.html