Java編程架構——服務器設計方案之應用限流

前言
在一個高併發系統中對流量的把控是很是重要的，當巨大的流量直接請求到咱們的服務器上沒多久就可能形成接口不可用，不處理的話甚至會形成整個應用不可用。

好比最近就有個這樣的需求，我做爲客戶端要向kafka生產數據，而kafka的消費者則再源源不斷的消費數據，並將消費的數據所有請求到web服務器，雖然說作了負載(有4臺web服務器)但業務數據的量也是巨大的，每秒鐘可能有上萬條數據產生。若是生產者直接生產數據的話極有可能把web服務器拖垮。

對此就必需要作限流處理，每秒鐘生產必定限額的數據到kafka，這樣就能極大程度的保證web的正常運轉。

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

**常見算法
對於限流常見有兩種算法:
漏桶算法
令牌桶算法**

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

以下圖所示:

這種作法簡單粗暴。

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

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

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

相比之下令牌桶能夠應對必定的突發流量.

RateLimiter實現

對於令牌桶的代碼實現，能夠直接使用Guava包中的RateLimiter。

調用結果以下:

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

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

容許先消費，後付款，意思就是它能夠來一個請求的時候一次性取走幾個或者是剩下全部的令牌甚至多取，可是後面的請求就得爲上一次請求買單，它須要等待桶中的令牌補齊以後才能繼續獲取令牌。

總結
針對於單個應用的限流夠用了，若是是分佈式環境能夠藉助Redis來完成。

喜歡的點點關注點點贊，支持下