RateLimiter是guava提供的基於令牌桶算法的實現類，可以非常簡單的完成限流特技，並且根據系統的實際情況來調整生成token的速率。
通常可應用於搶購限流防止沖垮系統；限制某接口、服務單位時間內的訪問量，譬如一些第三方服務會對用戶訪問量進行限制；限制網速，單位時間內只允許上傳下載多少字節等。
下面來看一些簡單的實踐，需要先引入guava的maven依賴。
一 有很多任務，但希望每秒不超過N個
import com.google.common.util.concurrent.RateLimiter; import java.util.ArrayList; import java.util.List; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; /** * Created by wuwf on 17/7/11. * 有很多個任務，但希望每秒不超過X個，可用此類 */ public class Demo1 { public static void main(String[] args) { //0.5代表一秒最多多少個 RateLimiter rateLimiter = RateLimiter.create(0.5); List<Runnable> tasks = new ArrayList<Runnable>(); for (int i = 0; i < 10; i++) { tasks.add(new UserRequest(i)); } ExecutorService threadPool = Executors.newCachedThreadPool(); for (Runnable runnable : tasks) { System.out.println("等待時間：" + rateLimiter.acquire()); threadPool.execute(runnable); } } private static class UserRequest implements Runnable { private int id; public UserRequest(int id) { this.id = id; } public void run() { System.out.println(id); } } }
該例子是多個線程依次執行，限制每2秒最多執行一個。運行看結果
我們限制了2秒放行一個，可以看到第一個是直接執行了，后面的每2秒會放行一個。
rateLimiter.acquire()該方法會阻塞線程，直到令牌桶中能取到令牌為止才繼續向下執行，並返回等待的時間。
二 搶購場景限流
譬如我們預估數據庫能承受並發10，超過了可能會造成故障，我們就可以對該請求接口進行限流。
package com.tianyalei.controller; import com.google.common.util.concurrent.RateLimiter; import com.tianyalei.model.GoodInfo; import com.tianyalei.service.GoodInfoService; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; import javax.annotation.Resource; /** * Created by wuwf on 17/7/11. */ @RestController public class IndexController { @Resource(name = "db") private GoodInfoService goodInfoService; RateLimiter rateLimiter = RateLimiter.create(10); @RequestMapping("/miaosha") public Object miaosha(int count, String code) { System.out.println("等待時間" + rateLimiter.acquire()); if (goodInfoService.update(code, count) > 0) { return "購買成功"; } return "購買失敗"; } @RequestMapping("/add") public Object add() { for (int i = 0; i < 100; i++) { GoodInfo goodInfo = new GoodInfo(); goodInfo.setCode("iphone" + i); goodInfo.setAmount(100); goodInfoService.add(goodInfo); } return "添加成功"; } }
這個是接着之前的文章（秒殺系統db，http://blog.csdn.net/tianyaleixiaowu/article/details/74389273）加了個Controller
代碼很簡單，就是請求過來時，調用RateLimiter.acquire，如果每秒超過了10個請求，就阻塞等待。我們使用jmeter進行模擬100個並發。
創建一個線程數為100，啟動間隔時間為0的線程組，代表100個並發請求。
初始化10個的容量，所以前10個請求無需等待直接成功，后面的開始被1秒10次限流了，基本上每0.1秒放行一個。
三 搶購場景降級
上面的例子雖然限制了單位時間內對DB的操作，但是對用戶是不友好的，因為他需要等待，不能迅速的得到響應。當你有1萬個並發請求，一秒只能處理10個，那剩余的用戶都會陷入漫長的等待。所以我們需要對應用降級，一旦判斷出某些請求是得不到令牌的，就迅速返回失敗，避免無謂的等待。
由於RateLimiter是屬於單位時間內生成多少個令牌的方式，譬如0.1秒生成1個，那搶購就要看運氣了，你剛好是在剛生成1個時進來了，那么你就能搶到，在這0.1秒內其他的請求就算白瞎了，只能寄希望於下一個0.1秒，而從用戶體驗上來說，不能讓他在那一直阻塞等待，所以就需要迅速判斷，該用戶在某段時間內，還有沒有機會得到令牌，這里就需要使用tryAcquire(long timeout, TimeUnit unit)方法，指定一個超時時間，一旦判斷出在timeout時間內還無法取得令牌，就返回false。注意，這里並不是真正的等待了timeout時間，而是被判斷為即便過了timeout時間，也無法取得令牌。這個是不需要等待的。
看實現：
/**
* tryAcquire(long timeout, TimeUnit unit)
* 從RateLimiter 獲取許可如果該許可可以在不超過timeout的時間內獲取得到的話，
* 或者如果無法在timeout 過期之前獲取得到許可的話，那么立即返回false（無需等待）
*/
@RequestMapping("/buy")
public Object miao(int count, String code) {
//判斷能否在1秒內得到令牌，如果不能則立即返回false，不會阻塞程序
if (!rateLimiter.tryAcquire(1000, TimeUnit.MILLISECONDS)) {
System.out.println("短期無法獲取令牌，真不幸，排隊也瞎排");
return "失敗";
}
if (goodInfoService.update(code, count) > 0) {
System.out.println("購買成功");
return "成功";
}
System.out.println("數據不足，失敗");
return "失敗";
}
在不看執行結果的情況下，我們可以先分析一下，一秒出10個令牌，0.1秒出一個，100個請求進來，假如100個是同時到達，那么最終只能成交10個，90個都會因為超時而失敗。事實上，並不會完全同時到達，必然會出現在0.1秒后到達的，就會被歸入下一個周期。這是一個挺復雜的數學問題，每一個請求都會被計算未來可能獲取到令牌的概率。
還好，RateLimiter有自己的方法去做判斷。
我們運行看結果
多執行幾次，發現每次這個順序都不太一樣。
經過我多次試驗，當設置線程組的間隔時間為0時，最終購買成功的數量總是22.其他的78個都是失敗。但基本都是開始和結束時連續成功，中間的大段失敗。
我修改一下jmeter線程組這100個請求的產生時間為1秒時，結果如下
除了前面幾個和最后幾個請求連續成功，中間的就比較穩定了，都是隔8個9個就會成功一次。
當我修改為2秒內產生100個請求時，結果就更平均了
基本上就是前10個成功，后面的就開始按照固定的速率而成功了。
這種場景更符合實際的應用場景，按照固定的單位時間進行分割，每個單位時間產生一個令牌，可供購買。
看到這里是不是有點明白搶小米的情況了，很多時候並不是你網速快，手速快就能搶到，你需要看后台系統的分配情況。所以你能否搶到，最好是開很多個賬號，而不是一直用一個賬號在猛點，因為你點也白點，后台已經把你的資格排除在外了。
當然了，真正的搶購不是這么簡單，瞬間的流量洪峰會沖垮服務器的負載，當100萬人搶1萬個小米時，連接口都請求不進來，更別提接口里的令牌分配了。
此時就需要做上一層的限流，我們可以選擇在上一層做分布式，開多個服務，先做一次限流，淘汰掉絕大多數運氣不好的用戶，甚至可以隨機丟棄某些規則的用戶，迅速攔截90%的請求，讓你去網頁看單機排隊動畫，還剩10萬。10萬也太大，足以沖垮數據層，那就進隊列MQ，用MQ削峰后，然后才放進業務邏輯里，再進行RateLimiter的限流，此時又能攔截掉90%的不幸者，還剩1萬，1萬去交給業務邏輯和數據層，用redis和DB來處理庫存。恭喜，你就是那個漏網之魚。
重點在於迅速攔截掉99%的不幸者，避免讓他們去接觸到數據層。而且不能等待時間太長，最好是請求的瞬間就能確定你是永遠看單機動畫最好。
/***************************************************************************************************/
補充：
只在本地時效果不怎么明顯，我把這個小工程部署到線上服務器壓測了一下。
首先試了一下去掉了RateLimiter，只用db的Service處理數據的情況，發現mysql的服務占CPU約20%，總體請求失敗率較高。多是Tomcat超時。
使用RateLimiter阻塞后，數據庫CPU基本沒動靜，壓力幾乎沒有，Tomcat超時還有一些，因為還是並發數大，處理不了。
使用RateLimiter非阻塞，超時和請求失敗極少，總體QPS上升了不少。