前言

在一個高并發(fā)系統(tǒng)中對流量的把控是非常重要的，當巨大的流量直接請求到我們的服務器上沒多久就可能造成接口不可用，不處理的話甚至會造成整個應用不可用。

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

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

其實不管處理何種場景，本質都是降低流量保證應用的高可用。

常見算法

對于限流常見有兩種算法:

• 漏桶算法

• 令牌桶算法

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

如下圖所示:

?

?

這種做法簡單粗暴。

漏桶算法雖說簡單，但卻不能應對實際場景，比如突然暴增的流量。

這時就需要用到令牌桶算法:

令牌桶會以一個恒定的速率向固定容量大小桶中放入令牌，當有流量來時則取走一個或多個令牌。當桶中沒有令牌則將當前請求丟棄或阻塞。

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

?

?

?

RateLimiter實現(xiàn)

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

?

?

調用結果如下:

?

?

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

使用有幾個值得注意的地方

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

總結

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

PS：為什么你現(xiàn)在應該買一臺云服務器

• 學習需要，特別是想學習進階技術，想做架構設計。

• 上線自己的項目需要，不管是搭建自己的博客，還是自己賺點小錢的項目。

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

• 騰訊云年中最大活動，注冊即領500減350卷！云服務器最低2折，1核1G內存50G硬盤1年只需325元！戳此直達活動現(xiàn)場！

---

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

轉載于:https://blog.51cto.com/13906751/2154371

總結

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

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