建站
咨詢
售后
建站咨詢
新聞中心
分布式服務(wù)限流實(shí)戰(zhàn)，已經(jīng)為你排好坑了
作者：段然 2019-08-08 09:57:53
開發(fā)
架構(gòu)
分布式 由于API接口無法控制調(diào)用方的行為，因此當(dāng)遇到瞬時(shí)請求量激增時(shí)，會導(dǎo)致接口占用過多服務(wù)器資源，使得其他請求響應(yīng)速度降低或是超時(shí)，更有甚者可能導(dǎo)致服務(wù)器宕機(jī)。
一、限流的作用
由于API接口無法控制調(diào)用方的行為，因此當(dāng)遇到瞬時(shí)請求量激增時(shí)，會導(dǎo)致接口占用過多服務(wù)器資源，使得其他請求響應(yīng)速度降低或是超時(shí)，更有甚者可能導(dǎo)致服務(wù)器宕機(jī)。
限流(Rate limiting)指對應(yīng)用服務(wù)的請求進(jìn)行限制，例如某一接口的請求限制為100個(gè)每秒,對超過限制的請求則進(jìn)行快速失敗或丟棄。
限流可以應(yīng)對：
- 熱點(diǎn)業(yè)務(wù)帶來的突發(fā)請求;
- 調(diào)用方bug導(dǎo)致的突發(fā)請求;
- 惡意攻擊請求。
因此，對于公開的接口應(yīng)該采取限流措施。
二、為什么要分布式限流
當(dāng)應(yīng)用為單點(diǎn)應(yīng)用時(shí)，只要應(yīng)用進(jìn)行了限流，那么應(yīng)用所依賴的各種服務(wù)也都得到了保護(hù)。
但線上業(yè)務(wù)出于各種原因考慮，多是分布式系統(tǒng)，單節(jié)點(diǎn)的限流僅能保護(hù)自身節(jié)點(diǎn)，但無法保護(hù)應(yīng)用依賴的各種服務(wù)，并且在進(jìn)行節(jié)點(diǎn)擴(kuò)容、縮容時(shí)也無法準(zhǔn)確控制整個(gè)服務(wù)的請求限制。
而如果實(shí)現(xiàn)了分布式限流，那么就可以方便地控制整個(gè)服務(wù)集群的請求限制，且由于整個(gè)集群的請求數(shù)量得到了限制，因此服務(wù)依賴的各種資源也得到了限流的保護(hù)。
三、限流的算法
實(shí)現(xiàn)限流有很多辦法，在程序中時(shí)通常是根據(jù)每秒處理的事務(wù)數(shù)(Transaction per second)來衡量接口的流量。
本文介紹幾種常用的限流算法：
- 固定窗口計(jì)數(shù)器;
- 滑動窗口計(jì)數(shù)器;
- 漏桶;
- 令牌桶。
1、固定窗口計(jì)數(shù)器算法
固定窗口計(jì)數(shù)器算法概念如下：
- 將時(shí)間劃分為多個(gè)窗口;
- 在每個(gè)窗口內(nèi)每有一次請求就將計(jì)數(shù)器加一;
- 如果計(jì)數(shù)器超過了限制數(shù)量，則本窗口內(nèi)所有的請求都被丟棄當(dāng)時(shí)間到達(dá)下一個(gè)窗口時(shí)，計(jì)數(shù)器重置。
固定窗口計(jì)數(shù)器是最為簡單的算法，但這個(gè)算法有時(shí)會讓通過請求量允許為限制的兩倍?？紤]如下情況：限制1秒內(nèi)最多通過5個(gè)請求，在第一個(gè)窗口的最后半秒內(nèi)通過了5個(gè)請求，第二個(gè)窗口的前半秒內(nèi)又通過了5個(gè)請求。這樣看來就是在1秒內(nèi)通過了10個(gè)請求。
2、滑動窗口計(jì)數(shù)器算法
滑動窗口計(jì)數(shù)器算法概念如下：
- 將時(shí)間劃分為多個(gè)區(qū)間;
- 在每個(gè)區(qū)間內(nèi)每有一次請求就將計(jì)數(shù)器加一維持一個(gè)時(shí)間窗口，占據(jù)多個(gè)區(qū)間;
- 每經(jīng)過一個(gè)區(qū)間的時(shí)間，則拋棄最老的一個(gè)區(qū)間，并納入最新的一個(gè)區(qū)間;
- 如果當(dāng)前窗口內(nèi)區(qū)間的請求計(jì)數(shù)總和超過了限制數(shù)量，則本窗口內(nèi)所有的請求都被丟棄。
滑動窗口計(jì)數(shù)器是通過將窗口再細(xì)分，并且按照時(shí)間"滑動"，這種算法避免了固定窗口計(jì)數(shù)器帶來的雙倍突發(fā)請求，但時(shí)間區(qū)間的精度越高，算法所需的空間容量就越大。
3、漏桶算法
漏桶算法概念如下：
將每個(gè)請求視作"水滴"放入"漏桶"進(jìn)行存儲;
"漏桶"以固定速率向外"漏"出請求來執(zhí)行如果"漏桶"空了則停止"漏水";
如果"漏桶"滿了則多余的"水滴"會被直接丟棄。
漏桶算法多使用隊(duì)列實(shí)現(xiàn)，服務(wù)的請求會存到隊(duì)列中，服務(wù)的提供方則按照固定的速率從隊(duì)列中取出請求并執(zhí)行，過多的請求則放在隊(duì)列中排隊(duì)或直接拒絕。
漏桶算法的缺陷也很明顯，當(dāng)短時(shí)間內(nèi)有大量的突發(fā)請求時(shí)，即便此時(shí)服務(wù)器沒有任何負(fù)載，每個(gè)請求也都得在隊(duì)列中等待一段時(shí)間才能被響應(yīng)。
4、令牌桶算法
令牌桶算法概念如下：
- 令牌以固定速率生成;
- 生成的令牌放入令牌桶中存放，如果令牌桶滿了則多余的令牌會直接丟棄，當(dāng)請求到達(dá)時(shí)，會嘗試從令牌桶中取令牌，取到了令牌的請求可以執(zhí)行;
- 如果桶空了，那么嘗試取令牌的請求會被直接丟棄。
令牌桶算法既能夠?qū)⑺械恼埱笃骄植嫉綍r(shí)間區(qū)間內(nèi)，又能接受服務(wù)器能夠承受范圍內(nèi)的突發(fā)請求，因此是目前使用較為廣泛的一種限流算法。
四、代碼實(shí)現(xiàn)
作為如此重要的功能，在Java中自然有很多實(shí)現(xiàn)限流的類庫，例如Google的開源項(xiàng)目guava提供了RateLimiter類，實(shí)現(xiàn)了單點(diǎn)的令牌桶限流。
而分布式限流常用的則有Hystrix、resilience4j、Sentinel等框架，但這些框架都需引入第三方的類庫，對于國企等一些保守的企業(yè)，引入外部類庫都需要經(jīng)過層層審批，較為麻煩。
分布式限流本質(zhì)上是一個(gè)集群并發(fā)問題，而Redis作為一個(gè)應(yīng)用廣泛的中間件，又擁有單進(jìn)程單線程的特性，天然可以解決分布式集群的并發(fā)問題。本文簡單介紹一個(gè)通過Redis實(shí)現(xiàn)單次請求判斷限流的功能。
1、腳本編寫
經(jīng)過上面的對比，最適合的限流算法就是令牌桶算法。而為實(shí)現(xiàn)限流算法，需要反復(fù)調(diào)用Redis查詢與計(jì)算，一次限流判斷需要多次請求較為耗時(shí)。因此我們采用編寫Lua腳本運(yùn)行的方式，將運(yùn)算過程放在Redis端，使得對Redis進(jìn)行一次請求就能完成限流的判斷。
令牌桶算法需要在Redis中存儲桶的大小、當(dāng)前令牌數(shù)量，并且實(shí)現(xiàn)每隔一段時(shí)間添加新的令牌。最簡單的辦法當(dāng)然是每隔一段時(shí)間請求一次Redis，將存儲的令牌數(shù)量遞增。
但實(shí)際上我們可以通過對限流兩次請求之間的時(shí)間和令牌添加速度來計(jì)算得出上次請求之后到本次請求時(shí)，令牌桶應(yīng)添加的令牌數(shù)量。因此我們在Redis中只需要存儲上次請求的時(shí)間和令牌桶中的令牌數(shù)量，而桶的大小和令牌的添加速度可以通過參數(shù)傳入實(shí)現(xiàn)動態(tài)修改。
由于第一次運(yùn)行腳本時(shí)默認(rèn)令牌桶是滿的，因此可以將數(shù)據(jù)的過期時(shí)間設(shè)置為令牌桶恢復(fù)到滿所需的時(shí)間，及時(shí)釋放資源。
編寫完成的Lua腳本如下：
- local ratelimit_info = redis.pcall('HMGET',KEYS[1],'last_time','current_token')
- local last_time = ratelimit_info[1]
- local current_token = tonumber(ratelimit_info[2])
- local max_token = tonumber(ARGV[1])
- local token_rate = tonumber(ARGV[2])
- local current_time = tonumber(ARGV[3])
- local reverse_time = 1000/token_rate
- if current_token == nil then
- current_token = max_token
- last_time = current_time
- else
- local past_time = current_time-last_time
- local reverse_token = math.floor(past_time/reverse_time)
- current_token = current_token+reverse_token
- last_time = reverse_time*reverse_token+last_time
- if current_token>max_token then
- current_token = max_token
- end
- end
- local result = 0
- if(current_token>0) then
- result = 1
- current_token = current_token-1
- end
- redis.call('HMSET',KEYS[1],'last_time',last_time,'current_token',current_token)
- redis.call('pexpire',KEYS[1],math.ceil(reverse_time*(max_token-current_token)+(current_time-last_time)))
- return result
2、執(zhí)行限流
這里使用Spring Data Redis來進(jìn)行Redis腳本的調(diào)用。
編寫Redis腳本類:
- public class RedisReteLimitScript implements RedisScript
{ - private static final String SCRIPT =
- "local ratelimit_info = redis.pcall('HMGET',KEYS[1],'last_time','current_token') local last_time = ratelimit_info[1] local current_token = tonumber(ratelimit_info[2]) local max_token = tonumber(ARGV[1]) local token_rate = tonumber(ARGV[2]) local current_time = tonumber(ARGV[3]) local reverse_time = 1000/token_rate if current_token == nil then current_token = max_token last_time = current_time else local past_time = current_time-last_time; local reverse_token = math.floor(past_time/reverse_time) current_token = current_token+reverse_token; last_time = reverse_time*reverse_token+last_time if current_token>max_token then current_token = max_token end end local result = '0' if(current_token>0) then result = '1' current_token = current_token-1 end redis.call('HMSET',KEYS[1],'last_time',last_time,'current_token',current_toke redis.call('pexpire',KEYS[1],math.ceil(reverse_time*(max_tokencurrent_token)+(current_time-last_time))) return result";
- @Override public String getSha1() {
- return DigestUtils.sha1Hex(SCRIPT);
- }
- @Override public Class
getResultType() { return String.class; - }
- @Override public String getScriptAsString() { return SCRIPT;
- }
- }
通過RedisTemplate對象執(zhí)行腳本：
- public boolean rateLimit(String key, int max, int rate) {
- List
keyList = new ArrayList<>(1); - keyList.add(key);
- return "1".equals(stringRedisTemplate
- .execute(new RedisReteLimitScript(), keyList, Integer.toString(max), Integer.toString(rate),
- Long.toString(System.currentTimeMillis())));
- }
rateLimit方法傳入的key為限流接口的ID，max為令牌桶的最大大小，rate為每秒鐘恢復(fù)的令牌數(shù)量，返回的boolean即為此次請求是否通過了限流。為了測試Redis腳本限流是否可以正常工作，我們編寫一個(gè)單元測試進(jìn)行測試看看。
- @Autowired
- private RedisManager redisManager;
- @Test
- public void rateLimitTest() throws InterruptedException {
- String key = "test_rateLimit_key";
- int max = 10; //令牌桶大小
- int rate = 10; //令牌每秒恢復(fù)速度
- AtomicInteger successCount = new AtomicInteger(0);
- Executor executor = Executors.newFixedThreadPool(10);
- CountDownLatch countDownLatch = new CountDownLatch(30);
- for (int i = 0; i < 30; i++) {
- executor.execute(() -> {
- boolean isAllow = redisManager.rateLimit(key, max, rate);
- if (isAllow) {
- successCount.addAndGet(1);
- }
- log.info(Boolean.toString(isAllow));
- countDownLatch.countDown();
- });
- }
- countDownLatch.await();
- log.info("請求成功{}次", successCount.get());
- }
設(shè)置令牌桶大小為10，令牌桶每秒恢復(fù)10個(gè)，啟動10個(gè)線程在短時(shí)間內(nèi)進(jìn)行30次請求，并輸出每次限流查詢的結(jié)果。日志輸出：
- [19:12:50,283]true
- [19:12:50,284]true
- [19:12:50,284]true
- [19:12:50,291]true
- [19:12:50,291]true
- [19:12:50,291]true
- [19:12:50,297]true
- [19:12:50,297]true
- [19:12:50,298]true
- [19:12:50,305]true
- [19:12:50,305]false
- [19:12:50,305]true
- [19:12:50,312]false
- [19:12:50,312]false
- [19:12:50,312]false
- [19:12:50,319]false
- [19:12:50,319]false
- [19:12:50,319]false
- [19:12:50,325]false
- [19:12:50,325]false
- [19:12:50,326]false
- [19:12:50,380]false
- [19:12:50,380]false
- [19:12:50,380]false
- [19:12:50,387]false
- [19:12:50,387]false
- [19:12:50,387]false
- [19:12:50,392]false
- [19:12:50,392]false
- [19:12:50,392]false
- [19:12:50,393]請求成功11次
可以看到，在0.1秒內(nèi)請求的30次請求中，除了初始的10個(gè)令牌以及隨時(shí)間恢復(fù)的1個(gè)令牌外，剩下19個(gè)沒有取得令牌的請求均返回了false，限流腳本正確的將超過限制的請求給判斷出來了，業(yè)務(wù)中此時(shí)就可以直接返回系統(tǒng)繁忙或接口請求太過頻繁等提示。
3、開發(fā)中遇到的問題
1)Lua變量格式
Lua中的String和Number需要通過tonumber()和tostring()進(jìn)行轉(zhuǎn)換。
2)Redis入?yún)?/strong>
Redis的pexpire等命令不支持小數(shù)，但Lua的Number類型可以存放小數(shù)，因此Number類型傳遞給 Redis時(shí)最好通過math.ceil()等方式轉(zhuǎn)換以避免存在小數(shù)導(dǎo)致命令失敗。
3)Time命令
由于Redis在集群下是通過復(fù)制腳本及參數(shù)到所有節(jié)點(diǎn)上，因此無法在具有不確定性的命令后面執(zhí)行寫入命令，因此只能請求時(shí)傳入時(shí)間而無法使用Redis的Time命令獲取時(shí)間。
3.2版本之后的Redis腳本支持redis.replicate_commands()，可以改為使用Time命令獲取當(dāng)前時(shí)間。
4)潛在的隱患
由于此Lua腳本是通過請求時(shí)傳入的時(shí)間做計(jì)算，因此務(wù)必保證分布式節(jié)點(diǎn)上獲取的時(shí)間同步，如果時(shí)間不同步會導(dǎo)致限流無法正常運(yùn)作。
作者介紹
段然，甜橙金融創(chuàng)新中心開發(fā)工程師，目前負(fù)責(zé)公司平臺化建設(shè)及媒介能力聚合。
分享題目：分布式服務(wù)限流實(shí)戰(zhàn)，已經(jīng)為你排好坑了
網(wǎng)站鏈接：http://www.5511xx.com/article/coehddp.html
