Redis实战之限制操作频率
最近沉迷于业务开发无法自拔 🤣,有一段时间没有更新博文了,后续博文内容计划把一些业务场景下的实战方案,或者比较好的设计思路进行分享,就不像之前围绕着一个主题,消耗很多的时间去整理相关内容(憋大招),后续可能一篇的内容量就没那么丰富,但是尽可能针对一个点进行更细化,或者更深入的分析,通过不断分享和自我复盘,进行经验的沉淀,同时提高博文分享的频率 🤙
场景
场景1
留言功能限制,30秒 内只能评论 10次,超出次数不让能再评论,并提示:过于频繁
场景2
点赞功能限制,10秒 内只能点赞 10次,超出次数后不能再点赞,并禁止操作 1个小时,提示:过于频繁,被禁止操作1小时
场景3
上传记录功能,限制一天只能上传 100次,超出次数不让能再上传,并提示:超出今日上线
抽离本质
在业务开发的过程中,我们不断的参与各种业务场景的方案设计,往往很容易碰到很类似的场景,只不过当前所属的业务模块不一样,其实这些需求的本质是解决同一个问题,当遇到这种场景的时候,我们需要根据自己经验分析抽离出需求的本质问题,实现一个通用的解决方案,让自己的解决方案更有价值,这可能就是区别于你是有灵魂的工程师还是cp(copy paste)最强王者吧。
分析上面3个业务场景,可以从中发现其中有相似的逻辑,称它为同类的问题,现在我们就是要抽离这个问题,设计一个通用的解决方案,勾画相同逻辑流程图:
通过分析上面的需求场景,抽离出他们都需要的那些条件:
- 限制对象:用户
- 限制操作(评论,点赞,记录, ...)
- 时间范围X秒内
- 限制操作数Y次
- 超出后禁止操作时间Z(秒/具体时间)
- 超出后不让再操作,并提示
(最小时间单位用秒:天/小时/分钟都可换算成秒,用秒可以解决更多的场景)
如果把功能抽离成一个通用函数是不是大概是这样:
<?php /** * 频率限制 * @param string $action 操作动作 * @param int $userId 发起操作的用户ID * @param int $time 时间范围X秒内 * @param int $number 限制操作数Y次 * @param array $expire 超出封印时间Z ['type'=>1,'ttl'=>过期时间/秒] ['type'=>2,'ttl'=>具体过期时间戳] 二选一 * @return bool * @throws \Exception */ public static function frequencyLimit(string $action, int $userId, int $time, int $number, $expire = []) { // todo 根据用户操作动作时间范围,进行频率的控制和失效释放 }
解决方案落地
功能中需要对用户发起的操作和时间,以及累计次数进行存储,并且需要失效过期的清理,如果这个时候我们依赖mysql做存储,想想都觉的挺痛苦,这里主角:redis 终于登场了,基于redis特性,incr的原子操作和key 支持过期机制,内存存储的效率优势,可以相对简单灵活并且又高效的完成目的。
这里简单实现个通用功能的代码:
<?php /** * 频率限制 * @param string $action 操作动作 * @param int $userId 发起操作的用户ID * @param int $time 时间范围X秒内 * @param int $number 限制操作数Y次 * @param array $expire 超出封印时间Z ['type'=>1,'ttl'=>过期时间/秒] ['type'=>2,'ttl'=>具体过期时间戳] 二选一 * @return bool * @throws \Exception */ public function frequencyLimit(string $action, int $userId, int $time, int $number, $expire = []) { if (empty($action) || $userId <= 0 || $time <= 0 || $number <= 0) { throw new \Exception('非法参数'); } $key = 'act:limit:' . $action . ':' . $userId; $r = RedisClient::connect(); //获取当前累计次数 $current = intval($r->get($key)); if ($current >= $number) return false; //累计并返回最新值 $current = $r->incr($key); //第一次累加,设置控制操作频率的有效时间 if ($current === 1) $r->expire($key, $time); //未超出限制次数先放过 if ($current < $number) return true; //超出后根据需要重新设置过期失效时间 $current === $number 判断保证只重新设置一次 $type = empty($expire['type']) ? 0 : intval($expire['type']); $ttl = empty($expire['ttl']) ? 0 : intval($expire['ttl']); if ($current === $number && $ttl > 0 && in_array($type, [1, 2])) { if ($type === 1) $r->expire($key, $ttl); if ($type === 2) $r->expireAt($key, $ttl); } return false; } //场景1 /** * 评论限制 * @param int $userId * @return bool|string */ public function doComment(int $userId) { try { $pass = FrequencyLimit::doHandle('comment', $userId, 30, 10); if (!$pass) return '过于频繁'; // todo 评论逻辑 return true; } catch (\Exception $e) { return $e->getMessage(); } } //场景2 /** * 点赞限制 * @param int $userId * @return bool|string */ public function doLike(int $userId) { try { $pass = FrequencyLimit::doHandle('like', $userId, 10, 10, ['type' => 1, 'ttl' => 1 * 60 * 60]); if (!$pass) return '过于频繁,被禁止操作1小时'; // todo 点赞逻辑 return true; } catch (\Exception $e) { return $e->getMessage(); } } //场景3 /** * 上传限制 * @param int $userId * @return bool|string */ public function doUpload(int $userId) { try { $expire = strtotime(date('Y-m-d', strtotime(+1 . 'days'))); $pass = FrequencyLimit::doHandle('upload', $userId, 1 * 24 * 60 * 60, 100, ['type' => 2, 'ttl' => $expire]); if (!$pass) return '超出今日上线'; // todo 上传逻辑 return true; } catch (\Exception $e) { return $e->getMessage(); } } //场景N
编码上可以根据你设计这个通用方案的复杂度进行进一步抽象,如抽象成频率限制的功能类 等
总结
- 对相似的业务场景进行分析,发现本质问题并设计通用的解决方案
- 让解决方案更有价值,做一个有灵魂的开发者
- 熟练掌握redis,充分利用它的特性和优势
首发于Github🌈大话WEB开发,欢迎Star 🥰

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
细谈 vue - transition-group 篇
本篇文章是细谈 vue 系列的第四篇,按理说这篇文章是上篇 《细谈 vue - transition 篇》中的一个单独的大章节。然鹅,上篇文章篇幅过长,所以不得已将其单独拎出来写成一篇了。对该系列以前的文章感兴趣的可以点击以下链接进行传送 《细谈 vue 核心- vdom 篇》 《细谈 vue - slot 篇》 《细谈 vue - transition 篇》 书接上文,上篇文章我们主要介绍了 <transition> 组件对 props 和 vnode hooks 的 输入 => 输出 处理设计,它针对单一元素的 enter 以及 leave 阶段进行了过渡效果的封装处理,使得我们只需关注 css 和 js 钩子函数的业务实现即可。 但是我们在实际开发中,却终究难逃多个元素都需要进行使用过渡效果进行展示,很显然,<transition> 组件并不能实现我的业务需求。这个时候,vue 内部封装了 <transition-group> 这么一个内置组件来满足我们的需要,它很好的帮助我们实现了列表的过渡效果。 一、举个例子 老样子,直接先上一个官方...
- 下一篇
线程池没你想的那么简单(续)
前言 前段时间写过一篇《线程池没你想的那么简单》,和大家一起撸了一个基本的线程池,具备: 线程池基本调度功能。 线程池自动扩容缩容。 队列缓存线程。 关闭线程池。 这些功能,最后也留下了三个待实现的 features 。 执行带有返回值的线程。 异常处理怎么办? 所有任务执行完怎么通知我? 这次就实现这三个特性来看看 j.u.c 中的线程池是如何实现这些需求的。 再看本文之前,强烈建议先查看上文《线程池没你想的那么简单》 任务完成后的通知 大家在用线程池的时候或多或少都会有这样的需求: 线程池中的任务执行完毕后再通知主线程做其他事情,比如一批任务都执行完毕后再执行下一波任务等等。 以我们之前的代码为例: 总共往线程池中提交了 13 个任务,直到他们都执行完毕后再打印 “任务执行完毕” 这个日志。 执行结果如下: 为了简单的达到这个效果,我们可以在初始化线程池的时候传入一个接口的实现,这个接口就是用于任务完成之后的回调。 public interface Notify { /** * 回调 */ void notifyListen() ; } 以上就是线程池的构造函数以及接口的定义。 所...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS7安装Docker,走上虚拟化容器引擎之路
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- SpringBoot2全家桶,快速入门学习开发网站教程
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS7,CentOS8安装Elasticsearch6.8.6
- 2048小游戏-低调大师作品
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7