使用RateLimiter完成簡單的大流量限流
公司券系統壓力過大，採用了限流的方法。
public Integer couponSendWithLimiter(CouponLogQC couponLogQC) {
//限制每秒請求數 30秒每個使用者只能請求一次
String uniqueCode = this.uniqueCode(couponLogQC);
boolean isDuplicated = deDuplicationService.isSent(uniqueCode);
if (isDuplicated) {
return 0;
}
if (!rateLimiterService.tryAcquire()) {
// 轉發至MQ
amqpTemplate.convertAndSend(......);
return 1;
} else {
return this.couponSend(couponLogQC);
}
}自己又研究了一下rateLimiter限流的原理：
RateLimiter是guava提供的基於令牌桶演算法的實現類，可以非常簡單的完成限流特技，並且根據系統的實際情況來調整生成token的速率。
通常可應用於搶購限流防止沖垮系統；限制某介面、服務單位時間內的訪問量，譬如一些第三方服務會對使用者訪問量進行限制；限制網速，單位時間內只允許上傳下載多少位元組等。
下面來看一些簡單的實踐，需要先引入guava的maven依賴。
一 有很多工，但希望每秒不超過N個
[java] view plaincopyprint?
- 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秒最多執行一個。執行看結果
rateLimiter.acquire()該方法會阻塞執行緒，直到令牌桶中能取到令牌為止才繼續向下執行，並返回等待的時間。
二 搶購場景限流
譬如我們預估資料庫能承受併發10，超過了可能會造成故障，我們就可以對該請求介面進行限流。
[java] view plaincopyprint?
- 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個併發請求。
啟動jmeter請求，看控制檯結果
初始化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時間，也無法取得令牌。這個是不需要等待的。
看實現：
[java] view plaincopyprint?
- /**
- * 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上升了不少。
測試不太正規，就大概跑了跑。