要实现spring boot接口限流，核心方案是结合aop与redis。1. 使用aop定义自定义注解@ratelimit，配置限流参数；2. 利用redis的原子性操作执行lua脚本，确保分布式环境下计数准确；3. lua脚本实现令牌桶算法，控制请求频率；4. 在切面中拦截请求并调用redis执行限流逻辑；5. 被限流时抛出异常或返回错误码。该方法保障系统稳定性、资源公平分配，并提升安全性。选择限流算法需根据业务需求权衡突发流量处理能力。实践分布式限流时要注意key设计、脚本健壮性、异常处理、动态配置及redis高可用部署。
Spring Boot接口限流，说白了就是给你的API请求设个“门槛”，防止瞬间涌入的流量冲垮系统，或者被恶意刷爆。核心思想就是控制单位时间内的请求数量，确保系统稳定性和资源的合理分配。
解决方案
要在Spring Boot里实现接口限流，我个人觉得最稳妥、也最灵活的方案就是结合AOP（面向切面编程）和Redis。AOP能让你在不修改业务代码的前提下，优雅地织入限流逻辑；而Redis则能提供分布式环境下的原子性计数和状态存储，这对于微服务架构来说是必不可少的。
具体来说，我们可以定义一个自定义注解，比如@RateLimit，里面包含限流的策略参数，像每秒允许多少次请求、限流的维度（按用户ID、IP还是接口路径）。然后，通过AOP切面去拦截所有被这个注解标记的方法。在切面里，我们会根据注解的参数，向Redis发起请求，执行一个预先写好的Lua脚本。
为什么是Lua脚本？因为Redis执行Lua脚本是原子性的，这能完美解决分布式环境下并发请求导致计数不准确的问题。比如，实现一个令牌桶算法：每次请求过来，先去Redis里检查桶里是否有足够的令牌；有就取走令牌，放行请求；没有就拒绝。Lua脚本可以一次性完成“检查”和“取走”这两个操作，避免了中间状态被其他并发请求干扰。
// 假设这是你的自定义限流注解
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface RateLimit {
String key() default ""; // 限流的key，默认是方法名
int permitsPerSecond(); // 每秒允许的请求数
long timeout() default 0; // 获取令牌的等待时间，0表示不等待
TimeUnit timeUnit() default TimeUnit.SECONDS; // 时间单位
}
// AOP切面大致逻辑（伪代码）
@Aspect
@Component
public class RateLimitAspect {
@Autowired
private StringRedisTemplate redisTemplate;
// 假设这是你的Lua脚本，实现令牌桶逻辑
// KEYS[1] -> 限流的key
// ARGV[1] -> 桶容量 (permitsPerSecond)
// ARGV[2] -> 每次请求消耗的令牌数 (1)
// ARGV[3] -> 当前时间戳 (毫秒)
// ARGV[4] -> 桶的过期时间 (毫秒)
private static final String LUA_SCRIPT = """
local key = KEYS[1]
local capacity = tonumber(ARGV[1])
local requested = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local expire = tonumber(ARGV[4])
local last_fill_time = tonumber(redis.call('HGET', key, 'last_fill_time') or '0')
local tokens = tonumber(redis.call('HGET', key, 'tokens') or tostring(capacity))
local fill_interval = 1000 / capacity -- 填充一个令牌所需的时间 (毫秒)
if now > last_fill_time then
local time_passed = now - last_fill_time
local new_tokens = math.floor(time_passed / fill_interval)
tokens = math.min(capacity, tokens + new_tokens)
last_fill_time = now
end
if tokens >= requested then
redis.call('HSET', key, 'tokens', tokens - requested)
redis.call('HSET', key, 'last_fill_time', last_fill_time)
redis.call('EXPIRE', key, expire / 1000) -- 设置过期时间，避免key无限增长
return 1
else
return 0
end
""";
@Around("@annotation(rateLimit)")
public Object doRateLimit(ProceedingJoinPoint joinPoint, RateLimit rateLimit) throws Throwable {
String key = rateLimit.key().isEmpty() ? joinPoint.getSignature().getName() : rateLimit.key();
int permits = rateLimit.permitsPerSecond();
long timeout = rateLimit.timeout(); // 实际使用中可能需要更复杂的等待逻辑
// 实际的key可以加上IP、用户ID等上下文信息
String finalKey = "rate_limit:" + key;
DefaultRedisScript redisScript = new DefaultRedisScript<>(LUA_SCRIPT, Long.class);
// 执行Lua脚本
Long result = redisTemplate.execute(redisScript,
Collections.singletonList(finalKey),
String.valueOf(permits), // 桶容量
"1", // 每次请求消耗1个令牌
String.valueOf(System.currentTimeMillis()), // 当前时间
String.valueOf(rateLimit.timeUnit().toMillis(permits * 2)) // 桶数据过期时间，这里简单设为2倍的令牌填充周期
);
if (result == 0) {
// 被限流了，抛出异常或者返回特定错误码
throw new RuntimeException("访问频率过高，请稍后再试！");
}
return joinPoint.proceed();
}
} 这只是一个简化版的Lua脚本和AOP切面示例，实际生产环境可能需要更复杂的逻辑，比如区分不同的限流维度、更精细的过期策略、以及对异常的统一处理。但核心思路就是这样。
为什么API限流对微服务至关重要？
在微服务架构下，API限流的重要性简直不言而喻，甚至可以说它是构建健壮系统的基石之一。你想啊，一个大型系统被拆分成几十上百个微服务，服务之间互相调用，外部请求也可能直接打到某个服务上。如果没有限流，会发生什么？
我记得有一次，我们一个新上线的活动，因为没有做好限流，用户一拥而上，瞬间就把负责商品详情的微服务给打挂了。然后这个服务一挂，依赖它的其他服务也跟着出问题，最后整个系统都瘫痪了。这事儿给我留下了很深的印象。
所以，API限流首先是保障系统稳定性的最后一道防线。它能防止突发流量、恶意攻击（比如DDoS或暴力破解）导致服务过载崩溃。其次，它能实现资源的公平分配。你想，如果一个用户或客户端无限制地占用资源，那其他正常的请求可能就得不到响应。限流可以确保每个请求都能在一定程度上获得服务，避免“劣币驱逐良币”的情况。再者，对于一些有成本考量的外部API调用，限流也能控制成本，避免不必要的开销。最后，它也是一种安全策略，可以有效缓解一些常见的安全威胁，比如短时间内大量的登录尝试。
如何为你的Spring Boot应用选择合适的限流算法？
选择限流算法，这事儿没有银弹，得看你的具体业务场景和对流量控制的需求。我经常开玩笑说，这就像选车，轿车、SUV、跑车，各有各的用处。
固定窗口（Fixed Window）：最简单粗暴，比如每分钟100次。但它的问题是，在窗口边缘容易出现“双倍峰值”问题。比如00:59秒来了99个请求，01:00秒又来了99个请求，总共198个，但都合法。这种算法，如果你的业务对瞬时峰值不敏感，或者流量本身就很平稳，那用用也行。但说实话，我个人对它有点保留，除非是那种对实时性要求不高，且流量分布非常均匀的场景。
滑动窗口（Sliding Window）：这是固定窗口的升级版，它通过维护一个更细粒度的请求记录（比如10个小窗口），或者直接记录每个请求的时间戳，来解决固定窗口的边缘问题。它能更精确地控制单位时间内的请求数量，平滑度更好。对于大多数需要精确控制流量的应用来说，滑动窗口是个不错的选择。实现起来会稍微复杂一点，但效果也更好。
漏桶算法（Leaky Bucket）：这个算法的特点是“匀速出水”，无论进来的水流多大，它都以固定的速率往外漏。这就像一个有固定出水速率的桶，水满了就溢出（请求被拒绝）。它的优点是能强制输出流量保持一个恒定的速率，非常适合那些后端处理能力有限，需要平滑流量的场景，比如消息队列的消费者、或者需要稳定调用第三方API的场景。它能有效地削峰填谷，保证后端服务的稳定性。
令牌桶算法（Token Bucket）：这是我个人在实际项目中用得比较多的一个。它跟漏桶有点像，但更灵活。桶里会以固定的速率往里“放”令牌，请求来了，必须拿到令牌才能通过。如果桶里有足够的令牌，即使瞬间来了一波大流量，也能在桶容量范围内被处理（允许突发）。但如果令牌用完了，就得等。这种算法的优势在于，它在控制平均速率的同时，允许一定程度的突发流量，这对于很多用户交互型的API来说非常友好，因为它不会因为偶尔的瞬时高并发就直接拒绝所有请求。
选择的时候，你得问自己几个问题：我的服务是需要严格的匀速处理，还是允许一定的突发？我的业务对瞬时流量峰值有多敏感？我希望在限流时是直接拒绝，还是能稍微等待一下？想清楚这些，基本就能选出最适合你的算法了。
Spring Boot分布式限流的实践与常见挑战
当你的Spring Boot应用部署在多个实例上，或者采用微服务架构时，单机限流就显得力不从心了。这时候，分布式限流就成了必选项。前面提到的Redis + Lua脚本方案，就是分布式限流的典型实践。
在实践中，有几个点是需要特别注意的：
Key的粒度设计：限流的key非常关键。你是按IP限流？按用户ID限流？还是按接口路径限流？或者这三者的组合？比如，
rate_limit:ip:{ip_address}，rate_limit:user:{user_id}，rate_limit:api:{path}。设计不当可能导致限流效果不佳，或者误伤正常用户。我通常会根据业务需求，提供多维度的限流能力，并且允许动态配置。Lua脚本的健壮性与性能：虽然Lua脚本在Redis内部执行是原子性的，但脚本本身的逻辑要严谨，避免死循环或者过多的Redis操作导致性能问题。对于复杂的限流逻辑，我建议先在本地模拟测试，确保脚本的正确性和效率。另外，Lua脚本应该尽可能地把所有操作封装在一个
EVAL或EVALSHA调用中，减少网络往返。异常处理与用户体验：当请求被限流时，应该如何响应？直接抛出HTTP 429 Too Many Requests错误码？返回一个友好的提示信息？还是重定向到一个等待页面？这需要和产品、前端团队一起商量。我个人倾向于返回明确的错误码和简洁的提示信息，让调用方知道发生了什么。
动态配置与监控：限流参数（比如每秒允许的请求数）可能需要根据业务情况动态调整。集成配置中心（如Nacos、Apollo）可以实现热更新。同时，对限流效果的监控也非常重要，比如被限流的请求数量、限流的生效频率等，这些数据能帮助你评估限流策略是否合理，并进行优化。
集群环境下的Redis高可用：如果你的Redis是单点部署，那它就成了限流系统的单点故障。为了保障限流服务的持续可用性，Redis集群（如Redis Sentinel或Redis Cluster）是必须的。
实际操作中，可能会遇到一些“坑”，比如Redis连接池配置不当导致连接耗尽，或者Lua脚本写得不够严谨在并发下出现意外行为。这些都需要在开发和测试阶段充分考虑，并进行压力测试来验证限流策略的有效性。
