基于拦截器Interceptor+Redis实现接口限流

 

最近开发的抢购活动上线后发现了两个比较明显的问题：

其一：活动一开始，接口访问量剧增；其二：黑名单中增加了一大批黑名单用户（或者说IP），这其中就包含了一些恶意用户或机器人刷接口。

针对一些高并发的接口，限流是处理高并发的几大利剑之一。一方面，限流可以防止接口被刷，造成不必要的服务层压力，另一方面，是为了防止接口被滥用。

限流的方式也蛮多，本篇只讲几种我自己常用的，并且是后端的限流操作。

漏桶算法

漏桶算法思路很简单，水（请求）先进入到漏桶里，漏桶以一定的速度出水，当水流入速度过大会直接溢出，可以看出漏桶算法能强行限制数据的传输速率。

漏桶算法示意图(图片取自网络)

漏桶算法可以很好地限制容量池的大小，从而防止流量暴增。

令牌桶算法

令牌桶算法的原理是系统会以一个恒定的速度往桶里放入令牌，而如果请求需要被处理，则需要先从桶里获取一个令牌，当桶里没有令牌可取时，则拒绝服务。

令牌桶算法通过发放令牌，根据令牌的rate频率做请求频率限制，容量限制等。

自定义注解+拦截器+redis实现限流

从代码层面来看，此方式实现还是比较优雅的，对业务层也没有太多的耦合。注意:此种方式单体和分布式均适用，因为用户实际的访问次数都是存在redis容器里的，和应用的单体或分布式无关。

@Inherited