高併發處理之介面限流
最近開發的搶購活動上線後發現了兩個比較明顯的問題，其一：活動一開始，介面訪問量劇增；其二：黑名單中增加了一大批黑名單使用者（或者說IP），這其中就包含了一些惡意使用者或機器人刷介面。
針對一些高併發的介面，限流是處理高併發的幾大利劍之一。一方面，限流可以防止介面被刷，造成不必要的服務層壓力，另一方面，是為了防止介面被濫用。
限流的方式也蠻多，本篇只講幾種我自己常用的，並且是後端的限流操作。
漏桶演算法
漏桶演算法思路很簡單，水（請求）先進入到漏桶裡，漏桶以一定的速度出水，當水流入速度過大會直接溢位，可以看出漏桶演算法能強行限制資料的傳輸速率。
漏桶演算法示意圖(圖片取自網路)
漏桶演算法可以很好地限制容量池的大小，從而防止流量暴增。
令牌桶演算法
令牌桶演算法的原理是系統會以一個恆定的速度往桶裡放入令牌，而如果請求需要被處理，則需要先從桶裡獲取一個令牌，當桶裡沒有令牌可取時，則拒絕服務。
令牌桶演算法示意圖(圖片取自網路)
令牌桶演算法通過發放令牌，根據令牌的rate頻率做請求頻率限制，容量限制等。
自定義註解+攔截器+Redis實現限流
從程式碼層面來看，此方式實現還是比較優雅的，對業務層也沒有太多的耦合。注意:此種方式單體和分散式均適用，因為使用者實際的訪問次數都是存在redis容器裡的，和應用的單體或分散式無關。
@Inherited @Documented @Target({ElementType.FIELD,ElementType.TYPE,ElementType.METHOD}) @Retention(RetentionPolicy.RUNTIME) public @interface AccessLimit { //標識 指定sec時間段內的訪問次數限制 int limit() default 5; //標識 時間段 int sec() default 5; }
public class AccessLimitInterceptor implements HandlerInterceptor { //使用RedisTemplate操作redis @Autowired private RedisTemplate<String, Integer> redisTemplate; @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (handler instanceof HandlerMethod) { HandlerMethod handlerMethod = (HandlerMethod) handler; Method method = handlerMethod.getMethod(); if (!method.isAnnotationPresent(AccessLimit.class)) { return true; } AccessLimit accessLimit = method.getAnnotation(AccessLimit.class); if (accessLimit == null) { return true; } int limit = accessLimit.limit(); int sec = accessLimit.sec(); String key = IPUtil.getIpAddr(request) + request.getRequestURI(); Integer maxLimit = redisTemplate.opsForValue().get(key); if (maxLimit == null) { //set時一定要加過期時間 redisTemplate.opsForValue().set(key, 1, sec, TimeUnit.SECONDS); } else if (maxLimit < limit) { redisTemplate.opsForValue().set(key, maxLimit + 1, sec, TimeUnit.SECONDS); } else { output(response, "請求太頻繁!"); return false; } } return true; } public void output(HttpServletResponse response, String msg) throws IOException { response.setContentType("application/json;charset=UTF-8"); ServletOutputStream outputStream = null; try { outputStream = response.getOutputStream(); outputStream.write(msg.getBytes("UTF-8")); } catch (IOException e) { e.printStackTrace(); } finally { outputStream.flush(); outputStream.close(); } } @Override public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception { } @Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception { } }
@Controller
@RequestMapping("/activity")
public class AopController {
@ResponseBody
@RequestMapping("/seckill")
@AccessLimit(limit = 4,sec = 10) //加上自定義註解即可
public String test (HttpServletRequest request,@RequestParam(value = "username",required = false) String userName){
//TODO somethings……
return "hello world !";
}
}/*springmvc的配置檔案中加入自定義攔截器*/
<mvc:interceptors>
<mvc:interceptor>
<mvc:mapping path="/**"/>
<bean class="com.pptv.activityapi.controller.pointsmall.AccessLimitInterceptor"/>
</mvc:interceptor>
</mvc:interceptors>訪問效果如下，10s內訪問介面超過4次以上就過濾請求，原理和計數器演算法類似：
Guava的RateLimiter實現限流
guava提供的RateLimiter可以限制物理或邏輯資源的被訪問速率，咋一聽有點像java併發包下的Samephore，但是又不相同，RateLimiter控制的是速率，Samephore控制的是併發量。RateLimiter的原理就是令牌桶，它主要由許可發出的速率來定義，如果沒有額外的配置，許可證將按每秒許可證規定的固定速度分配，許可將被平滑地分發，若請求超過permitsPerSecond則RateLimiter按照每秒 1/permitsPerSecond 的速率釋放許可。注意:RateLimiter適用於單體應用。下面簡單的寫個測試：
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>23.0</version>
</dependency>public static void main(String[] args) {
String start = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(new Date());
RateLimiter limiter = RateLimiter.create(1.0); // 這裡的1表示每秒允許處理的量為1個
for (int i = 1; i <= 10; i++) {
limiter.acquire();// 請求RateLimiter, 超過permits會被阻塞
System.out.println("call execute.." + i);
}
String end = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(new Date());
System.out.println("start time:" + start);
System.out.println("end time:" + end);
}
可以看到，我假定了每秒處理請求的速率為1個，現在我有10個任務要處理，那麼RateLimiter就很好的實現了控制速率，總共10個任務，需要9次獲取許可，所以最後10個任務的消耗時間為9s左右。
放在Controller中用Jemter壓測一下：
可以看到，模擬了20個併發請求，並設定了QPS為1，那麼20個併發請求實現了限流的目的，後續的請求都要阻塞1s左右時間才能返回。要注意的是RateLimiter不保證公平性訪問！
----------------------------------------這是一條分隔線 2018-06-14補充---------------------------------------
針對實際專案使用RateLimiter來限流，正確的開啟方式應該還有更好的方式，對於這個問題，我在github上提問了，並得到了相應的解答，問題討論區在這裡：https://github.com/google/guava/issues/3180
-----------------------------------------這又是一點分隔線 2018-08-16補充-----------------------------------
今天翻閱是發現使用上述方式使用RateLimiter的方式不夠優雅，儘管我們可以把RateLimiter的邏輯包在service裡面，controller直接呼叫即可，但是如果我們換成：自定義註解+AOP的方式實現的話，會優雅的多，詳細見下面程式碼：
自定義註解
import java.lang.annotation.*;
/**
* 自定義註解可以不包含屬性，成為一個標識註解
*/
@Inherited
@Documented
@Target({ElementType.METHOD, ElementType.FIELD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
public @interface RateLimitAspect {
}自定義切面類
import com.google.common.util.concurrent.RateLimiter;
import com.simons.cn.springbootdemo.util.ResultUtil;
import net.sf.json.JSONObject;
import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.annotation.Scope;
import org.springframework.stereotype.Component;
import javax.servlet.ServletOutputStream;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
@Component
@Scope
@Aspect
public class RateLimitAop {
@Autowired
private HttpServletResponse response;
private RateLimiter rateLimiter = RateLimiter.create(5.0); //比如說，我這裡設定"併發數"為5
@Pointcut("@annotation(com.simons.cn.springbootdemo.aspect.RateLimitAspect)")
public void serviceLimit() {
}
@Around("serviceLimit()")
public Object around(ProceedingJoinPoint joinPoint) {
Boolean flag = rateLimiter.tryAcquire();
Object obj = null;
try {
if (flag) {
obj = joinPoint.proceed();
}else{
String result = JSONObject.fromObject(ResultUtil.success1(100, "failure")).toString();
output(response, result);
}
} catch (Throwable e) {
e.printStackTrace();
}
System.out.println("flag=" + flag + ",obj=" + obj);
return obj;
}
public void output(HttpServletResponse response, String msg) throws IOException {
response.setContentType("application/json;charset=UTF-8");
ServletOutputStream outputStream = null;
try {
outputStream = response.getOutputStream();
outputStream.write(msg.getBytes("UTF-8"));
} catch (IOException e) {
e.printStackTrace();
} finally {
outputStream.flush();
outputStream.close();
}
}
}測試controller
import com.simons.cn.springbootdemo.aspect.RateLimitAspect;
import com.simons.cn.springbootdemo.util.ResultUtil;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.ResponseBody;
/**
* 類描述：RateLimit限流測試（基於註解+AOP）
* 建立人：simonsfan
*/
@Controller
public class TestController {
@ResponseBody
@RateLimitAspect
@RequestMapping("/test")
public String test(){
return ResultUtil.success1(1001, "success").toString();
}這樣通過自定義註解@RateLimiterAspect來動態的加到需要限流的介面上，個人認為是比較優雅的實現吧。
壓測結果：
可以看到，10個執行緒中無論壓測多少次，併發數總是限制在6，也就實現了限流，至於為什麼併發數是6而不是5，我也很納悶，這個問題在guava的github上提問了下，後面應該會有小夥伴解答的：https://github.com/google/guava/issues/3240