在大數據量高併發訪問時，經常會出現服務或接口面對暴漲的請求而不可用的情況，甚至引發連鎖反映導致整個系統崩潰。此時你需要使用的技術手段之一就是限流，當請求達到一定的併發數或速率，就進行等待、排隊、降級、拒絕服務等。在限流時，常見的兩種算法是漏桶和令牌桶算法算法，本文即對相關內容進行重點介紹。
一、漏桶和令牌桶算法的概念
漏桶算法（Leaky Bucket）：主要目的是控制數據注入到網絡的速率，平滑網絡上的突發流量。漏桶算法提供了一種機制，通過它，突發流量可以被整形以便爲網絡提供一個穩定的流量。漏桶算法的示意圖如下：
請求先進入到漏桶裏，漏桶以一定的速度出水，當水請求過大會直接溢出，可以看出漏桶算法能強行限制數據的傳輸速率。
令牌桶算法（Token Bucket）：是網絡流量整形（Traffic Shaping）和速率限制（Rate Limiting）中最常使用的一種算法。典型情況下，令牌桶算法用來控制發送到網絡上的數據的數目，並允許突發數據的發送。令牌桶算法示意圖如下所示：
大小固定的令牌桶可自行以恆定的速率源源不斷地產生令牌。如果令牌不被消耗，或者被消耗的速度小於產生的速度，令牌就會不斷地增多，直到把桶填滿。後面再產生的令牌就會從桶中溢出。最後桶中可以保存的最大令牌數永遠不會超過桶的大小。
二、兩種算法的區別
兩者主要區別在於“漏桶算法”能夠強行限制數據的傳輸速率，而“令牌桶算法”在能夠限制數據的平均傳輸速率外，還允許某種程度的突發傳輸。在“令牌桶算法”中，只要令牌桶中存在令牌，那麼就允許突發地傳輸數據直到達到用戶配置的門限，所以它適合於具有突發特性的流量。
三、使用Guava的RateLimiter進行限流控制
Guava是google提供的java擴展類庫，其中的限流工具類RateLimiter採用的就是令牌桶算法。RateLimiter 從概念上來講，速率限制器會在可配置的速率下分配許可證，如果必要的話，每個acquire() 會阻塞當前線程直到許可證可用後獲取該許可證，一旦獲取到許可證，不需要再釋放許可證。通俗的講RateLimiter會按照一定的頻率往桶裏扔令牌，線程拿到令牌才能執行，比如你希望自己的應用程序QPS不要超過1000，那麼RateLimiter設置1000的速率後，就會每秒往桶裏扔1000個令牌。例如我們需要處理一個任務列表，但我們不希望每秒的任務提交超過兩個，此時可以採用如下方式：
有一點很重要，那就是請求的許可數從來不會影響到請求本身的限制（調用acquire(1) 和調用acquire(1000) 將得到相同的限制效果，如果存在這樣的調用的話），但會影響下一次請求的限制，也就是說，如果一個高開銷的任務抵達一個空閒的RateLimiter，它會被馬上許可，但是下一個請求會經歷額外的限制，從而來償付高開銷任務。注意：RateLimiter 並不提供公平性的保證。
四、使用Semphore進行併發流控
Java 併發庫的Semaphore 可以很輕鬆完成信號量控制，Semaphore可以控制某個資源可被同時訪問的個數，通過 acquire() 獲取一個許可，如果沒有就等待，而 release() 釋放一個許可。單個信號量的Semaphore對象可以實現互斥鎖的功能，並且可以是由一個線程獲得了“鎖”，再由另一個線程釋放“鎖”，這可應用於死鎖恢復的一些場合。下面的Demo中申明瞭一個只有5個許可的Semaphore，而有20個線程要訪問這個資源，通過acquire()和release()獲取和釋放訪問許可：
最後：進行限流控制還可以有很多種方法，針對不同的場景各有優劣，例如通過AtomicLong計數器控制、使用MQ消息隊列進行流量消峯等等。