Java限流实现：Guava令牌桶算法详解

RateLimiter.create() 的 permitsPerSecond 参数表示令牌生成速率而非每秒放行请求数，需结合真实QPS乘2～3倍设初始值，并显式指定maxBurstSeconds以提升突发容忍能力。

RateLimiter.create() 的参数到底填多少才合理

限流效果差，要么是压根没生效，要么是拦得太狠——根源常出在 create() 的 permitsPerSecond 参数上。它不是“每秒最多放行几个请求”，而是“令牌生成速率”，实际能扛住的并发峰值可能远高于这个值（因为桶有容量），但长期平均不会超过它。

常见错误是直接按 QPS 估算填 100，结果突发流量一来就全放过；或者填太小（比如 1），连健康检查都卡住。

• 先看真实入口流量：用 Nginx 日志或网关监控查 5 分钟内平均 QPS，再乘 2～3 倍作为初始值（留缓冲）
• 桶容量默认是 1，想抗突发得显式指定：RateLimiter.create(100, 10, TimeUnit.SECONDS) 表示每秒生成 100 个令牌，桶最多存 10 个（注意：第二个参数是 maxBurstSeconds，不是容量数字）
• Spring Boot 中注入时别写死数值，用 @Value("${rate.limit.qps:50}") 外部配置，上线后可热调

拦截逻辑放在 Controller 还是 Filter？

放在 @RestController 方法里最简单，但容易漏——比如静态资源、Actuator 端点、Swagger UI 都绕过 Controller。真正起作用的位置是 Filter 或 Spring WebMvc 的 HandlerInterceptor。

Filter 更底层，能覆盖所有 HTTP 请求；Interceptor 更轻量，但对 WebFlux 无效，且不拦截静态资源（除非关掉 spring.web.resources.add-mappings=false）。

• 推荐用 OncePerRequestFilter 实现，避免异步请求重复触发
• 注意区分路径：别对 /actuator/health 或 /swagger-ui/ 限流，否则运维排查困难
• 限流失败时返回 429 Too Many Requests，别用 500 或重定向，前端才好统一处理

RateLimiter.acquire() 和 tryAcquire() 怎么选

acquire() 会阻塞等待令牌，等不到就一直挂起线程——在 Web 容器里等于浪费一个 Tomcat 线程，高并发下可能拖垮整个服务。而 tryAcquire() 是非阻塞的，立刻返回 true/false，适合做快速拒绝。

绝大多数 Web 场景该用 tryAcquire()，除非你明确需要“削峰填谷”式平滑处理（比如后台任务队列）。

• 用 tryAcquire() 时，可传超时参数：tryAcquire(1, 100, TimeUnit.MILLISECONDS)，表示最多等 100ms
• 别在循环里反复调 acquire()，Guava 不保证线程安全的重入，可能引发 IllegalStateException
• 如果业务允许微小延迟（比如搜索建议），可用 acquire(1)，但必须配线程池隔离，防止拖累主线程池

单机限流在集群环境下为什么失效

RateLimiter 是纯内存对象，每个实例独立维护桶状态。三台机器部署，create(100) 就等于总容量 300 QPS，根本达不到预期限流效果。

这不是 Guava 的 bug，而是设计使然——它定位就是单机轻量限流。要跨节点一致限流，必须引入外部存储。

• 短期方案：用 Redis + Lua 脚本实现分布式令牌桶（redis.eval 保证原子性），但要注意网络 RTT 影响吞吐
• 别用 Redis 的 INCR + 过期时间模拟，无法精确控制令牌生成节奏，burst 行为不可控
• Spring Cloud Gateway 内置的 redis-rate-limiter 是更稳妥的选择，配置即用，背后就是 Lua 脚本

真正难的不是写对一行 RateLimiter.create()，而是搞清你的流量模型、部署拓扑和失败容忍边界。漏掉任意一环，限流就变成幻觉。