假设我们要做一个业务需求，这个需求就是限制用户的访问频次。比如1分钟内只能访问20次，10分钟内只能访问200次。因为是用户维度的场景，性能肯定是要首先考虑，那么适合这个场景的非redis莫属。
最简单的实现，莫过于只是用incr进行计数操作，于是有了下面的代码：
来，我们对上面这段代码解读一下。需求有2个时间维度的限制，所以这边基于用户和时间维度构建了redis的key。然后对每个key进行计数，计数后的结果用于跟限制的值进行判断，如果超出了限制的值就抛出异常。
假设限制的时间场景有10个呢？那上面的代码是不是得写10遍才可以。有人可能会说，这还不简单吗？循环呀，循环确实能够解决这个问题。但是大家有没有去思考，这是用户维度的请求，如果每个请求里面都去操作10次redis的话，这耗时至少也得10来毫秒吧。所以问题在这，并不是说这个逻辑实现的有问题。
那我们就改成批量的吧，用pipeline来批量执行。
用pipeline也有一个问题，那就是拿不到返回值，也就只能增加，但是没办法判断是否超过了限制的阀值。
所以需要在第一步先查询下，用查到的值进行判断，这样也就是只需要和redis交互两次就可以了。
上面的代码在单节点下没问题，但是如果在集群下，其实每个key都可能分配到不同的节点上去，只不过是底层帮你屏蔽掉了细节，并发执行，拿到了所有结果后合并返回的。所以我们需要让所有的key都路由到一个节点上，本来就是用户维度的，直接使用userid路由即可。
这个时候redis的hashtag功能就排上用场了，将key user:1:600改写成user:{1}:600 。
虽然已经优化了，但是还是要发起两次网络请求才能完成这个逻辑，有没有可能再进一步优化下呢？一次请求行不行。
这个时候要放大招了，lua脚本走起，将所有逻辑都放入lua脚本中，一次网络交互即可完成。
上面脚本演示了如何对一个key进行处理，返回1表示限流，返回0表示通过。不过使用lua脚本的时候要注意，某些云服务的redis会对脚本进行校验，像redis的key不能使用变量，必须用keys[下标]的方式，所以这里操作多个key还不能用循环，代码得写多遍，这是一个恶心的点。
总结
到此这篇关于利用redis实现访问次数限流的文章就介绍到这了,更多相关redis访问次数限流内容请搜索www.887551.com以前的文章或继续浏览下面的相关文章希望大家以后多多支持www.887551.com！