前言

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

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

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

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

常見算法

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

• 漏桶算法

• 令牌桶算法

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

如下圖所示:

?

?

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

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

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

令牌桶會(huì)以一個(gè)恒定的速率向固定容量大小桶中放入令牌，當(dāng)有流量來時(shí)則取走一個(gè)或多個(gè)令牌。當(dāng)桶中沒有令牌則將當(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í)間來看也確實(shí)如此(返回值是獲取此令牌所消耗的時(shí)間，差不多也是每500ms一個(gè))。

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

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

總結(jié)

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

PS：為什么你現(xiàn)在應(yīng)該買一臺(tái)云服務(wù)器

• 學(xué)習(xí)需要，特別是想學(xué)習(xí)進(jìn)階技術(shù)，想做架構(gòu)設(shè)計(jì)。

• 上線自己的項(xiàng)目需要，不管是搭建自己的博客，還是自己賺點(diǎn)小錢的項(xiàng)目。

• 云服務(wù)器便宜，服務(wù)器現(xiàn)在白菜價(jià)。

• 騰訊云年中最大活動(dòng)，注冊(cè)即領(lǐng)500減350卷！云服務(wù)器最低2折，1核1G內(nèi)存50G硬盤1年只需325元！戳此直達(dá)活動(dòng)現(xiàn)場(chǎng)！

---

作者：慕容千語
鏈接：https://juejin.im/post/5b62d1ea5188251b3a1de69c

轉(zhuǎn)載于:https://blog.51cto.com/13906751/2154371

總結(jié)

以上是生活随笔為你收集整理的Java编程——服务器设计方案之应用限流的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。