伺服器設計方案之應用限流
在一個高併發系統中對流量的把控是非常重要的，當巨大的流量直接請求到我們的伺服器上沒多久就可能造成介面不可用，不處理的話甚至會造成整個應用不可用。
比如最近就有個這樣的需求，我作為客戶端要向kafka生產資料，而kafka的消費者則再源源不斷的消費資料，並將消費的資料全部請求到web伺服器，雖說做了負載(有4臺web伺服器)但業務資料的量也是巨大的，每秒鐘可能有上萬條資料產生。如果生產者直接生產資料的話極有可能把web伺服器拖垮。
對此就必須要做限流處理，每秒鐘生產一定限額的資料到kafka，這樣就能極大程度的保證web的正常運轉。
其實不管處理何種場景，本質都是降低流量保證應用的高可用。
常見演算法
對於限流常見有兩種演算法:
- 漏桶演算法
- 令牌桶演算法
漏桶演算法比較簡單，就是將流量放入桶中，漏桶同時也按照一定的速率流出，如果流量過快的話就會溢位(漏桶並不會提高流出速率)。溢位的流量則直接丟棄。
如下圖所示:
這種做法簡單粗暴。
漏桶演算法雖說簡單，但卻不能應對實際場景，比如突然暴增的流量。
這時就需要用到令牌桶演算法:
令牌桶會以一個恆定的速率向固定容量大小桶中放入令牌，當有流量來時則取走一個或多個令牌。當桶中沒有令牌則將當前請求丟棄或阻塞。
相比之下令牌桶可以應對一定的突發流量.
RateLimiter實現
對於令牌桶的程式碼實現，可以直接使用Guava包中的RateLimiter。
呼叫結果如下:
程式碼可以看出以每秒向桶中放入兩個令牌，請求一次消耗一個令牌。所以每秒鐘只能傳送兩個請求。按照圖中的時間來看也確實如此(返回值是獲取此令牌所消耗的時間，差不多也是每500ms一個)。
使用有幾個值得注意的地方:
允許先消費，後付款，意思就是它可以來一個請求的時候一次性取走幾個或者是剩下所有的令牌甚至多取，但是後面的請求就得為上一次請求買單，它需要等待桶中的令牌補齊之後才能繼續獲取令牌。
總結
針對於單個應用的限流夠用了，如果是分散式環境可以藉助Redis來完成。