最近有个分享，关于频率限制的redis实现。
主要是使用redis的命令：incr/decr
incr/derc的作用就是对某个key进行+1或者-1。适用的场景之一：频率限制
简单的实现
在以往的频率限制方案里面，如果不是太讲究的话，可以直接使用简单粗暴地方法——当访问一次之后，在redis生成一个key（带有过期时间），再次访问的时候，就查一下这个key是否存在，用来判断该次访问是否被放行。这个做法有个不好的地方，时间频率都固定下来了，说好1秒1次，就不会让你1秒2次。
所以，如果想要灵活一点的话，我们可以尝试使用以下两个算法。
令牌桶、漏桶算法
这里主要讲令牌桶
我是令牌桶
原理： 每一个访客都拥有一个独立的“令牌桶”，在这个“令牌桶”里放了一些“令牌”，访客每次来访都会消耗“令牌桶”中的“令牌”，如果“令牌桶”空了，将会对访客做特殊处理（如拒绝其继续访问以达到限流的目的，或者拉黑一段时间再放行）。
比如，60秒内限制A用户最多只能访问a接口100次
这里有两个问题
- 访客终有一天会花光所有的令牌，所以我们需要不断地补给。按照一定的频率往桶里放一些令牌。至于这个频率是多少，和预期保持一致即可（每过60/100秒钟往桶里加一个）
-
如果某个用户访问了一次之后，再也没有来过，怎么办？令牌会一直增加一直增加啊。所以我们可以设置最大的令牌数（100）.
-
怎么定时加令牌？如果直接简单粗暴地加个定时器，不断往桶里加令牌。那不实际，恐怕没过多久，项目就崩了 。这里有个比较巧妙的地方——我不需要定时器，只要记下你当前访问的时间，然后和下次来的时间作一个比对，就可以知道应该往桶里增加多少了。比如，上次访问的时候有34个令牌，6秒之后再来访问，可以往桶里增加 （100/60）* 6 = 10 个，所以这个时候桶里就有44个啦。
-
如果一个用户访问一次以后，从此以后不再访问，怎么办？redis会一直保存着他的信息啊。做法之一，可以在初始化的时候，给他一个过期时间。
总结上面的种种问题。我们需要确定几个值：时间、次数、令牌桶的初始值。如60秒、100次、50个令牌（半桶）。
redis的实现
很幸运的是，redis天生就可以为我们做这些事情。—— inrc/derc是原子操作, 这里用到的是derc, 当然，也可以反过来使用inrc。区别不大
实现起来难度不大，代码就不写了。附上链接
不过，这个算法还是会存在一定的缺陷。假如，每分钟允许某个用户访问100次，按照以上的做法，可以会出现以下情况。
- A用户访问a接口，在第1秒直接就撸完了100次，剩下的59秒应该怎么办？因为是每秒钟增加100/60个令牌，所以，1分钟过去，可能这个用户会访问了200次了。
- 还是A用户。前59秒（第1秒）之撸了1次（为什么是1次？），在接近60秒的时候，突然爆发访问99次。这个时候就用光了所有令牌，而且有效期刚过完，下一个循环又来了，再第61秒狂撸100次。至此，在短短的时间里，访问了接近200次，甚至，在这两分钟里访问了300次。显然，这并不符合我们的要求。
上面两个问题，如果可以忍受，问题不大，实在不能忍，可以稍微改一下。关于有效期，我们可以效仿session的机制。给用户一个过期时间（1分钟），每次来访问的时候，都重置这个有效期。一分钟过后，再无访问的话，就直接过期了，等待用户下次光临。而且，可以让初始令牌为最大个数的一半，即50。这两个做法，可以解决什么问题呢？
问题1，一分钟最多只能150次
问题2，短时间内只能一次性访问100次，降低应用被拖垮的风险。
如果还是不能忍的话，可以再想办法进行改造。总会有一个方案满足你的胃口。
比如，可以用列表来保存用户每次访问的时间。一旦当前列表长度大于等于100，就用当前时间和第一个元素的时间进行比较，如果小于60秒的话，就直接拒绝啦。同时，把第一个元素删除，让当前时间保存到列表里。如此一来，就可以保证每60秒，最多只能让用户最多访问100次。
上面就是令牌桶算法了。
漏桶算法
既然提到令牌桶，就不得不提另外一个了——漏桶算法。这两个概念有点像，都是限制一段时间允许用户访问的最大次数。不同的是，令牌桶更加灵活一点，允许某种程序的突发传输。比如上面说的问题2,洪峰爆发。那么，漏桶算法是什么鬼？
我是漏桶
如上图所示，我们假设系统是一个漏桶，当请求到达时，就是往漏桶里“加水”，而当请求被处理掉，就是水从漏桶的底部漏出。水漏出的速度是固定的，当“加水”太快，桶就会溢出，也就是“拒绝请求”。从而使得桶里的水的体积不可能超出桶的容量。
需要注意的是，这里的漏水速率是恒定的。可以简单粗俗地理解为，该服务每秒钟只能处理N个请求，当接收到请求（从天而降的水）的时候，会放入桶中待处理。当桶（队列）满了的时候，会直接拒绝丢弃。使用该算法，可以有效地避免服务被过度使用导致性能严重下降。
这两个算法可以结合使用。令牌桶可以用于针对单个用户访问的频率，漏桶可以用于限制某个接口在规定时间内的被（所有用户）访问次数。
举个例子。对于接口a而言。
- 每个人在1分钟内最多只允许访问100次；
- 该接口在1分钟内最多只能被调用100,000次；
前者为了防止被恶意大量调用，后者保证服务可用。这样，在接口频率限制的情况下，允许个别情况持续突发。
说了这么多，可以发现redis还是挺好用的。虽然，这种事情并不一定要在项目里面做，其实还可以在代理服务器上面进行。
nginx的方案
nginx也有自己的解决方案，直接在配置文件里面配置即可
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
server {
location /search/ {
limit_req zone=one burst=5;
}
}
总结
通篇文章读完之后，发现自己写的其实是访问频率限制（可恶的标题党，还以为你讲的是redis）。好吧，我说的就是这个算法。
这两个算法不只是接口频率限制，其实还能用在各种各样关于限制的事情上。比如，验证码的使用，不能被过度使用。
网友评论