占小狼，轉(zhuǎn)載請注明原創(chuàng)出處，謝謝！
保障服務(wù)穩(wěn)定的三大利器：熔斷降級、服務(wù)限流和故障模擬。今天和大家談?wù)勏蘖魉惴ǖ膸追N實(shí)現(xiàn)方式，本文所說的限流并非是Nginx層面的限流，而是業(yè)務(wù)代碼中的邏輯限流。
為什么需要限流
按照服務(wù)的調(diào)用方，可以分為以下幾種類型服務(wù)
1、與用戶打交道的服務(wù)
比如web服務(wù)、對外API，這種類型的服務(wù)有以下幾種可能導(dǎo)致機(jī)器被拖垮：
- 用戶增長過快（這是好事）
- 因?yàn)槟硞€熱點(diǎn)事件（微博熱搜）
- 競爭對象爬蟲
- 惡意的刷單
這些情況都是無法預(yù)知的，不知道什么時候會有10倍甚至20倍的流量打進(jìn)來，如果真碰上這種情況，擴(kuò)容是根本來不及的（彈性擴(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)行限流
限流算法實(shí)現(xiàn)
常見的限流算法有：計(jì)數(shù)器、令牌桶、漏桶。
1、計(jì)數(shù)器算法
采用計(jì)數(shù)器實(shí)現(xiàn)限流有點(diǎn)簡單粗暴，一般我們會限制一秒鐘的能夠通過的請求數(shù)，比如限流qps為100，算法的實(shí)現(xiàn)思路就是從第一個請求進(jìn)來開始計(jì)時，在接下去的1s內(nèi)，每來一個請求，就把計(jì)數(shù)加1，如果累加的數(shù)字達(dá)到了100，那么后續(xù)的請求就會被全部拒絕。等到1s結(jié)束后，把計(jì)數(shù)恢復(fù)成0，重新開始計(jì)數(shù)。
具體的實(shí)現(xiàn)可以是這樣的：對于每次服務(wù)調(diào)用，可以通過AtomicLong#incrementAndGet()方法來給計(jì)數(shù)器加1并返回最新值，通過這個最新值和閾值進(jìn)行比較。
這種實(shí)現(xiàn)方式，相信大家都知道有一個弊端：如果我在單位時間1s內(nèi)的前10ms，已經(jīng)通過了100個請求，那后面的990ms，只能眼巴巴的把請求拒絕，我們把這種現(xiàn)象稱為“突刺現(xiàn)象”
2、漏桶算法
為了消除"突刺現(xiàn)象"，可以采用漏桶算法實(shí)現(xiàn)限流，漏桶算法這個名字就很形象，算法內(nèi)部有一個容器，類似生活用到的漏斗，當(dāng)請求進(jìn)來時，相當(dāng)于水倒入漏斗，然后從下端小口慢慢勻速的流出。不管上面流量多大，下面流出的速度始終保持不變。
不管服務(wù)調(diào)用方多么不穩(wěn)定，通過漏桶算法進(jìn)行限流，每10毫秒處理一次請求。因?yàn)樘幚淼乃俣仁枪潭ǖ?，請求進(jìn)來的速度是未知的，可能突然進(jìn)來很多請求，沒來得及處理的請求就先放在桶里，既然是個桶，肯定是有容量上限，如果桶滿了，那么新進(jìn)來的請求就丟棄。
在算法實(shí)現(xiàn)方面，可以準(zhǔn)備一個隊(duì)列，用來保存請求，另外通過一個線程池（ScheduledExecutorService）來定期從隊(duì)列中獲取請求并執(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í)行。
實(shí)現(xiàn)思路：可以準(zhǔn)備一個隊(duì)列，用來保存令牌，另外通過一個線程池定期生成令牌放到隊(duì)列中，每來一個請求，就從隊(duì)列中獲取一個令牌，并繼續(xù)執(zhí)行。
通過Google開源的guava包，我們可以很輕松的創(chuàng)建一個令牌桶算法的限流器。
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>18.0</version>
</dependency>
通過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)建了一個每秒生成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ī)限流是無法實(shí)現(xiàn)的，這時就需要通過集群限流進(jìn)行實(shí)現(xiàn)。
如何實(shí)現(xiàn)？
為了控制訪問次數(shù)，肯定需要一個計(jì)數(shù)器，而且這個計(jì)數(shù)器只能保存在第三方服務(wù)，比如redis。
大概思路：每次有相關(guān)操作的時候，就向redis服務(wù)器發(fā)送一個incr命令，比如需要限制某個用戶訪問/index接口的次數(shù)，只需要拼接用戶id和接口名生成redis的key，每次該用戶訪問此接口時，只需要對這個key執(zhí)行incr命令，在這個key帶上過期時間，就可以實(shí)現(xiàn)指定時間的訪問頻率。
