目前有幾種常見的限流方式：
1、通過限制單位時間段內呼叫量來限流
2、通過限制系統的併發呼叫程度來限流
3、使用漏桶（Leaky Bucket）演算法來進行限流
4、使用令牌桶（Token Bucket）演算法來進行限流

具體我們看下第三種和第四中演算法，也是我們目前看到的最常見的限流演算法
漏桶(Leaky Bucket)演算法思路很簡單,水(請求)先進入到漏桶裡,漏桶以一定的速度出水(介面有響應速率),當水流入速度過大會直接溢位(訪問頻率超過介面響應速率),然後就拒絕請求,可以看出漏桶演算法能強行限制資料的傳輸速率.示意圖如下:

可見這裡有兩個變數,一個是桶的大小,支援流量突發增多時可以存多少的水(burst),另一個是水桶漏洞的大小(rate)，虛擬碼如下：

double rate;               // leak rate in calls/s
double burst;              // bucket size in calls

long refreshTime;          // time for last water refresh
double water;              // water count at refreshTime

refreshWater() {
    long  now = getTimeOfDay();
    
    //水隨著時間流逝,不斷流走,最多就流乾到0.
    water = max(0
 
, water- (now - refreshTime)*rate); 
    refreshTime = now;
}

bool permissionGranted() {
    refreshWater();
    if (water < burst) { // 水桶還沒滿,繼續加1
        water ++;
        return true;
    } else {
        return false;
    }
}

漏桶演算法其實是悲觀的，因為它嚴格限制了系統的吞吐量，從某種角度上來說，它的效果和併發量限流很類似。漏桶演算法也可以用於大多數場景，但由於它對服務吞吐量有著嚴格固定的限制，如果在某個大的服務網路中只對某些服務進行漏桶演算法限流，這些服務可能會成為瓶頸。其實對於可擴充套件的大型服務網路，上游的服務壓力可以經過多重下游服務進行擴散，過多的漏桶限流似乎意義不大。

令牌桶演算法(Token Bucket)和 Leaky Bucket 效果一樣但方向相反的演算法,更加容易理解.隨著時間流逝,系統會按恆定1/QPS時間間隔(如果QPS=100,則間隔是10ms)往桶裡加入Token(想象和漏洞漏水相反,有個水龍頭在不斷的加水),如果桶已經滿了就不再加了.新請求來臨時,會各自拿走一個Token,如果沒有Token可拿了就阻塞或者拒絕服務.

令牌桶的另外一個好處是可以方便的改變速度. 一旦需要提高速率,則按需提高放入桶中的令牌的速率. 一般會定時(比如100毫秒)往桶中增加一定數量的令牌, 有些變種演算法則實時的計算應該增加的令牌的數量.

ratelimiter的簡介：Google開源工具包Guava提供了限流工具類RateLimiter,該類基於令牌桶演算法(Token Bucket)來完成限流,非常易於使用.RateLimiter經常用於限制對一些物理資源或者邏輯資源的訪問速率.它支援兩種獲取permits介面,一種是如果拿不到立刻返回false,一種會阻塞等待一段時間看能不能拿到.RateLimiter和Java中的訊號量(java.util.concurrent.Semaphore)類似,Semaphore通常用於限制併發量.

我們先看看如何建立一個RateLimiter例項：

RateLimiter create(double permitsPerSecond);  // 建立一個每秒包含permitsPerSecond個令牌的令牌桶，可以理解為QPS最多為permitsPerSecond

RateLimiter create(double permitsPerSecond, long warmupPeriod, TimeUnit unit)// 建立一個每秒包含permitsPerSecond個令牌的令牌桶，可以理解為QPS最多為permitsPerSecond，幷包含某個時間段的預熱期

我們再看看獲取令牌的相關方法：

double acquire(); // 阻塞直到獲取一個許可，返回被限制的睡眠等待時間，單位秒

double acquire(int permits); // 阻塞直到獲取permits個許可，返回被限制的睡眠等待時間，單位秒

boolean tryAcquire();// 嘗試獲取一個許可

boolean tryAcquire(int permits);// 嘗試獲取permits個許可

boolean tryAcquire(long timeout, TimeUnit unit);// 嘗試獲取一個許可，最多等待timeout時間

boolean tryAcquire(int permits, long timeout, TimeUnit unit);// 嘗試獲取permits個許可，最多等待timeout時間

我們來看個最簡單的例子：

SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyyMMdd HH:mm:ss.SSS");

RateLimiter rateLimiter = RateLimiter.create(2);

while(true) {

rateLimiter.acquire();

System.out.println(simpleDateFormat.format(new Date()));

}

執行該例子會得到類似如下結果：

20170323 17:04:03.352

20170323 17:04:03.851

20170323 17:04:04.350

20170323 17:04:04.849

20170323 17:04:05.350

20170323 17:04:05.850

20170323 17:04:06.350

20170323 17:04:06.850

我們從中看到，我們在開始設定的QPS是2，也就是說每秒2個請求，在我們列印的結果中每次結果相隔就是500毫秒。

在ratelimiter中，有兩種演算法：一種是平滑演算法（SmoothBursty）一種是預熱型演算法（SmoothWarmingUp），他們之間最顯著的區別就是ratelimiter的子方法：

// 重設流量相關引數，需要子類來實現，不同子類引數不盡相同，比如SmoothWarmingUp肯定有增長比率相關引數

void doSetRate(double permitsPerSecond, double stableIntervalMicros);

// 計算生成這些許可數需要等待的時間

long storedPermitsToWaitTime(double storedPermits, double permitsToTake);

// 返回許可冷卻（間隔）時間

double coolDownIntervalMicros();

其中，storedPermitsToWaitTime這個決定了兩種方法的等待時間計算方式的不一樣，首先smoothburst的該方法是返回0，也就是說對於smoothburst而言，他裡面的令牌會一次性全部給請求，所以他的等待時間=缺少的令牌數×stableIntervalMicros（固定的微妙數），而smoothwarmingup的時間計算方式不是這樣的，而是緩慢釋放令牌直到threshold,再進行QPS的速度，如下圖：

*          ^ throttling
 *          |
 * 3*stable +                  /
 * interval |                 /.
 *  (cold)  |                / .
 *          |               /  .   <-- "warmup period" is the area of the trapezoid between
 * 2*stable +              /   .       halfPermits and maxPermits
 * interval |             /    .
 *          |            /     .
 *          |           /      .
 *   stable +----------/  WARM . }
 * interval |          .   UP  . } <-- this rectangle (from 0 to maxPermits, and
 *          |          . PERIOD. }     height == stableInterval) defines the cooldown period,
 *          |          .       . }     and we want cooldownPeriod == warmupPeriod
 *          |---------------------------------> storedPermits
 *              (halfPermits) (maxPermits)
 *

具體的演算法，是按照從右到左計算每次獲取的permits×（interval1+interval2）/2,簡單來說就是計算從左到右覆蓋的面積（開始是梯形面積計算）

還有一個點需要重點說明下：我們可以看下我們獲取的每次等待時間

0.0

20170324 14:05:24.201

0.497167

20170324 14:05:24.700

0.499216

20170324 14:05:25.199

0.50035

20170324 14:05:25.699

void resync(long nowMicros) {
  // if nextFreeTicket is in the past, resync to now
if (nowMicros > nextFreeTicketMicros) {
    double newPermits = (nowMicros - nextFreeTicketMicros) / coolDownIntervalMicros();
storedPermits = min(maxPermits, storedPermits + newPermits);
nextFreeTicketMicros = nowMicros;
}
}

long waitMicros =
    storedPermitsToWaitTime(this.storedPermits, storedPermitsToSpend)
        + (long) (freshPermits * stableIntervalMicros);
this.nextFreeTicketMicros = LongMath.saturatedAdd(nextFreeTicketMicros, waitMicros);