保障服務穩定的三大利器：熔斷降級、服務限流和故障模擬。今天和大家談談限流演算法的幾種實現方式，本文所說的限流並非是Nginx層面的限流，而是業務程式碼中的邏輯限流。

為什麼需要限流

按照服務的呼叫方，可以分為以下幾種型別服務

1、與使用者打交道的服務

比如web服務、對外API，這種型別的服務有以下幾種可能導致機器被拖垮：

• 使用者增長過快（這是好事）

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

• 競爭物件爬蟲

• 惡意的刷單

這些情況都是無法預知的，不知道什麼時候會有10倍甚至20倍的流量打進來，如果真碰上這種情況，擴容是根本來不及的（彈性擴容都是虛談，一秒鐘你給我擴一下試試）

2、對內的RPC服務

一個服務A的介面可能被BCDE多個服務進行呼叫，在B服務發生突發流量時，直接把A服務給呼叫掛了，導致A服務對CDE也無法提供服務。 這種情況時有發生，解決方案有兩種： 1、每個呼叫方採用執行緒池進行資源隔離 2、使用限流手段對每個呼叫方進行限流

限流演算法實現

常見的限流演算法有：計數器、令牌桶、漏桶。

1、計數器演算法

採用計數器實現限流有點簡單粗暴，一般我們會限制一秒鐘的能夠通過的請求數，比如限流qps為100，演算法的實現思路就是從第一個請求進來開始計時，在接下去的1s內，每來一個請求，就把計數加1，如果累加的數字達到了100，那麼後續的請求就會被全部拒絕。等到1s結束後，把計數恢復成0，重新開始計數。

具體的實現可以是這樣的：對於每次服務呼叫，可以通過 AtomicLong#incrementAndGet()方法來給計數器加1並返回最新值，通過這個最新值和閾值進行比較。

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

2、漏桶演算法

為了消除"突刺現象"，可以採用漏桶演算法實現限流，漏桶演算法這個名字就很形象，演算法內部有一個容器，類似生活用到的漏斗，當請求進來時，相當於水倒入漏斗，然後從下端小口慢慢勻速的流出。不管上面流量多大，下面流出的速度始終保持不變。

不管服務呼叫方多麼不穩定，通過漏桶演算法進行限流，每10毫秒處理一次請求。因為處理的速度是固定的，請求進來的速度是未知的，可能突然進來很多請求，沒來得及處理的請求就先放在桶裡，既然是個桶，肯定是有容量上限，如果桶滿了，那麼新進來的請求就丟棄。

在演算法實現方面，可以準備一個佇列，用來儲存請求，另外通過一個執行緒池定期從佇列中獲取請求並執行，可以一次性獲取多個併發執行。

這種演算法，在使用過後也存在弊端：無法應對短時間的突發流量。

3、令牌桶演算法

從某種意義上講，令牌桶演算法是對漏桶演算法的一種改進，桶演算法能夠限制請求呼叫的速率，而令牌桶演算法能夠在限制呼叫的平均速率的同時還允許一定程度的突發呼叫。

在令牌桶演算法中，存在一個桶，用來存放固定數量的令牌。演算法中存在一種機制，以一定的速率往桶中放令牌。每次請求呼叫需要先獲取令牌，只有拿到令牌，才有機會繼續執行，否則選擇選擇等待可用的令牌、或者直接拒絕。

放令牌這個動作是持續不斷的進行，如果桶中令牌數達到上限，就丟棄令牌，所以就存在這種情況，桶中一直有大量的可用令牌，這時進來的請求就可以直接拿到令牌執行，比如設定qps為100，那麼限流器初始化完成一秒後，桶中就已經有100個令牌了，這時服務還沒完全啟動好，等啟動完成對外提供服務時，該限流器可以抵擋瞬時的100個請求。所以，只有桶中沒有令牌時，請求才會進行等待，最後相當於以一定的速率執行。

實現思路：可以準備一個佇列，用來儲存令牌，另外通過一個執行緒池定期生成令牌放到佇列中，每來一個請求，就從佇列中獲取一個令牌，並繼續執行。

幸運的是，通過Google開源的guava包，我們可以很輕鬆的建立一個令牌桶演算法的限流器。

<dependency>
   <groupId>com.google.guava</groupId>
   <artifactId>guava</artifactId>
   <version>18.0</version>
</dependency>

通過RateLimiter類的create方法，建立限流器。

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();
       }
   }
}

其實Guava提供了多種create方法，方便建立適合各種需求的限流器。在上述例子中，建立了一個每秒生成10個令牌的限流器，即100ms生成一個，並最多儲存10個令牌，多餘的會被丟棄。

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

叢集限流

前面討論的幾種演算法都屬於單機限流的範疇，但是業務需求五花八門，簡單的單機限流，根本無法滿足他們。

比如為了限制某個資源被每個使用者或者商戶的訪問次數，5s只能訪問2次，或者一天只能呼叫1000次，這種需求，單機限流是無法實現的，這時就需要通過叢集限流進行實現。

如何實現？為了控制訪問次數，肯定需要一個計數器，而且這個計數器只能儲存在第三方服務，比如redis。

大概思路：每次有相關操作的時候，就向redis伺服器傳送一個incr命令，比如需要限制某個使用者訪問/index介面的次數，只需要拼接使用者id和介面名生成redis的key，每次該使用者訪問此介面時，只需要對這個key執行incr命令，在這個key帶上過期時間，就可以實現指定時間的訪問頻率。