流量控制与RateLimiter

àì夳堔傛蜴生んèń 2022-05-28 07:30 222阅读 0赞

# 一背景 #

如何提高系统的稳定性，简单来说除了加机器外就是服务降级、限流。加机器就是常说的分布式，从整个架构的稳定性角度看，一般SOA每个接口的所能提供的单位时间服务能力是有上限。假如超过服务能力，一般会造成整个接口服务停顿，或者应用挂了，将延迟传递给服务调用方造成整个系统的服务能力丧失。要是对外的公开 API 接口服务，Rate limiting 应该是一个必备的功能，否极有可能被恶意调用导致服务宕掉，所以限流是必要的。这里本文就整理下常见的限流原理及方案。

流量控制更专业的叫法是：流量整形(traffic shaping)，典型作用是限制流出某一网络的某一连接的流量与突发，使这类报文以比较均匀的速度向外发送。

# 二 常用方法 #

令牌桶([Token Bucket][])和漏桶([leaky bucket][])是 最常用的两种限流的算法。

## 2.1 漏桶算法 ##

漏桶(Leaky Bucket)算法思路很简单,水(请求)先进入到漏桶里,漏桶以一定的速度出水(接口有响应速率),当水流入速度过大会直接溢出(访问频率超过接口响应速率),然后就拒绝请求,可以看出漏桶算法能强行限制数据的传输速率.示意图如下:

![Center][]

可见这里有两个变量,一个是桶的大小,支持流量突发增多时可以存多少的水(burst),另一个是水桶漏洞的大小(rate)，在某些情况下，漏桶算法不能够有效地使用网络资源。因为漏桶的漏出速率是固定的参数，所以，即使网络中不存在资源冲突（没有发生拥塞），漏桶算法也不能使某一个单独的流突发到端口速率。因此，漏桶算法对于存在突发特性的流量来说缺乏效率。而令牌桶算法则能够满足这些具有突发特性的流量。通常，漏桶算法与令牌桶算法可以结合起来为网络流量提供更大的控制。

## 2.2令牌桶算法 ##

# ![Center 1][]    #

令牌桶算法(Token Bucket)和 Leaky Bucket 效果一样但方向相反的算法,更加容易理解.随着时间流逝,系统会按恒定1/QPS时间间隔(如果QPS=100,则间隔是10ms)往桶里加入Token(想象和漏洞漏水相反,有个水龙头在不断的加水),如果桶已经满了就不再加了.新请求来临时,会各自拿走一个Token,如果没有Token可拿了就阻塞或者拒绝服务.

令牌桶的另外一个好处是可以方便的改变速度. 一旦需要提高速率,则按需提高放入桶中的令牌的速率. 一般会定时(比如100毫秒)往桶中增加一定数量的令牌, 有些变种算法则实时的计算应该增加的令牌的数量.

# 三 guava RateLimiter #

## 3.1RateLimiter 简介 ##

Google开源工具包Guava提供了限流工具类RateLimiter,该类基于令牌桶算法(Token Bucket)来完成限流,非常易于使用.RateLimiter经常用于限制对一些物理资源或者逻辑资源的访问速率.它支持两种获取permits接口,一种是如果拿不到立刻返回false,一种会阻塞等待一段时间看能不能拿到.

RateLimiter经常用于限制对一些物理资源或者逻辑资源的访问速率。与Semaphore 相比，Semaphore 限制了并发访问的数量而不是使用速率。（注意尽管并发性和速率是紧密相关的，比如参考[Little定律][Little]）

通过设置许可证的速率来定义RateLimiter。在默认配置下，许可证会在固定的速率下被分配，速率单位是每秒多少个许可证。为了确保维护配置的速率，许可会被平稳地分配，许可之间的延迟会做调整。  
可能存在配置一个拥有预热期的RateLimiter 的情况，在这段时间内，每秒分配的许可数会稳定地增长直到达到稳定的速率。

有一点很重要，那就是请求的许可数从来不会影响到请求本身的限制（调用acquire(1) 和调用acquire(1000) 将得到相同的限制效果，如果存在这样的调用的话），但会影响下一次请求的限制，也就是说，如果一个高开销的任务抵达一个空闲的RateLimiter，它会被马上许可，但是下一个请求会经历额外的限制，从而来偿付高开销任务。注意：RateLimiter 并不提供公平性的保证。

## 3.2 code ##

我们要实现一个基于速率的单机流控框架的时候，RateLimiter 是一个完善的核心组件，下面是demo

**\[java\]**  [view plain][]   [copy][view plain]

1. import java.util.concurrent.ConcurrentMap;  
2.   
3. import com.google.common.collect.Maps;  
4. import com.google.common.util.concurrent.RateLimiter;  
5.   
6. public class TrafficShaper \{  
7.   
8.     //key-value(serverice,qps)  
9.     private static final ConcurrentMap<String, Double> resourceMap = Maps.newConcurrentMap();  
10.     //userkey-service limiter  
11.     private static final ConcurrentMap<String, RateLimiter> userresourceLimiterMap = Maps.newConcurrentMap();  
12.     static \{  
13.         //init  
14.         resourceMap.put("aaa", 50.0);  
15.     \}  
16.     public static void updateResourceQps(String resource, double qps) \{  
17.         resourceMap.put(resource, qps);  
18.     \}  
19.   
20.     public static void removeResource(String resource) \{  
21.         resourceMap.remove(resource);  
22.     \}  
23.   
24.     public static int enter(String resource,String userkey)  \{  
25.         long t1 = System.currentTimeMillis();  
26.         double qps = resourceMap.get(resource);  
27.         //服务不限流  
28.         if (qps == 0.0) \{  
29.             return 0;  
30.         \}  
31.         String keyser = resource+userkey;  
32.         RateLimiter keyserlimiter = userresourceLimiterMap.get(keyser);  
33.         //if null,new limiter   
34.         if(keyserlimiter == null)  
35.         \{  
36.             keyserlimiter =RateLimiter.create(qps);  
37.             RateLimiter putByOtherThread = userresourceLimiterMap.putIfAbsent(keyser, keyserlimiter);  
38.             if (putByOtherThread != null) \{  
39.                 keyserlimiter = putByOtherThread;  
40.             \}  
41.             keyserlimiter.setRate(qps);  
42.         \}  
43.          
44.         //tryacquire  
45.         if (!keyserlimiter.tryAcquire()) \{            
46.             System.out.println("use:"\+(System.currentTimeMillis()-t1)+"ms;"\+resource+"  visited  too frequently  by key:"\+userkey);  
47.               
48.             return 99;  
49.         \}else\{  
50.             System.out.println("use:"\+(System.currentTimeMillis()-t1)+"ms;");  
51.             return 0;  
52.         \}  
53.           
54.     \}  
55.       
56.     public static void main(String\[\] args) throws InterruptedException \{  
57.         // TODO Auto-generated method stub  
58.         int i=0;  
59.           
60.         while(true)\{  
61.             i++;  
62.             long t2 = System.currentTimeMillis();  
63.             System.out.println(t2+":qq:"\+i);      
64.               
65.             int res =   TrafficShaper.enter("aaa", "qq");  
66.             System.out.println((System.currentTimeMillis()-t2)+":qq:"\+i);         
67.             if(res ==99)  
68.             \{                     
69.                 i=0;  
70.                 Thread.sleep(1000);  
71.             \}  
72.               
73.         \}         
74.     \}  
75. \}

简单说明下，这里核心方法是enter，入参是两个，分别是服务名称跟用户key.预期效果就是开放API对于用户来说某个服务只允许调用最大次数。

运行结果：

## ![Center 2][]    ##

## 3.3 API接口 ##

<table style="width:798px;margin:0px 0px 1em;padding:0px;border:0px;color:rgb(102,102,102);font-size:14px;"> 
 <tbody> 
 <tr> 
 <th style="border-color:rgb(204,204,204);padding:15px;font-weight:normal;background:rgb(238,238,238);">修饰符和类型</th> 
 <th style="border-color:rgb(204,204,204);padding:15px;font-weight:normal;background:rgb(238,238,238);">方法和描述</th> 
 </tr> 
 <tr> 
 <td style="border-color:rgb(204,204,204);padding:15px;">double</td> 
 <td style="border-color:rgb(204,204,204);padding:15px;">acquire() 从RateLimiter获取一个许可，该方法会被阻塞直到获取到请求</td> 
 </tr> 
 <tr> 
 <td style="border-color:rgb(204,204,204);padding:15px;">double</td> 
 <td style="border-color:rgb(204,204,204);padding:15px;">acquire(int&nbsp;permits) 从RateLimiter获取指定许可数，该方法会被阻塞直到获取到请求</td> 
 </tr> 
 <tr> 
 <td style="border-color:rgb(204,204,204);padding:15px;">static&nbsp;RateLimiter</td> 
 <td style="border-color:rgb(204,204,204);padding:15px;">create(double&nbsp;permitsPerSecond) 根据指定的稳定吞吐率创建RateLimiter，这里的吞吐率是指每秒多少许可数（通常是指QPS，每秒多少查询）</td> 
 </tr> 
 <tr> 
 <td style="border-color:rgb(204,204,204);padding:15px;">static&nbsp;RateLimiter</td> 
 <td style="border-color:rgb(204,204,204);padding:15px;">create(double&nbsp;permitsPerSecond, long&nbsp;warmupPeriod,&nbsp;TimeUnit&nbsp;unit) 根据指定的稳定吞吐率和预热期来创建RateLimiter，这里的吞吐率是指每秒多少许可数（通常是指QPS，每秒多少个请求量），在这段预热时间内，RateLimiter每秒分配的许可数会平稳地增长直到预热期结束时达到其最大速率。（只要存在足够请求数来使其饱和）</td> 
 </tr> 
 <tr> 
 <td style="border-color:rgb(204,204,204);padding:15px;">double</td> 
 <td style="border-color:rgb(204,204,204);padding:15px;">getRate() 返回RateLimiter&nbsp;配置中的稳定速率，该速率单位是每秒多少许可数</td> 
 </tr> 
 <tr> 
 <td style="border-color:rgb(204,204,204);padding:15px;">void</td> 
 <td style="border-color:rgb(204,204,204);padding:15px;">setRate(double&nbsp;permitsPerSecond) 更新RateLimite的稳定速率，参数permitsPerSecond&nbsp;由构造RateLimiter的工厂方法提供。</td> 
 </tr> 
 <tr> 
 <td style="border-color:rgb(204,204,204);padding:15px;">String</td> 
 <td style="border-color:rgb(204,204,204);padding:15px;">toString() 返回对象的字符表现形式</td> 
 </tr> 
 <tr> 
 <td style="border-color:rgb(204,204,204);padding:15px;">boolean</td> 
 <td style="border-color:rgb(204,204,204);padding:15px;">tryAcquire() 从RateLimiter&nbsp;获取许可，如果该许可可以在无延迟下的情况下立即获取得到的话</td> 
 </tr> 
 <tr> 
 <td style="border-color:rgb(204,204,204);padding:15px;">boolean</td> 
 <td style="border-color:rgb(204,204,204);padding:15px;">tryAcquire(int&nbsp;permits) 从RateLimiter&nbsp;获取许可数，如果该许可数可以在无延迟下的情况下立即获取得到的话</td> 
 </tr> 
 <tr> 
 <td style="border-color:rgb(204,204,204);padding:15px;">boolean</td> 
 <td style="border-color:rgb(204,204,204);padding:15px;">tryAcquire(int&nbsp;permits, long&nbsp;timeout,&nbsp;TimeUnit&nbsp;unit) 从RateLimiter&nbsp;获取指定许可数如果该许可数可以在不超过timeout的时间内获取得到的话，或者如果无法在timeout 过期之前获取得到许可数的话，那么立即返回false&nbsp;（无需等待）</td> 
 </tr> 
 <tr> 
 <td style="border-color:rgb(204,204,204);padding:15px;">boolean</td> 
 <td style="border-color:rgb(204,204,204);padding:15px;">tryAcquire(long&nbsp;timeout,&nbsp;TimeUnit&nbsp;unit) 从RateLimiter&nbsp;获取许可如果该许可可以在不超过timeout的时间内获取得到的话，或者如果无法在timeout 过期之前获取得到许可的话，那么立即返回false（无需等待）</td> 
 </tr> 
 </tbody> 
</table>

## 3.4 源码分析 ##

RateLimiter主要源码分析

两个create函数用于构建不同形式的RateLimiter

**\[java\]**  [view plain][]   [copy][view plain]

1.  public static RateLimiter create(double permitsPerSecond)  
2.  用于创建SmoothBursty类型的RateLimiter  
3.  public static RateLimiter create(double permitsPerSecond,long warmupPeriod,TimeUnit unit)  
4.  用于创建SmoothWarmingUp类型的RateLimiter.API注释上比较长，如下：

**\[java\]**  [view plain][]   [copy][view plain]

1.  根据指定的稳定吞吐率和预热期来创建RateLimiter，这里的吞吐率是指每秒多少许可数（通常是指QPS，每秒多少查询），在这段预热时间内，RateLimiter每秒分配的许可数会平稳地增长直到预热期结束时达到其最大速率（只要存在足够请求数来使其饱和）。同样地，如果RateLimiter 在warmupPeriod时间内闲置不用，它将会逐步地返回冷却状态。也就是说，它会像它第一次被创建般经历同样的预热期。返回的RateLimiter 主要用于那些需要预热期的资源，这些资源实际上满足了请求（比如一个远程服务），而不是在稳定（最大）的速率下可以立即被访问的资源。返回的RateLimiter 在冷却状态下启动（即预热期将会紧跟着发生），并且如果被长期闲置不用，它将回到冷却状态。

下面以acquire为例子，看下源码的实现

**\[java\]**  [view plain][]   [copy][view plain]

1. public double acquire() \{  
2.    return acquire(1);  
3.  \}  
4.  public double acquire(int permits) \{  
5.    long microsToWait = reserve(permits);  
6.    stopwatch.sleepMicrosUninterruptibly(microsToWait);//<span style="color: rgb(0, 128, 0); font-family: Menlo, Monaco, Consolas, 'Courier New', monospace; line-height: 1.42857143; background-color: rgb(245, 245, 245);"><span style="font-size:10px;">等待，当未达到限制时，microsToWait为0  
7.   
8.    return 1.0 \* microsToWait / SECONDS.toMicros(1L);  
9.  \}  
10.  final long reserve(int permits) \{  
11.    checkPermits(permits);//<span style="color:\#006600;">参数校验>0  
12.    synchronized (mutex()) \{ //<span style="color:\#006600;">并发的情况下同步  
13.      return reserveAndGetWaitLength(permits, stopwatch.readMicros());//<span style="color:\#006600;">获取需要等待的时间  
14.    \}  
15.  \}

**\[java\]**  [view plain][]   [copy][view plain]

1.  final long reserveAndGetWaitLength(int permits, long nowMicros) \{  
2.    long momentAvailable = reserveEarliestAvailable(permits, nowMicros);  
3.    return max(momentAvailable - nowMicros, 0);  
4.  \}

**\[java\]**  [view plain][]   [copy][view plain]

1.   abstract long reserveEarliestAvailable(int permits, long nowMicros);

这是个抽象接口，我们看下具体实现类SmoothRateLimiter:

**\[java\]**  [view plain][]   [copy][view plain]

1. @Override  
2. final long reserveEarliestAvailable(int requiredPermits, long nowMicros) \{  
3.   resync(nowMicros);//<span style="color:\#006600;">补充令牌  
4.   long returnValue = nextFreeTicketMicros;  
5.   double storedPermitsToSpend = min(requiredPermits, this.storedPermits);//<span style="color:\#006600;">本次请求消耗的令牌数  
6.   double freshPermits = requiredPermits - storedPermitsToSpend;  
7.   
8.   long waitMicros = storedPermitsToWaitTime(this.storedPermits, storedPermitsToSpend)  
9.       + (long) (freshPermits \* stableIntervalMicros);  
10.   
11.   this.nextFreeTicketMicros = nextFreeTicketMicros + waitMicros;//<span style="color:\#006600;">计算下次可用时间  
12.   this.storedPermits -= storedPermitsToSpend;//<span style="color:\#006600;">消耗令牌  
13.   return returnValue;  
14. \}

**\[java\]**  [view plain][]   [copy][view plain]

1.  private void resync(long nowMicros) \{ //<span style="color:\#006600;">补充令牌数，及更新下次可用令牌毫秒数  
2.     // if nextFreeTicket is in the past, resync to now  
3.     if (nowMicros > nextFreeTicketMicros) \{  
4.       storedPermits = min(maxPermits,  
5.           storedPermits + (nowMicros - nextFreeTicketMicros) / stableIntervalMicros);  
6.       nextFreeTicketMicros = nowMicros;  
7.     \}  
8.   \}

对于 storedPermitsToWaitTime，这是一个抽象接口，

**\[java\]**  [view plain][]   [copy][view plain]

1. /\*\* 
2.  \* Translates a specified portion of our currently stored permits which we want to 
3.  \* spend/acquire, into a throttling time. Conceptually, this evaluates the integral 
4.  \* of the underlying function we use, for the range of 
5.  \* \[(storedPermits - permitsToTake), storedPermits\]. 
6.  \* 
7.  \* This always holds: \{@code 0 <= permitsToTake <= storedPermits\} 
8.  \*/  
9. abstract long storedPermitsToWaitTime(double storedPermits, double permitsToTake);

RateLimiter实际上由两种实现策略，其实现分别见SmoothBursty和SmoothWarmingUp。

### 3.4.1SmoothBursty ###

SmoothBursty使用storedPermits不需要额外等待时间。并且默认maxBurstSeconds为1，因此maxPermits为permitsPerSecond，即最多可以存储1秒的剩余令牌，比如QPS=4，则maxPermits=4.

**\[java\]**  [view plain][]   [copy][view plain]

1. <span style="font-size:12px;"> static final class SmoothBursty extends SmoothRateLimiter \{  
2.     /\*\* The work (permits) of how many seconds can be saved up if this RateLimiter is unused? \*/  
3.     final double maxBurstSeconds;       
4.     SmoothBursty(SleepingStopwatch stopwatch, double maxBurstSeconds) \{  
5.       super(stopwatch);  
6.       this.maxBurstSeconds = maxBurstSeconds;  
7.     \}    
8.     @Override  
9.     void doSetRate(double permitsPerSecond, double stableIntervalMicros) \{  
10.       double oldMaxPermits = this.maxPermits;  
11.       maxPermits = maxBurstSeconds \* permitsPerSecond;  
12.       if (oldMaxPermits == Double.POSITIVE\_INFINITY) \{  
13.         // if we don't special-case this, we would get storedPermits == NaN, below  
14.         storedPermits = maxPermits;  
15.       \} else \{  
16.         storedPermits = (oldMaxPermits == 0.0)  
17.             ? 0.0 // initial state  
18.             : storedPermits \* maxPermits / oldMaxPermits;  
19.       \}  
20.     \}    
21.     @Override  
22.     long storedPermitsToWaitTime(double storedPermits, double permitsToTake) \{  
23.       return 0L;  
24.     \}  
25.   \}

RateLimiter 允许某次请求拿走超出剩余令牌数的令牌，但是下一次请求将为此付出代价，一直等到令牌亏空补上，并且桶中有足够本次请求使用的令牌为止 [2][] 。这里面就涉及到一个权衡，是让前一次请求干等到令牌够用才走掉呢，还是让它先走掉后面的请求等一等呢？Guava 的设计者选择的是后者，先把眼前的活干了，后面的事后面再说。这里我看网上举了例子便于理解，以每秒qps=4，头两步消耗4个，剩余存储4个。在第三步的时候之前存储了4个，加上本次的共8个，但是本次请求了10个，所以透支了2个，第四次请求的时候，需要补上2个，等待0.5秒。

(1).t=0,这时候storedPermits=0，请求1个令牌，等待时间=0；

(2).t=1,这时候storedPermits=3，请求3个令牌，等待时间=0；

(3).t=2,这时候storedPermits=4，请求10个令牌，等待时间=0，超前使用了2个令牌；

(4).t=3,这时候storedPermits=0，请求1个令牌，等待时间=0.5；

### 3.4.2SmoothWarmingUp ###

**\[java\]**  [view plain][]   [copy][view plain]

1.  static final class SmoothWarmingUp extends SmoothRateLimiter \{  
2.      private final long warmupPeriodMicros;  
3.      /\*\* 
4.       \* The slope of the line from the stable interval (when permits == 0), to the cold interval 
5.       \* (when permits == maxPermits) 
6.       \*/  
7.      private double slope;  
8.      private double halfPermits;  
9.      
10.     SmoothWarmingUp(SleepingStopwatch stopwatch, long warmupPeriod, TimeUnit timeUnit) \{  
11.       super(stopwatch);  
12.       this.warmupPeriodMicros = timeUnit.toMicros(warmupPeriod);  
13.     \}  
14.     
15.     @Override  
16.     void doSetRate(double permitsPerSecond, double stableIntervalMicros) \{  
17.       double oldMaxPermits = maxPermits;  
18.       maxPermits = warmupPeriodMicros / stableIntervalMicros;  
19.       halfPermits = maxPermits / 2.0;  
20.       // Stable interval is x, cold is 3x, so on average it's 2x. Double the time -> halve the rate  
21.       double coldIntervalMicros = stableIntervalMicros \* 3.0;  
22.       slope = (coldIntervalMicros - stableIntervalMicros) / halfPermits;  
23.       if (oldMaxPermits == Double.POSITIVE\_INFINITY) \{  
24.         // if we don't special-case this, we would get storedPermits == NaN, below  
25.         storedPermits = 0.0;  
26.       \} else \{  
27.         storedPermits = (oldMaxPermits == 0.0)  
28.             ? maxPermits // initial state is cold  
29.             : storedPermits \* maxPermits / oldMaxPermits;  
30.       \}  
31.     \}  
32.     
33.     @Override  
34.     long storedPermitsToWaitTime(double storedPermits, double permitsToTake) \{  
35.       double availablePermitsAboveHalf = storedPermits - halfPermits;  
36.       long micros = 0;  
37.       // measuring the integral on the right part of the function (the climbing line)  
38.       if (availablePermitsAboveHalf > 0.0) \{  
39.         double permitsAboveHalfToTake = min(availablePermitsAboveHalf, permitsToTake);  
40.         micros = (long) (permitsAboveHalfToTake \* (permitsToTime(availablePermitsAboveHalf)  
41.             + permitsToTime(availablePermitsAboveHalf - permitsAboveHalfToTake)) / 2.0);  
42.         permitsToTake -= permitsAboveHalfToTake;  
43.       \}  
44.       // measuring the integral on the left part of the function (the horizontal line)  
45.       micros += (stableIntervalMicros \* permitsToTake);  
46.       return micros;  
47.     \}  
48.     
49.     private double permitsToTime(double permits) \{  
50.       return stableIntervalMicros + permits \* slope;  
51.     \}  
52.   \}

maxPermits等于热身(warmup)期间能产生的令牌数，比如QPS=4，warmup为2秒，则maxPermits=8.halfPermits为maxPermits的一半.  
![Center 3][]

这个图还不是很理解，对比上一个实现方式，就是不能透支，需要的资源就等待。这里待测试验证。

# 四 其他常见实现方式 #

## 4.1Proxy 层的实现，针对部分 URL 或者 API 接口进行访问频率限制 ##

#### Nginx 模块 ####

limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
    server {
        location /search/ {
            limit_req zone=one burst=5;
        }

详细参见：  [ngx\_http\_limit\_req\_module][ngx_http_limit_req_module]

#### Haproxy 提供的功能 ####

详细参见：  [Haproxy Rate limit 模块][Haproxy Rate limit]

## 4.2基于 Redis 功能的实现 ##

这个在 Redis 官方文档有非常详细的实现。一般适用于所有类型的应用，比如 PHP、Python 等等。Redis 的实现方式可以支持分布式服务的访问频率的集中控制。Redis 的频率限制实现方式还适用于在应用中无法状态保存状态的场景。

参见：[Redis INCR rate limiter][]

参考：

http://xiaobaoqiu.github.io/blog/2015/07/02/ratelimiter/

[Token Bucket]: http://en.wikipedia.org/wiki/Token_bucket
[leaky bucket]: http://en.wikipedia.org/wiki/Leaky_bucket
[Center]: /images/20220528/430cc0b8b11746d78793c9d11f7be690.png
[Center 1]: /images/20220528/f00434be4875457d8de2f7a1ff9a5794.png
[Little]: http://en.wikipedia.org/wiki/Little'%20rel=
[view plain]: https://blog.csdn.net/bohu83/article/details/51596346#
[Center 2]: /images/20220528/57ad3d1e59814f1b89ffe475f8a77318.png
[2]: https://yq.aliyun.com/articles/4243#fn2
[Center 3]: /images/20220528/c67d21a76d1744ceaad9e4dad66f9350.png
[ngx_http_limit_req_module]: http://nginx.org/en/docs/http/ngx_http_limit_req_module.html
[Haproxy Rate limit]: http://blog.serverfault.com/2010/08/26/1016491873/
[Redis INCR rate limiter]: http://redis.io/commands/INCR#pattern-rate-limiter