前言

在一個高併發系統中對流量的把控是非常重要的，當巨大的流量直接請求到我們的伺服器上沒多久就可能造成介面不可用，不處理的話甚至會造成整個應用不可用。

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

       對此就必須要做限流處理，每秒鐘生產一定限額的資料到kafka，這樣就能極大程度的保證web的正常運轉。

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

常見演算法

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

漏桶演算法

令牌桶演算法

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

如下圖所示:

       這種做法簡單粗暴。

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

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

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

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

RateLimiter實現

       對於令牌桶的程式碼實現，可以直接使用Guava包中的RateLimiter。

呼叫結果如下:

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

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

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

總結

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

 

如果對自己未來有想法，想提升自己，你現在在JAVA這條路上掙扎，也想在IT行業拿高薪，可以參加我們免費的公開課試聽學習 乾貨滿滿的，選擇最適合自己的課程學習，技術大牛親授，課程內容有：Java工程化、高效能及分散式、高效能、深入淺出。高架構。效能調優、Spring，MyBatis，Netty原始碼分析和大資料等多個知識點。如果你想拿高薪的，想學習的，想就業前景好的，想跟別人競爭能取得優勢的，想進阿里面試但擔心面試不過的，你都可以來。群號：468947140

先分享幾節你們自己看一下 乾貨滿滿的 能看懂這些視訊再加吧

高可用叢集架構技術進階篇手把手教你玩轉Nginx與Docker

連結：https://pan.baidu.com/s/1NL0QKHQMmDkxqF-TzetdaA

密碼：w61n

走向架構師，你必須瞭解的Java虛擬機器高階特性

連結：https://pan.baidu.com/s/1hlrZEhVPdWLWb_Wnr9pgtA

密碼：rlxn

高併發處理技術老司機帶你玩RabbitMq實現效能倍增

連結：https://pan.baidu.com/s/1tdWyeXgXzbWsltY8NlhdaQ

密碼：ripd