占小狼，轉(zhuǎn)載請(qǐng)注明原創(chuàng)出處，謝謝！
保障服務(wù)穩(wěn)定的三大利器：熔斷降級(jí)、服務(wù)限流和故障模擬。今天和大家談?wù)勏蘖魉惴ǖ膸追N實(shí)現(xiàn)方式，本文所說(shuō)的限流并非是Nginx層面的限流，而是業(yè)務(wù)代碼中的邏輯限流。
為什么需要限流
按照服務(wù)的調(diào)用方，可以分為以下幾種類型服務(wù)
1、與用戶打交道的服務(wù)
比如web服務(wù)、對(duì)外API，這種類型的服務(wù)有以下幾種可能導(dǎo)致機(jī)器被拖垮：
- 用戶增長(zhǎng)過(guò)快（這是好事）
- 因?yàn)槟硞€(gè)熱點(diǎn)事件（微博熱搜）
- 競(jìng)爭(zhēng)對(duì)象爬蟲(chóng)
- 惡意的刷單
這些情況都是無(wú)法預(yù)知的，不知道什么時(shí)候會(huì)有10倍甚至20倍的流量打進(jìn)來(lái)，如果真碰上這種情況，擴(kuò)容是根本來(lái)不及的（彈性擴(kuò)容都是虛談，一秒鐘你給我擴(kuò)一下試試）
2、對(duì)內(nèi)的RPC服務(wù)
一個(gè)服務(wù)A的接口可能被BCDE多個(gè)服務(wù)進(jìn)行調(diào)用，在B服務(wù)發(fā)生突發(fā)流量時(shí)，直接把A服務(wù)給調(diào)用掛了，導(dǎo)致A服務(wù)對(duì)CDE也無(wú)法提供服務(wù)。
這種情況時(shí)有發(fā)生，解決方案有兩種：
1、每個(gè)調(diào)用方采用線程池進(jìn)行資源隔離
2、使用限流手段對(duì)每個(gè)調(diào)用方進(jìn)行限流
限流算法實(shí)現(xiàn)
常見(jiàn)的限流算法有：計(jì)數(shù)器、令牌桶、漏桶。
1、計(jì)數(shù)器算法
采用計(jì)數(shù)器實(shí)現(xiàn)限流有點(diǎn)簡(jiǎn)單粗暴，一般我們會(huì)限制一秒鐘的能夠通過(guò)的請(qǐng)求數(shù)，比如限流qps為100，算法的實(shí)現(xiàn)思路就是從第一個(gè)請(qǐng)求進(jìn)來(lái)開(kāi)始計(jì)時(shí)，在接下去的1s內(nèi)，每來(lái)一個(gè)請(qǐng)求，就把計(jì)數(shù)加1，如果累加的數(shù)字達(dá)到了100，那么后續(xù)的請(qǐng)求就會(huì)被全部拒絕。等到1s結(jié)束后，把計(jì)數(shù)恢復(fù)成0，重新開(kāi)始計(jì)數(shù)。
具體的實(shí)現(xiàn)可以是這樣的：對(duì)于每次服務(wù)調(diào)用，可以通過(guò)AtomicLong#incrementAndGet()方法來(lái)給計(jì)數(shù)器加1并返回最新值，通過(guò)這個(gè)最新值和閾值進(jìn)行比較。
這種實(shí)現(xiàn)方式，相信大家都知道有一個(gè)弊端：如果我在單位時(shí)間1s內(nèi)的前10ms，已經(jīng)通過(guò)了100個(gè)請(qǐng)求，那后面的990ms，只能眼巴巴的把請(qǐng)求拒絕，我們把這種現(xiàn)象稱為“突刺現(xiàn)象”
2、漏桶算法
為了消除"突刺現(xiàn)象"，可以采用漏桶算法實(shí)現(xiàn)限流，漏桶算法這個(gè)名字就很形象，算法內(nèi)部有一個(gè)容器，類似生活用到的漏斗，當(dāng)請(qǐng)求進(jìn)來(lái)時(shí)，相當(dāng)于水倒入漏斗，然后從下端小口慢慢勻速的流出。不管上面流量多大，下面流出的速度始終保持不變。
不管服務(wù)調(diào)用方多么不穩(wěn)定，通過(guò)漏桶算法進(jìn)行限流，每10毫秒處理一次請(qǐng)求。因?yàn)樘幚淼乃俣仁枪潭ǖ?，?qǐng)求進(jìn)來(lái)的速度是未知的，可能突然進(jìn)來(lái)很多請(qǐng)求，沒(méi)來(lái)得及處理的請(qǐng)求就先放在桶里，既然是個(gè)桶，肯定是有容量上限，如果桶滿了，那么新進(jìn)來(lái)的請(qǐng)求就丟棄。
在算法實(shí)現(xiàn)方面，可以準(zhǔn)備一個(gè)隊(duì)列，用來(lái)保存請(qǐng)求，另外通過(guò)一個(gè)線程池（ScheduledExecutorService）來(lái)定期從隊(duì)列中獲取請(qǐng)求并執(zhí)行，可以一次性獲取多個(gè)并發(fā)執(zhí)行。
這種算法，在使用過(guò)后也存在弊端：無(wú)法應(yīng)對(duì)短時(shí)間的突發(fā)流量。
3、令牌桶算法
從某種意義上講，令牌桶算法是對(duì)漏桶算法的一種改進(jìn)，桶算法能夠限制請(qǐng)求調(diào)用的速率，而令牌桶算法能夠在限制調(diào)用的平均速率的同時(shí)還允許一定程度的突發(fā)調(diào)用。
在令牌桶算法中，存在一個(gè)桶，用來(lái)存放固定數(shù)量的令牌。算法中存在一種機(jī)制，以一定的速率往桶中放令牌。每次請(qǐng)求調(diào)用需要先獲取令牌，只有拿到令牌，才有機(jī)會(huì)繼續(xù)執(zhí)行，否則選擇選擇等待可用的令牌、或者直接拒絕。
放令牌這個(gè)動(dòng)作是持續(xù)不斷的進(jìn)行，如果桶中令牌數(shù)達(dá)到上限，就丟棄令牌，所以就存在這種情況，桶中一直有大量的可用令牌，這時(shí)進(jìn)來(lái)的請(qǐng)求就可以直接拿到令牌執(zhí)行，比如設(shè)置qps為100，那么限流器初始化完成一秒后，桶中就已經(jīng)有100個(gè)令牌了，這時(shí)服務(wù)還沒(méi)完全啟動(dòng)好，等啟動(dòng)完成對(duì)外提供服務(wù)時(shí)，該限流器可以抵擋瞬時(shí)的100個(gè)請(qǐng)求。所以，只有桶中沒(méi)有令牌時(shí)，請(qǐng)求才會(huì)進(jìn)行等待，最后相當(dāng)于以一定的速率執(zhí)行。
實(shí)現(xiàn)思路：可以準(zhǔn)備一個(gè)隊(duì)列，用來(lái)保存令牌，另外通過(guò)一個(gè)線程池定期生成令牌放到隊(duì)列中，每來(lái)一個(gè)請(qǐng)求，就從隊(duì)列中獲取一個(gè)令牌，并繼續(xù)執(zhí)行。
通過(guò)Google開(kāi)源的guava包，我們可以很輕松的創(chuàng)建一個(gè)令牌桶算法的限流器。
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>18.0</version>
</dependency>
通過(guò)RateLimiter類的create方法，創(chuàng)建限流器。
public class RateLimiterMain {
public static void main(String[] args) {
RateLimiter rateLimiter = RateLimiter.create(10);
for (int i = 0; i < 10; i++) {
new Thread(new Runnable() {
@Override
public void run() {
rateLimiter.acquire()
System.out.println("pass");
}
}).start();
}
}
}
其實(shí)Guava提供了多種create方法，方便創(chuàng)建適合各種需求的限流器。在上述例子中，創(chuàng)建了一個(gè)每秒生成10個(gè)令牌的限流器，即100ms生成一個(gè)，并最多保存10個(gè)令牌，多余的會(huì)被丟棄。
rateLimiter提供了acquire()和tryAcquire()接口
1、使用acquire()方法，如果沒(méi)有可用令牌，會(huì)一直阻塞直到有足夠的令牌。
2、使用tryAcquire()方法，如果沒(méi)有可用令牌，就直接返回false。
3、使用tryAcquire()帶超時(shí)時(shí)間的方法，如果沒(méi)有可用令牌，就會(huì)判斷在超時(shí)時(shí)間內(nèi)是否可以等到令牌，如果不能，就返回false，如果可以，就阻塞等待。
集群限流
前面討論的幾種算法都屬于單機(jī)限流的范疇，但是業(yè)務(wù)需求五花八門，簡(jiǎn)單的單機(jī)限流，根本無(wú)法滿足他們。
比如為了限制某個(gè)資源被每個(gè)用戶或者商戶的訪問(wèn)次數(shù)，5s只能訪問(wèn)2次，或者一天只能調(diào)用1000次，這種需求，單機(jī)限流是無(wú)法實(shí)現(xiàn)的，這時(shí)就需要通過(guò)集群限流進(jìn)行實(shí)現(xiàn)。
如何實(shí)現(xiàn)？
為了控制訪問(wèn)次數(shù)，肯定需要一個(gè)計(jì)數(shù)器，而且這個(gè)計(jì)數(shù)器只能保存在第三方服務(wù)，比如redis。
大概思路：每次有相關(guān)操作的時(shí)候，就向redis服務(wù)器發(fā)送一個(gè)incr命令，比如需要限制某個(gè)用戶訪問(wèn)/index接口的次數(shù)，只需要拼接用戶id和接口名生成redis的key，每次該用戶訪問(wèn)此接口時(shí)，只需要對(duì)這個(gè)key執(zhí)行incr命令，在這個(gè)key帶上過(guò)期時(shí)間，就可以實(shí)現(xiàn)指定時(shí)間的訪問(wèn)頻率。
