计数器法

计数器算法，也成固定窗口法。可以控制在固定的时间窗口内，允许通过的最大的请求数。

例如，我们设定时间间隔窗口为1分钟，该窗口内的最大请求数max为100。当第1个请求到来时，我们记录下当前窗口内的第一个请求的时间firstReqTime，那么之后的请求到来时，先判断是否进入下一个窗口。

如果进入，则直接重置firstReqTime为当前时间，该请求通过。如果没进入，再判断是否超过max。

计数器法的缺点
该算法无法应对突发的流量，因为计数器法是固定窗口的。

例如第一个请求10:00:00到来，那么第一个时间窗口为10:00:00-10:01:00。之后在10:00:59时，突然来了99个请求，又在下一个时间窗口的10:01:01来了100个请求。

也就是说，在10:00:59-10:01:01的短短几秒内，共有199个请求到来，可能会瞬间压垮我们的应用。

滑动窗口法

滑动窗口法可以解决计数器在固定窗口法下无法应对突发流量的问题

固定窗口法是以第一个请求为窗口开始期，并向后截取intervalWindow长度，只有当窗口时间流逝完，才开辟新的窗口。

滑动窗口法以每一个请求为窗口结束期，向前截取intervalWindow长度，检查该范围内的请求总和，相当于会为每个请求开辟一个新窗口。

漏桶法

水龙头可以通过松紧来控制出水的速率，下方有一个储蓄桶来保存当前的水。储蓄通底部有一个出口，内部的水会以恒定的速率从出口漏掉。
如果储蓄桶满了之后，再进来的水会全部溢出。只有当出水速率和漏水速率相同时，储蓄桶才会在不漏水的前提下达到最大的吞吐量。
我们把水比作请求，水龙头就是客户端。请求产生的速率肯定不是恒定的，但处理请求的速率是恒定的。当储蓄桶满了之后，请求产生的速率必须要和处理请求的速率一致。
漏桶法的缺点
使用漏桶法去做限流，在业务平稳期其实已经够用了。但是在业务高峰期，我们又希望动态地去调整处理请求的速率，而不是一成不变的速率。
我们大可以动态地去改变参数leakRate的值，不过在计算剩余水量的时候，将会十分复杂。
因此，如果要考虑到对突发流量的控制，就不太推荐漏桶法了。

令牌桶法

首先有一个令牌桶，然后系统以一个恒定的速率向桶中放入令牌。当桶满时，会丢弃生成的令牌。

每有一个请求过来时，拿到令牌就可以执行，否则阻塞获取或者被直接丢弃。
漏桶是以一个恒定速率的出水，即处理请求的速率是恒定的。而令牌桶则是以一个恒定的速率往桶中放入令牌，在桶中令牌用完之前，并不限制处理请求的速率。
令牌桶的一个优势在于，可以允许短时间内的一次突发流量。但不会允许在短时间内的多次突发流量，因为令牌的填充也是需要时间的。