為什么需要限流

按照服務(wù)的調(diào)用方，可以分為以下幾種類型服務(wù)

?

1、與用戶打交道的服務(wù)

比如web服務(wù)、對外API，這種類型的服務(wù)有以下幾種可能導(dǎo)致機(jī)器被拖垮：

用戶增長過快（這是好事）

因為某個熱點事件（微博熱搜）

競爭對象爬蟲

惡意的刷單

這些情況都是無法預(yù)知的，不知道什么時候會有10倍甚至20倍的流量進(jìn)來，如果遇到此類情況，擴(kuò)容是根本來不及的，彈性擴(kuò)容也是來不及的；

?

2、對內(nèi)的RPC服務(wù)

一個服務(wù)A的接口可能被BCDE多個服務(wù)進(jìn)行調(diào)用，在B服務(wù)發(fā)生突發(fā)流量時，直接把A服務(wù)給調(diào)用掛了，導(dǎo)致A服務(wù)對CDE也無法提供服務(wù)。 這種情況時有發(fā)生，解決方案有兩種： 1、每個調(diào)用方采用線程池進(jìn)行資源隔離 2、使用限流手段對每個調(diào)用方進(jìn)行限流

?

限流算法實現(xiàn)

常見的限流算法有：計數(shù)器、令牌桶、漏桶。

?

1、計數(shù)器算法

采用計數(shù)器實現(xiàn)限流有點簡單粗暴，一般我們會限 制一秒鐘的能夠通過的請求數(shù)，比如限流qps為100，算法的實現(xiàn)思路就是從第一個請求進(jìn)來開始計時，在接下去的1s內(nèi)，每來一個請求，就把計數(shù)加1，如果累加的數(shù)字達(dá)到了100，那么后續(xù)的請求就會被全部拒絕。等到1s結(jié)束后，把計數(shù)恢復(fù)成0，重新開始計數(shù)。

?

具體的實現(xiàn)可以是這樣的：對于每次服務(wù)調(diào)用，可以通過 AtomicLong#incrementAndGet()方法來給計數(shù)器加1并返回最新值，通過這個最新值和閾值進(jìn)行比較。

?

這種實現(xiàn)方式，相信大家都知道有一個弊端：如果我在單位時間1s內(nèi)的前10ms，已經(jīng)通過了100個請求，那后面的990ms，只能眼巴巴的把請求拒絕，我們把這種現(xiàn)象稱為“突刺現(xiàn)象”

?

2、漏桶算法

為了消除"突刺現(xiàn)象"，可以采用漏桶算法實現(xiàn)限流，漏桶算法這個名字就很形象，算法內(nèi)部有一個容器，類似生活用到的漏斗，當(dāng)請求進(jìn)來時，相當(dāng)于水倒入漏斗，然后從下端小口慢慢勻速的流出。不管上面流量多大，下面流出的速度始終保持不變。

?

不管服務(wù)調(diào)用方多么不穩(wěn)定，通過漏桶算法進(jìn)行限流，每10毫秒處理一次請求。因為處理的速度是固定的，請求進(jìn)來的速度是未知的，可能突然進(jìn)來很多請求，沒來得及處理的請求就先放在桶里，既然是個桶，肯定是有容量上限，如果桶滿了，那么新進(jìn)來的請求就丟棄。

在算法實現(xiàn)方面，可以準(zhǔn)備一個隊列，用來保存請求，另外通過一個線程池定期從隊列中獲取請求并執(zhí)行，可以一次性獲取多個并發(fā)執(zhí)行。

這種算法，在使用過后也存在弊端：無法應(yīng)對短時間的突發(fā)流量。

?

3、令牌桶算法

從某種意義上講，令牌桶算法是對漏桶算法的一種改進(jìn)，桶算法能夠限 制請求調(diào)用的速率，而令牌桶算法能夠在限 制調(diào)用的平均速率的同時還允許一定程度的突發(fā)調(diào)用。

?

在令牌桶算法中，存在一個桶，用來存放固定數(shù)量的令牌。算法中存在一種機(jī)制，以一定的速率往桶中放令牌。每次請求調(diào)用需要先獲取令牌，只有拿到令牌，才有機(jī)會繼續(xù)執(zhí)行，否則選擇選擇等待可用的令牌、或者直接拒絕。

?

放令牌這個動作是持續(xù)不斷的進(jìn)行，如果桶中令牌數(shù)達(dá)到上限，就丟棄令牌，所以就存在這種情況，桶中一直有大量的可用令牌，這時進(jìn)來的請求就可以直接拿到令牌執(zhí)行，比如設(shè)置qps為100，那么限流器初始化完成一秒后，桶中就已經(jīng)有100個令牌了，這時服務(wù)還沒完全啟動好，等啟動完成對外提供服務(wù)時，該限流器可以抵擋瞬時的100個請求。所以，只有桶中沒有令牌時，請求才會進(jìn)行等待，最后相當(dāng)于以一定的速率執(zhí)行。

實現(xiàn)思路：可以準(zhǔn)備一個隊列，用來保存令牌，另外通過一個線程池定期生成令牌放到隊列中，每來一個請求，就從隊列中獲取一個令牌，并繼續(xù)執(zhí)行。

?

幸運(yùn)的是，通過Google開源的guava包，我們可以很輕松的創(chuàng)建一個令牌桶算法的限流器。

? com.google.guava ? ?

??guava ? ?

? 18.0

?

通過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("ok"); ? ? ? ? ? ? ??

????????????????????????} ? ? ? ? ?

?????????????????}).start();? ? ? ? ?

??????????????}?

? ?????}?

}

其實Guava提供了多種create方法，方便創(chuàng)建適合各種需求的限流器。在上述例子中，創(chuàng)建了一個每秒生成10個令牌的限流器，即100ms生成一個，并最多保存10個令牌，多余的會被丟棄。

?

rateLimiter提供了acquire()和tryAcquire()接口 1、使用acquire()方法，如果沒有可用令牌，會一直阻塞直到有足夠的令牌。 2、使用tryAcquire()方法，如果沒有可用令牌，就直接返回false。 3、使用tryAcquire()帶超時時間的方法，如果沒有可用令牌，就會判斷在超時時間內(nèi)是否可以等到令牌，如果不能，就返回false，如果可以，就阻塞等待。

?

集群限流

前面討論的幾種算法都屬于單機(jī)限流的范疇，但是業(yè)務(wù)需求五花八門，簡單的單機(jī)限流，根本無法滿足他們。

?

比如為了限 制某個資源被每個用戶或者商戶的訪問次數(shù)，5s只能訪問2次，或者一天只能調(diào)用1000次，這種需求，單機(jī)限流是無法實現(xiàn)的，這時就需要通過集群限流進(jìn)行實現(xiàn)。

?

如何實現(xiàn)？為了控制訪問次數(shù)，肯定需要一個計數(shù)器，而且這個計數(shù)器只能保存在第三方服務(wù)，比如redis。

?

大概思路：每次有相關(guān)操作的時候，就向redis服務(wù)器發(fā)送一個incr命令，比如需要限 制某個用戶訪問/index接口的次數(shù)，只需要拼接用戶id和接口名生成redis的key，每次該用戶訪問此接口時，只需要對這個key執(zhí)行incr命令，在這個key帶上過期時間，就可以實現(xiàn)指定時間的訪問頻率。