限流
當訪問頻率或者併發請求超過其承受範圍的時候,這時候我們就要考慮限流來保證接口的可用性,以防止非預期的請求對系統壓力過大而引起的系統癱瘓。通常的策略就是拒絕多餘的訪問,或者讓多餘的訪問排隊等待服務。
限流算法
任何限流都不是漫無目的的,也不是一個開關就可以解決的問題,常用的限流算法有:令牌桶,漏桶。
令牌桶
令牌桶算法是網絡流量整形(Traffic Shaping)和速率限制(Rate Limiting)中最常使用的一種算法。典型情況下,令牌桶算法用來控制發送到網絡上的數據的數目,並允許突發數據的發送(百科)。
在秒殺活動中,用戶的請求速率是不固定的,這裏我們假定爲10r/s,令牌按照5個每秒的速率放入令牌桶,桶中最多存放20個令牌。仔細想想,是不是總有那麼一部分請求被丟棄。
漏桶
漏桶算法的主要目的是控制數據注入到網絡的速率,平滑網絡上的突發流量。漏桶算法提供了一種機制,通過它,突發流量可以被整形以便爲網絡提供一個穩定的流量。
令牌桶是無論你流入速率多大,我都按照既定的速率去處理,如果桶滿則拒絕服務。
應用限流
Tomcat
在Tomcat容器中,我們可以通過自定義線程池,配置最大連接數,請求處理隊列等參數來達到限流的目的。
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限流,該類基於"令牌桶算法",開箱即用。
自定義定義註解
/**
* 自定義註解 限流
*/
@Target({ElementType.PARAMETER, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface ServiceLimit {
String description() default "";
}
自定義切面
/**
* 限流 AOP
*/
@Component
@Scope
@Aspect
public class LimitAspect {
//每秒只發出100個令牌,此處是單進程服務的限流,內部採用令牌捅算法實現
private static RateLimiter rateLimiter = RateLimiter.create(100.0);
//Service層切點 限流
@Pointcut("@annotation(com.itstyle.seckill.common.aop.ServiceLimit)")
public void ServiceAspect() {
}
@Around("ServiceAspect()")
public Object around(ProceedingJoinPoint joinPoint) {
Boolean flag = rateLimiter.tryAcquire();
Object obj = null;
try {
if(flag){
obj = joinPoint.proceed();
}
} catch (Throwable e) {
e.printStackTrace();
}
return obj;
}
}
業務實現:
@Override
@ServiceLimit
@Transactional
public Result startSeckil(long seckillId, long userId) {
//省略部分業務代碼,詳見秒殺源碼
}
分佈式限流
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 seckill.52itstyle.com;
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 xxx.xxx.xxx:8080 weight=1 max_fails=2 fail_timeout=30s;
server xxx.xxx.xxx: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.13.6.1最新版本,自帶lua-resty-limit-traffic模塊以及案例 ,實現起來更爲方便。
限制接口總併發數/請求數:秒殺活動中,由於突發流量暴增,有可能會影響整個系統的穩定性從而造成崩潰,這時候我們就要限制秒殺接口的總併發數/請求數。這裏我們採用 lua-resty-limit-traffic中的resty.limit.count模塊實現,具體代碼參見源碼openresty/lua/limit_count.lua。
限制接口時間窗請求數:秒殺場景下,有時候並都是人肉鼠標,比如12306的搶票軟件,軟件刷票可比人肉鼠標快多了。此時我們就要對客戶端單位時間內的請求數進行限制,以至於刷票不是那麼猖獗。當然了道高一尺魔高一丈,搶票軟件總是會有辦法繞開你的防線,從另一方面講也促進了技術的進步。這裏我們採用 lua-resty-limit-traffic中的resty.limit.conn模塊實現,具體代碼參見源碼openresty/lua/limit_conn.lua。
平滑限制接口請求數:之前的限流方式允許突發流量,也就是說瞬時流量都會被允許。突然流量如果不加以限制會影響整個系統的穩定性,因此在秒殺場景中需要對請求整形爲平均速率處理,即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.13.6.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)
總結
以上限流方案,只是針對此次秒殺案例做一個簡單的小結,大家也不要刻意區分那種方案的好壞,只要適合業務場景就是最好的。