就是 常見 一次 一定的 處理 調用 針對 tro 阻塞

前言

在一個高並發系統中對流量的把控是非常重要的，當巨大的流量直接請求到我們的服務器上沒多久就可能造成接口不可用，不處理的話甚至會造成整個應用不可用。
比如最近就有個這樣的需求，我作為客戶端要向kafka生產數據，而kafka的消費者則再源源不斷的消費數據，並將消費的數據全部請求到web服務器，雖說做了負載(有4臺web服務器)但業務數據的量也是巨大的，每秒鐘可能有上萬條數據產生。如果生產者直接生產數據的話極有可能把web服務器拖垮。
對此就必須要做限流處理，每秒鐘生產一定限額的數據到kafka，這樣就能極大程度的保證web的正常運轉。
其實不管處理何種場景，本質都是降低流量保證應用的高可用。

常見算法

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

漏桶算法

令牌桶算法

漏桶算法比較簡單，就是將流量放入桶中，漏桶同時也按照一定的速率流出，如果流量過快的話就會溢出(漏桶並不會提高流出速率)。溢出的流量則直接丟棄。
如下圖所示:
https://user-gold-cdn.xitu.io/2018/8/2/164fa068dd4175c4?imageslim
這種做法簡單粗暴。
漏桶算法雖說簡單，但卻不能應對實際場景，比如突然暴增的流量。
這時就需要用到令牌桶算法:
令牌桶會以一個恒定的速率向固定容量大小桶中放入令牌，當有流量來時則取走一個或多個令牌。當桶中沒有令牌則將當前請求丟棄或阻塞。
相比之下令牌桶可以應對一定的突發流量.
https://user-gold-cdn.xitu.io/2018/8/2/164fa0714e2165b1?imageslim

RateLimiter實現
對於令牌桶的代碼實現，可以直接使用Guava包中的RateLimiter。
https://user-gold-cdn.xitu.io/2018/8/2/164fa078d7ea98f5?imageslim
調用結果如下:
https://user-gold-cdn.xitu.io/2018/8/2/164fa07c2181e936?imageslim
代碼可以看出以每秒向桶中放入兩個令牌，請求一次消耗一個令牌。所以每秒鐘只能發送兩個請求。按照圖中的時間來看也確實如此(返回值是獲取此令牌所消耗的時間，差不多也是每500ms一個)。
使用有幾個值得註意的地方:
允許先消費，後付款，意思就是它可以來一個請求的時候一次性取走幾個或者是剩下所有的令牌甚至多取，但是後面的請求就得為上一次請求買單，它需要等待桶中的令牌補齊之後才能繼續獲取令牌。

總結

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

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