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

標籤：use   一個   設計方案   分布式   高並發   web   ofo   兩種   分布   

前言

在一個高並發系統中對流量的把控是非常重要的，當巨大的流量直接請求到我們的伺服器上沒多久就可能造成介面不可用，不處理的話甚至會造成整個應用不可用。
比如最近就有個這樣的需求，我作為用戶端要向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編程——伺服器設計方案之應用限流