CloudCurrentLimit —— 限流控制工具
CloudCurrentLimit 基于 redis 的 Lua 脚本实现对高并发下的限流控制,可极大降低系统的接入成本,对高并发系统进行限流达到保护系统的目的。
开箱即用
引入maven,配置文件,注解一打,1分钟集成好限流,真正的做到了开箱即用。
使用场景:
无需独立启动第三方服务,以jar包方式和项目一起启动,不存在第三方服务挂掉的风险,对整个集群限流
如果我们的系统有高并发限流场景,自己临时写可能会有bug,引入现在市面上的限流工具,要么需要单独启动服务,要么配置繁琐,有没有低成本高效接入的限流组件呢?
显而易见CloudCurrentLimit正是很好符合该需求的选择,只需要简单的配置即可达到限流效果.
springboot集成版本支持 2.2.2.RELEASE<=Version<3.x
实现了集群状态下的限流,限流对整个集群生效
1.引入maven依赖
<dependency> <groupId>net.oschina.likaixuan</groupId> <artifactId>cloud-limit-spring-boot-starter</artifactId> <version>2.2.2.RELEASE</version> </dependency>
2. application.yml中开启限流配置
spring: redis: host: localhost database: 0 lettuce: pool: max-active: 10 max-idle: 10 max-wait: -1ms shutdown-timeout: 100ms password: port: 6379 cloud: limit: scan-package: com/example/demoplus/controller #项目中的controller包 type: TOKEN #目前算法只支持令牌桶算法,写死TOKEN就行
3.Controller 类上打上注解
@CloudLimitAnnottion( limitCount = 2, #每秒限流请求次数,默认50 limitMsg = "你被限流了" #支持配置自定义限流提示语句,可不配置,不配置默认提示限流【触发限流了】 )
举个栗子
4.该步骤一般项目中都有自己的全局捕获异常,只需要捕获RuntimeException即可,当然也可以捕获限流的异常类CloudLimitException
@RestControllerAdvice public class GlobalExceptionHandler { @ResponseStatus(HttpStatus.BAD_REQUEST) @ExceptionHandler(value = CloudLimitException.class) public R handler(CloudLimitException e){ return R.error(e.getMessage()); } }
如果项目启动有限流相关日志输出,则说明限流生效,如下图

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
每日一博 | 委派模式 —— 从 SLF4J 说起
作者:vivo 互联网服务器团队- Xiong yangxin 将某个通用解决方案包装成成熟的工具包,是每一个技术建设工作者必须思考且必须解决的问题。本文从业内流行的既有工具包入手,解析实现思路,沉淀一般方法。为技术建设的初学者提供一些实践思路的参考。尤其是文中提倡的“去中心化”的协作模式,和“关键链路+开发接口”的开发模式,具有一定的实际落地意义。当然本文在行文中,不可避免存在一定主观偏见性,读者可酌情阅读。 一、前言 熟悉JAVA服务器开发的同学应该都使用过日志模块,并且大概率使用过"log4j-over-slf4j"和“slf4j-log4j”这两个包。那么这两个包的区别是什么?为什么会互相引用包含呢?这篇文章会解释下这几个概念的区别。 首先说一下SLF4J。 二、从SLF4J开始 SLF4J全称"Simple Logging Facade for Java (SLF4J)", 它诞生之初的目的,是为了针对不同的log解决方案,提供一套统一的接口适配标准,从而让业务代码无须关心使用到的第三方模块都使用了哪些log方案。 举个例子, Apache Dubbo和RabbitMQ使用到...
- 下一篇
Stable Diffusion 因版权问题被起诉
日前,三位艺术家对 Stability AI(Stable Diffusion 背后的开发商)提起了诉讼,指控 Stability AI 直接、间接侵犯版权、违反 DMCA 和不正当竞争等。 这三位艺术家(Sarah Andersen、Kelly McKernan、Karla Ortiz)认为 Stability AI 在「未经原艺术家同意」的情况下,从网络上收集了数十亿张图片用于进行 AI 工具训练,侵犯了包括他们在内的数百万艺术家的权利。 三位艺术家通过专门处理反垄断和集体诉讼案件的 Joseph Saveri 律师事务所与律师 Matthew Butterick 发起了诉讼。其中 Butterick 和 Joseph Saveri 目前也正在起诉微软、GitHub 和 OpenAI,该案涉及 AI 编程模型 CoPilot,起诉的理由与本案类似,只不过一个涉及艺术品生成,另一个涉及代码生成。 律师 Butterick 将此案描述为「朝着使人工智能对每个人都公平和道德的方向迈出的又一步」。他认为像 "Stable Diffusion" 这样的人工智能艺术工具能够用无限数量的侵权图像...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS7设置SWAP分区,小内存服务器的救世主
- CentOS7,CentOS8安装Elasticsearch6.8.6
- Hadoop3单机部署,实现最简伪集群
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Red5直播服务器,属于Java语言的直播服务器
- CentOS7安装Docker,走上虚拟化容器引擎之路
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果