【Spring】Spring AOP 结合 Redis + Lua 脚本实现分布式限流

springboot + aop + Lua分布式限流的最佳实践

if c and tonumber(c) > tonumber(ARGV[1]) then //获取的key执行的次数是否大于允许的最大值，如果是直接返回，拒绝访问。c = redis.call('get',KEYS[1]) //从redis获取key执行的次数。c = redis.call('incr',KEYS[1]) //key对应的value增加1。redis.call('expire',KEYS[1],ARGV[2]) //对key设置过期时间。* 给定的时间范围 单位(秒)

SpringBoot整合Lua脚本

接口每秒限制客户端访问200次 创建lua，放到resource下myLimit_ip.lua -- 为某个接口的请求IP设置计数器，比如：127.0.0.1请求查询用户接口 -- KEYS[1] = 127.0.0.1 也就是用户的IP -- ARGV[1] = 过期时间 1s -- ARGV[2] = 限制的次数 local count = redis.call('incr',KEYS[1]); if count == 1 then redis.call("expire",...

SpringBoot 是为了简化 Spring 应用的创建、运行、调试、部署等一系列问题而诞生的产物，自动装配的特性让我们可以更好的关注业务本身而不是外部的XML配置，我们只需遵循规范，引入相关的依赖就可以轻易的搭建出一个 WEB 工程 本篇从 Spring Boot、Redis 应用层面来实现分布式的限流…. 分布式限流 单机版中我们了解到 AtomicInteger、RateLimiter、Semaphore 这几种解决方案...

由于后续要使用lua脚本来做权限控制，所以必须自定义一个redisTemplate，此处如果不自定义redisTemplate，则执行lua脚本时会报错。登录后复制@Bean1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.

Lua脚本(rateLimiter.lua)

通过 AOP 结合 Redis + Lua 脚本实现分布式限流，旨在保护 API 被恶意频繁访问的问题 自定义注解 @Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) @Documented public @interface RateLimiter { long DEFAULT_REQUEST = 10; /** * max 最大请求数 */ @AliasFor("max").

SpringBoot是为了简化Spring应用的创建、运行、调试、部署等一系列问题而诞生的产物，自动装配的特性让我们可以更好的关注业务本身而不是外部的XML配置，我们只需遵循规范，引入相关的依赖就可以轻易的搭建出一个 WEB 工程本篇从Spring Boot、Redis应用层面来实现分布式的限流….分布式限流单机版中我们了解到 AtomicInteger、RateLimiter、Sema...

先在ratelimiter_annotation模块中引入aop的依赖。然后在ratelimiter_annotation模块中新建一个annotation的包，并在annotation包下创建一个名为AccessLimiter的注解。再创建一个aspect的包，并创建一个名为AccessLimiterAspect的类@Slf4j@Aspect@Component@Autowired@Autowired//1、获得方法签名，作为method keyreturn;

掌握高效API接口限流实现方案，基于Redis+Lua打造高性能分布式限流器。适用于高并发场景，保障系统稳定，具备原子性与低延迟优势，支持灵活配置。值得收藏的实战技术解析，点击了解实现细节。

整个开发过程最惊喜的是平台的一键部署能力——写完代码直接点击部署按钮，马上就生成可测试的在线接口，省去了自己搭建Redis和配置环境的时间。对于需要快速验证技术方案的场景，这种即时反馈的体验确实能大幅提升效率。建议自己尝试时可以先从简单配置开始（比如先实现单机限流），再逐步添加分布式支持。快速搭建了一个基于自定义注解的限流原型，整个过程比想象中简单很多，特别适合需要快速验证方案的场景。在微服务架构中，API限流是保护系统稳定的重要手段。- 99%的限流判断耗时在2ms内完成。的模板库就能找到现成的示例。

*** 限流 key（支持 SpEL 表达式，如 #ip）*//*** 时间窗口（单位：秒）*//*** 允许的最大请求数*//*** 限流失败时的提示信息*/String message() default "请求过于频繁，请稍后再试";key支持 SpEL（如），后面会解析。

通过这三个案例，我们可以看到自定义注解 + AOP 的强大之处： 零侵入：业务代码里只有 @OperLog、@Idempotent，干干净净。 可复用：写一次切面，全公司 100 个微服务都能用。 易维护：修改限流算法？改切面代码就行，不用动业务逻辑。 最后，送上架构师金句： “优秀的架构师善于利用 AOP 将非业务逻辑封装成‘基础设施’。业务开发人员只需要关注核心逻辑（怎么赚钱），剩下的脏活累活（怎么记账、怎么安保），交给注解和切面。” 现在，去给你的项目贴上“标记”，部署“安检员”吧！️

支持选择限流算法维度参数。/** 限流 key 前缀 *//** 算法模式：滑动窗口 / 令牌桶 *//** ---------------- 滑动窗口参数 ---------------- */// 时间窗口（秒）// 窗口内允许的请求数/** ---------------- 令牌桶参数 ---------------- */// 桶容量// 每次补充令牌数// 补充周期（毫秒）// 单次请求消耗令牌数// 空桶过期（毫秒）/** 限流维度：方法、IP、用户 */