主流的四种限流策略，我都可以通过redis实现，干货仅此一篇

结果测试

• 我们设置的qps=3 ， 我们可以看到五个并发进来后前三个正常访问，后面两个就失败了。稍等一段时间我们在并发访问，前三个又可以正常访问。说明到了下一个时间窗口

滑动时间窗口算法

---

• 针对固定时间窗口的缺点–临界值出现双倍流量问题。 我们的滑动时间窗口就产生了。

• 其实很好理解，就是针对固定时间窗口，将时间窗口统计从原来的固定间隔变成更加细度化的单元了。

• 在上面我们固定时间窗口演示中我们设置的时间单元是1S 。 针对1S我们将1S拆成时间戳。

• 固定时间窗口是统计单元随着时间的推移不断向后进行。而滑动时间窗口是我们认为的想象出一个时间单元按照相对论的思想将时间固定，我们的抽象时间单元自己移动。抽象的时间单元比实际的时间单元更小。

• 读者可以看下下面的动图，就可以理解了。

优点

• 实质上就是固定时间窗口算法的改进。所以固定时间窗口的缺点就是他的优点。

• 内部抽象一个滑动的时间窗，将时间更加小化。存在边界的问题更加小。客户感知更弱了。

缺点

• 不管是固定时间窗口算法还是滑动时间窗口算法，他们都是基于计数器算法进行优化，但是他们对待限流的策略太粗暴了。

• 为什么说粗暴呢，未限流他们正常放行。一旦达到限流后就会直接拒绝。这样我们会损失一部分请求。这对于一个产品来说不太友好

实现

• 滑动时间窗口是将时间更加细化，上面我们是通过redis#setnx实现的。这里我们就无法通过他统一记录了。我们应该加上更小的时间单元存储到一个集合汇总。然后根据集合的总量计算限流。redis的zsett数据结构就和符合我们的需求。

• 为什么选择zset呢，因为redis的zset中除了值以外还有一个权重。会根据这个权重进行排序。如果我们将我们的时间单元及时间戳作为我们的权重，那么我们获取统计的时候只需要按照一个时间戳范围就可以了。

• 因为zset内元素是唯一的，所以我们的值采用uuid或者雪花算法一类的id生成器

controller

@RequestMapping(value = “/st