限流策略通常是用来在高qps下进行流量限制的，常见的方式有计数器、令牌桶、漏桶。在这次活动中我负责的模块是控制的对下游的流量，我们可以让那些请求选择丢弃、等待或者降级这些限流算法可以自行实现也可以利用现有的限流工具，比如说Guava的令牌桶，具体看场景需求吧，下面来看一下这几种限流策略，再说说我写的限流方式。
1、计数器限流
这种方式比较粗暴，相当于有一个计数器来控制单秒请求数，也就是qps定义的方式。比如说限流2000，每秒钟对于计数器进行置0操作，当一秒内到达2000时就不再接受请求了。这样能保证较长时间短的流量均匀，但是单秒内部实际上是不均匀的，可能这2000个请求，在前0.1s就处理完成了，后面的都是被丢掉的，并且峰值qps 可能是达到2w的。
2、令牌桶限流
令牌桶限流是指我们可以设立一个令牌桶，然后以固定的速率往令牌桶中添加令牌，令牌桶满则不添加。请求到来时检查如果令牌桶中有令牌则取走令牌，发起请求。假设要限定 2000 qps，则1/2000 的速率向令牌桶添加令牌，也可以1/1000 一次性添加两个令牌，以此类推。令牌桶在持续高qps 下是没问题的，可以把流量限制的比较均匀。但是面对突发流量时，流量桶里是满的，可能一瞬间把令牌抢空完成请求，这里的问题和计数器限流实际上是一样的，峰值可能远远大于2000，所以对于突发流量是限不住的。下面看看令牌桶的示意图：其实我感觉令牌桶更像是优化后的计数器限流，只不过时间窗口由1s变的更细了
3、漏斗限流
这个是使用最多的一种限流算法，通常用来流量整形或者流量控制，看起来和令牌桶比较像，但是差异还是比较大的。漏斗往桶里加的是请求，不是令牌，相当于新请求到达时放到桶中，如果桶满了则溢出请求，桶以匀速漏出请求进行处理，比如qps 2000，则1/2000 s 漏出一个请求进行处理。这种限流方式比较稳定，但是需要维护一个请求队列或者任务队列。
漏斗&令牌桶比较：
令牌桶是按照固定速率往桶中添加令牌，请求是否被处理需要看桶中令牌是否足够，当令牌数减为零时则拒绝新的请求；
漏桶则是按照常量固定速率流出请求，流入请求速率任意，当流入的请求数累积到漏桶容量时，则新流入的请求被拒绝；
令牌桶限制的是平均流入速率（允许突发请求，只要有令牌就可以处理，支持一次拿3个令牌，4个令牌），并允许一定程度突发流量；
漏桶限制的是常量流出速率（即流出速率是一个固定常量值，比如都是1的速率流出，而不能一次是1，下次又是2），从而平滑突发流入速率；
令牌桶允许一定程度的突发，而漏桶主要目的是平滑流入速率；
两个算法实现可以一样，但是方向是相反的，对于相同的参数得到的限流效果是一样的。
看完几种限流策略原型之后，放到具体的业务场景中看算法的选择及我们需要作出的改动。
业务端限流：
业务端做限流的话，请求来源于上有系统，流量要求是比较平稳的，峰值不能太高，否则可能一瞬间打挂系统，令牌桶和计数器方式就不太合适了。因为如果流量直接打到业务系统我们是没法进行预估的，大概率会有突发流量，所以选择直接使用流量桶就比较合适了。
consumer 控制对下游流量：
我所处的业务场景是nginx + lua 打入redis 则认为成功，consumer端消费消息，然后持续固定qps对下游发起请求。这种场景下，把消费速率&对下游qps控制放在consumer端来做就比较合适了。首先我们从Redis或者日志文件中读取了数据，并且拼接了请求任务放到任务队列中。然后线程池从任务队列中取任务发起请求，首先我们需要控制加入任务队列的速率，因为加入的任务队列的速度大于任务队列的消费速度，肯定是会导致OOM产生的，
我这里使用的是类似令牌桶的方式，一个线程取n个任务，然后线程内串行，几个线程并行，这样就一定程度上保证了不会出现令牌桶的流量不均问题了，同时减少了锁的争用。实际上使用漏斗算法也是合适的，但是对于这个场景来说，溢出任务实际上是不太好控制，需要让请求的加入速率与消费速度相对保持一致，这一点控制不好很容易oom的，所以直接采用任务队列 + 令牌桶实现是最方便控制也是最容易实现的，采用线程内一次取多个，串行发起请求的方式是可以一定程度上控制住流量的 实践证明效果不错。
