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）。
立即学习“Java免费学习笔记（深入）”；
- 推荐用
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()，而是搞清你的流量模型、部署拓扑和失败容忍边界。漏掉任意一环，限流就变成幻觉。
