從SpringBoot構建十萬博文聊聊限流特技

時間 2019-11-13

原文原文鏈接

前言

在開發十萬博客系統的的過程當中，前面主要分享了爬蟲、緩存穿透以及文章閱讀量計數等等。爬蟲的目的就是解決十萬+問題；緩存穿透是爲了保護後端數據庫查詢服務；計數服務解決了接近真實閱讀數以及數據庫服務的壓力。html

架構圖

限流

就拿十萬博客來講，若是存在熱點文章，可能會有數十萬級別的併發用戶參與閱讀。若是想讓這些用戶正常訪問，無非就是加機器橫向擴展各類服務，但凡事都有一個利益平衡點，有時候只須要少許的機器保證大部分用戶在大部分時間能夠正常訪問便可。java

亦或是，若是存在大量爬蟲或者惡意攻擊，咱們必須採起必定的措施來保證服務的正常運行。這時候咱們就要考慮限流來保證服務的可用性，以防止非預期的請求對系統壓力過大而引發的系統癱瘓。一般的策略就是拒絕多餘的訪問，或者讓多餘的訪問排隊等待服務。nginx

限流算法

任何限流都不是漫無目的的，也不是一個開關就能夠解決的問題，經常使用的限流算法有：令牌桶，漏桶。git

令牌桶

令牌桶算法是網絡流量整形（Traffic Shaping）和速率限制（Rate Limiting）中最常使用的一種算法。典型狀況下，令牌桶算法用來控制發送到網絡上的數據的數目，並容許突發數據的發送(百科)。算法

用戶的請求速率是不固定的，這裏咱們假定爲10r/s，令牌按照5個每秒的速率放入令牌桶，桶中最多存放20個令牌。仔細想一想，是否是總有那麼一部分請求被丟棄。spring

漏桶

漏桶算法的主要目的是控制數據注入到網絡的速率，平滑網絡上的突發流量。漏桶算法提供了一種機制，經過它，突發流量能夠被整形以便爲網絡提供一個穩定的流量(百科)。數據庫

令牌桶是不管你流入速率多大，我都按照既定的速率去處理，若是桶滿則拒絕服務。後端

應用限流

Tomcat

在Tomcat容器中，咱們能夠經過自定義線程池，配置最大鏈接數，請求處理隊列等參數來達到限流的目的。api

Tomcat默認使用自帶的鏈接池，這裏咱們也能夠自定義實現，打開/conf/server.xml文件，在Connector以前配置一個線程池：緩存

<Executor name="tomcatThreadPool"
        namePrefix="tomcatThreadPool-"
        maxThreads="1000"
        maxIdleTime="300000"
        minSpareThreads="200"/>

name：共享線程池的名字。這是Connector爲了共享線程池要引用的名字，該名字必須惟一。默認值：None；
namePrefix:在JVM上，每一個運行線程均可以有一個name 字符串。這一屬性爲線程池中每一個線程的name字符串設置了一個前綴，Tomcat將把線程號追加到這一前綴的後面。默認值：tomcat-exec-；
maxThreads：該線程池能夠容納的最大線程數。默認值：200；
maxIdleTime：在Tomcat關閉一個空閒線程以前，容許空閒線程持續的時間(以毫秒爲單位)。只有當前活躍的線程數大於minSpareThread的值，纔會關閉空閒線程。默認值：60000(一分鐘)。
minSpareThreads：Tomcat應該始終打開的最小不活躍線程數。默認值：25。

配置Connector

<Connector executor="tomcatThreadPool"
           port="8080" protocol="HTTP/1.1"
           connectionTimeout="20000"
           redirectPort="8443"
           minProcessors="5"
           maxProcessors="75"
           acceptCount="1000"/>

executor：表示使用該參數值對應的線程池；
minProcessors：服務器啓動時建立的處理請求的線程數；
maxProcessors：最大能夠建立的處理請求的線程數；
acceptCount：指定當全部可使用的處理請求的線程數都被使用時，能夠放處處理隊列中的請求數，超過這個數的請求將不予處理。

API限流

這裏咱們採用開源工具包guava提供的限流工具類RateLimiter進行API限流，該類基於"令牌桶算法"，開箱即用。

自定義定義註解

/**
 * 自定義註解  限流
 * 建立者  爪窪筆記
 * 博客 https://blog.52itstyle.vip
 * 建立時間 2019年8月15日
 */
@Target({ElementType.PARAMETER, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public  @interface ServiceLimit {
    /**
     * 描述
     */
    String description()  default "";

    /**
     * key
     */
    String key() default "";

    /**
     * 類型
     */
    LimitType limitType() default LimitType.CUSTOMER;

    enum LimitType {
        /**
         * 自定義key
         */
        CUSTOMER,
        /**
         * 根據請求者IP
         */
        IP
    }
}

自定義切面

/**
 * 限流 AOP
 * 建立者  爪窪筆記
 * 博客 https://blog.52itstyle.vip
 * 建立時間 2019年8月15日
 */
@Aspect
@Configuration
@Order(1)
public class LimitAspect{

    //根據IP分不一樣的令牌桶, 天天自動清理緩存
    private static LoadingCache<String, RateLimiter> caches = CacheBuilder.newBuilder()
            .maximumSize(1000)
            .expireAfterWrite(1, TimeUnit.DAYS)
            .build(new CacheLoader<String, RateLimiter>() {
                @Override
                public RateLimiter load(String key){
                    // 新的IP初始化 每秒只發出5個令牌
                    return RateLimiter.create(5);
                }
            });

    //Service層切點  限流
    @Pointcut("@annotation(com.itstyle.blog.common.limit.ServiceLimit)")
    public void ServiceAspect() {

    }

    @Around("ServiceAspect()")
    public  Object around(ProceedingJoinPoint joinPoint) {
        MethodSignature signature = (MethodSignature) joinPoint.getSignature();
        Method method = signature.getMethod();
        ServiceLimit limitAnnotation = method.getAnnotation(ServiceLimit.class);
        ServiceLimit.LimitType limitType = limitAnnotation.limitType();
        String key = limitAnnotation.key();
        Object obj;
        try {
            if(limitType.equals(ServiceLimit.LimitType.IP)){
                key = IPUtils.getIpAddr();
            }
            RateLimiter rateLimiter = caches.get(key);
            Boolean flag = rateLimiter.tryAcquire();
            if(flag){
                obj = joinPoint.proceed();
            }else{
                throw new RrException("小同志，你訪問的太頻繁了");
            }
        } catch (Throwable e) {
            throw new RrException("小同志，你訪問的太頻繁了");
        }
        return obj;
    }
}

業務實現：

/**
     * 執行順序
     * 1）限流
     * 2）布隆
     * 3）計數
     * 4) 緩存
     * @param id
     * @return
     */
    @Override
    @ServiceLimit(limitType= ServiceLimit.LimitType.IP)
    @BloomLimit
    @HyperLogLimit
    @Cacheable(cacheNames ="blog")
    public Blog getById(Long id) {
        String nativeSql = "SELECT * FROM blog WHERE id=?";
        return dynamicQuery.nativeQuerySingleResult(Blog.class,nativeSql,new Object[]{id});
    }

分佈式限流

Nginx

如何使用Nginx實現基本的限流，好比單個IP限制每秒訪問50次。經過Nginx限流模塊，咱們能夠設置一旦併發鏈接數超過咱們的設置，將返回503錯誤給客戶端。

配置nginx.conf

#統一在http域中進行配置
#限制請求
limit_req_zone $binary_remote_addr $uri zone=api_read:20m rate=50r/s;
#按ip配置一個鏈接 zone
limit_conn_zone $binary_remote_addr zone=perip_conn:10m;
#按server配置一個鏈接 zone
limit_conn_zone $server_name zone=perserver_conn:100m;
server {
        listen       80;
        server_name  blog.52itstyle.top;
        index index.jsp;
        location / {
              #請求限流排隊經過 burst默認是0
              limit_req zone=api_read burst=5;
              #鏈接數限制,每一個IP併發請求爲2
              limit_conn perip_conn 2;
              #服務所限制的鏈接數(即限制了該server併發鏈接數量)
              limit_conn perserver_conn 1000;
              #鏈接限速
              limit_rate 100k;
              proxy_pass      http://seckill;
        }
}
upstream seckill {
        fair;
        server  172.16.1.120:8080 weight=1  max_fails=2 fail_timeout=30s;
        server  172.16.1.130:8080 weight=1  max_fails=2 fail_timeout=30s;
}

配置說明

imit_conn_zone

是針對每一個IP定義一個存儲session狀態的容器。這個示例中定義了一個100m的容器，按照32bytes/session，能夠處理3200000個session。

limit_rate 300k;

對每一個鏈接限速300k. 注意，這裏是對鏈接限速，而不是對IP限速。若是一個IP容許兩個併發鏈接，那麼這個IP就是限速limit_rate×2。

burst=5；

這至關於桶的大小，若是某個請求超過了系統處理速度，會被放入桶中，等待被處理。若是桶滿了，那麼抱歉，請求直接返回503，客戶端獲得一個服務器忙的響應。若是系統處理請求的速度比較慢，桶裏的請求也不能一直待在裏面，若是超過必定時間，也是會被直接退回，返回服務器忙的響應。

OpenResty

這裏咱們使用 OpenResty 開源的限流方案，測試案例使用OpenResty1.15.8.1最新版本，自帶lua-resty-limit-traffic模塊以及案例，實現起來更爲方便。

限制接口總併發數/請求數

熱點博文，因爲突發流量暴增，有可能會影響整個系統的穩定性從而形成崩潰，這時候咱們就要限制熱點博文的總併發數/請求數。

這裏咱們採用 lua-resty-limit-traffic中的resty.limit.count模塊實現：

-- 限制接口總併發數/請求數
local limit_count = require "resty.limit.count"

-- 這裏咱們使用AB測試,-n訪問10000次, -c併發1200個 
-- ab -n 10000 -c 1200 http://121.42.155.213/ ,第一次測試數據：1000個請求會有差很少8801請求失敗，符合如下配置說明
-- 限制 一分鐘內只能調用 1200 次 接口（容許在時間段開始的時候一次性放過1200個請求）
local lim, err = limit_count.new("my_limit_count_store", 1200, 60)
if not lim then
    ngx.log(ngx.ERR, "failed to instantiate a resty.limit.count object: ", err)
    return ngx.exit(500)
end

-- use the Authorization header as the limiting key
local key = ngx.req.get_headers()["Authorization"] or "public"
local delay, err = lim:incoming(key, true)

if not delay then
    if err == "rejected" then
        ngx.header["X-RateLimit-Limit"] = "5000"
        ngx.header["X-RateLimit-Remaining"] = 0
        return ngx.exit(503)
    end
    ngx.log(ngx.ERR, "failed to limit count: ", err)
    return ngx.exit(500)
end

-- the 2nd return value holds the current remaining number
-- of requests for the specified key.
local remaining = err

ngx.header["X-RateLimit-Limit"] = "5000"
ngx.header["X-RateLimit-Remaining"] = remaining

限制接口時間窗請求數

如今網絡爬蟲氾濫，有時候並非人爲的去點擊，亦或是存在惡意攻擊的狀況。此時咱們就要對客戶端單位時間內的請求數進行限制，以致於黑客不是那麼猖獗。固然了道高一尺魔高一丈，攻擊者老是會有辦法繞開你的防線，從另外一方面講也促進了技術的進步。

這裏咱們採用 lua-resty-limit-traffic中的resty.limit.conn模塊實現：

-- well, we could put the require() and new() calls in our own Lua
-- modules to save overhead. here we put them below just for
-- convenience.

local limit_conn = require "resty.limit.conn"
-- 這裏咱們使用AB測試,-n訪問1000次, -c併發100個 
-- ab -n 1000 -c 100 http://121.42.155.213/ ,這裏1000個請求將會有700個失敗
-- 相同IP段的人將不能被訪問，不影響其它IP 

-- 限制 IP 總請求數
-- 限制單個 ip 客戶端最大 200 req/sec 而且容許100 req/sec的突發請求
-- 就是說咱們會把200以上300一下的請求請求給延遲， 超過300的請求將會被拒絕
-- 最後一個參數實際上是你要預估這些併發（或者說單個請求）要處理多久,能夠經過的log_by_lua中的leaving（）調用進行動態調整
local lim, err = limit_conn.new("my_limit_conn_store", 200, 100, 0.5)
if not lim then
    ngx.log(ngx.ERR,
            "failed to instantiate a resty.limit.conn object: ", err)
    return ngx.exit(500)
end

-- the following call must be per-request.
-- here we use the remote (IP) address as the limiting key
-- commit 爲true 表明要更新shared dict中key的值，
-- false 表明只是查看當前請求要處理的延時狀況和前面還未被處理的請求數
local key = ngx.var.binary_remote_addr
local delay, err = lim:incoming(key, true)
if not delay then
    if err == "rejected" then
        return ngx.exit(503)
    end
    ngx.log(ngx.ERR, "failed to limit req: ", err)
    return ngx.exit(500)
end

if lim:is_committed() then
    local ctx = ngx.ctx
    ctx.limit_conn = lim
    ctx.limit_conn_key = key
    ctx.limit_conn_delay = delay
end

-- the 2nd return value holds the current concurrency level
-- for the specified key.
local conn = err

if delay >= 0.001 then
    -- 其實這裏的 delay 確定是上面說的併發處理時間的整數倍，
    -- 舉個例子，每秒處理100併發，桶容量200個，當時同時來500個併發，則200個拒掉
    -- 100個在被處理，而後200個進入桶中暫存，被暫存的這200個鏈接中，0-100個鏈接其實應該延後0.5秒處理，
    -- 101-200個則應該延後0.5*2=1秒處理（0.5是上面預估的併發處理時間）
    -- the request exceeding the 200 connections ratio but below
    -- 300 connections, so
    -- we intentionally delay it here a bit to conform to the
    -- 200 connection limit.
    -- ngx.log(ngx.WARN, "delaying")
    ngx.sleep(delay)
end

平滑限制接口請求數

以前的限流方式容許突發流量，也就是說瞬時流量都會被容許。忽然流量若是不加以限制會影響整個系統的穩定性，所以在秒殺場景中須要對請求整形爲平均速率處理，即20r/s。

這裏咱們採用 lua-resty-limit-traffic 中的resty.limit.req 模塊實現漏桶限流和令牌桶限流。

其實漏桶和令牌桶根本的區別就是，如何處理超過請求速率的請求。漏桶會把請求放入隊列中去等待均速處理，隊列滿則拒絕服務；令牌桶在桶容量容許的狀況下直接處理這些突發請求。

漏桶

桶容量大於零，而且是延遲模式。若是桶沒滿，則進入請求隊列以固定速率等待處理，不然請求被拒絕。

令牌桶

桶容量大於零，而且是非延遲模式。若是桶中存在令牌，則容許突發流量，不然請求被拒絕。

壓測

爲了測試以上配置效果，咱們採用AB壓測，Linux下執行如下命令便可：

# 安裝
yum -y install httpd-tools
# 查看ab版本
ab -v
# 查看幫助
ab --help

測試命令：

ab -n 1000 -c 100 http://127.0.0.1/

測試結果：

Server Software:        openresty/1.15.8.1  #服務器軟件
Server Hostname:        127.0.0.1     #IP
Server Port:            80            #請求端口號

Document Path:          /             #文件路徑
Document Length:        12 bytes      #頁面字節數

Concurrency Level:      100           #請求的併發數
Time taken for tests:   4.999 seconds #總訪問時間
Complete requests:      1000          #總請求樹
Failed requests:        0             #請求失敗數量
Write errors:           0
Total transferred:      140000 bytes  #請求總數據大小
HTML transferred:       12000 bytes   #html頁面實際總字節數
Requests per second:    200.06 [#/sec] (mean) #每秒多少請求，這個是很是重要的參數數值，服務器的吞吐量
Time per request:       499.857 [ms] (mean) #用戶平均請求等待時間 
Time per request:       4.999 [ms] (mean, across all concurrent requests)  # 服務器平均處理時間，也就是服務器吞吐量的倒數 
Transfer rate:          27.35 [Kbytes/sec] received #每秒獲取的數據長度

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.8      0       4
Processing:     5  474  89.1    500     501
Waiting:        2  474  89.2    500     501
Total:          9  475  88.4    500     501

Percentage of the requests served within a certain time (ms)
  50%    500
  66%    500
  75%    500
  80%    500
  90%    501
  95%    501
  98%    501
  99%    501
 100%    501 (longest request)