RateLimiter.create() 参数需依据第三方API的SLA设定，非简单换算每秒请求数；应结合预热、动态调速与分布式协调，避免单机限流失效或突发打满。
RateLimiter.create() 的参数到底怎么设才不翻车
对第三方 API 做流控，不能拍脑袋填 permitsPerSecond。它不是“每秒最多调几次”，而是“长期平均速率”，实际允许突发（比如 1 秒内连发 5 次），但后续会自动拉长间隔来摊平。如果你填 10，RateLimiter 默认用 SmoothBursty，桶容量是 permitsPerSecond × 1（即最多积压 10 个令牌），这在下游 API 突然抖动时极易触发限流失败。
实操建议：
- 先查清第三方 API 的 SLA —— 特别是「每分钟最大请求数」和「是否允许短时突发」，再换算成每秒均值。例如 600 次/分钟 → 基础值设为 10，但别直接用
RateLimiter.create(10) - 改用带预热的构造：
RateLimiter.create(10, 30, TimeUnit.SECONDS)，这样前 30 秒会从 3 QPS 渐进升到 10 QPS，避免刚启动就打满对方限流阈值 - 如果对方明确要求「严格匀速」（如某些银行接口），强制用
SmoothWarmingUp并把warmupPeriod设得很小（如 100ms），效果接近漏桶
tryAcquire() 和 acquire() 在调用第三方 API 时怎么选
关键区别在于阻塞行为：acquire() 会主动 sleep 等待令牌，tryAcquire() 立即返回布尔值。对第三方 API 调用，除非你明确接受线程挂起几十毫秒，否则必须用 tryAcquire() + fallback 逻辑。
常见错误现象：用 acquire() 后发现 HTTP 调用整体耗时暴涨，其实是 RateLimiter 在内部 sleep，而你的超时配置（如 OkHttp 的 connectTimeout）根本没生效。
实操建议：
- 永远优先
rateLimiter.tryAcquire(1)，失败时立刻走降级路径（如返回缓存、抛自定义异常、记录告警） - 如果必须等，用带超时的
tryAcquire(1, 100, TimeUnit.MILLISECONDS)，避免被 RateLimiter 单方面拖死整个请求链路 - 注意：不要在循环里反复调
tryAcquire()碰运气，这会放大瞬时压力；应结合退避策略（如指数退避重试）
多实例部署时 RateLimiter 为什么突然失效
Guava 的 RateLimiter 是纯内存单机实现，不跨 JVM。K8s 里扩出 5 个 Pod，每个都创建自己的 RateLimiter，那实际总流量就是 5 倍限流阈值 —— 这是线上最常被忽略的坑。
使用场景：你给某支付网关设了 20 QPS 限流，测试环境单实例跑着好好的，上线后监控显示对方返回大量 429，一查才发现集群实际打出 100+ QPS。
实操建议：
- 确认是否真需要分布式限流：如果第三方 API 自身有全局配额（如按 client_id 限流），那单机 RateLimiter 就够用；否则必须切 Redis + Lua 方案
- 若坚持用 Guava，至少做两件事：1）所有实例共用同一份配置中心下发的
permitsPerSecond；2）加监控埋点，实时上报各实例的rateLimiter.getRate()和storedPermits，对比看是否严重偏离 - 别信“我们流量不大所以不用管”—— 流量毛刺往往出现在凌晨低峰期（如定时任务集中触发），此时单机限流器更容易被击穿
如何让 RateLimiter 对不同 API 端点动态调整速率
硬编码 RateLimiter.create(5) 无法应对第三方 API 的策略变更（比如对方突然收紧 /v1/pay 接口，但放宽 /v1/query）。你需要运行时可调的实例池，而不是全局静态对象。
性能影响：每次 new 一个 RateLimiter 开销极小（内部只是几个 double 和 long 字段），但频繁重建会导致 GC 压力和状态丢失（如预热进度归零）。
实操建议：
- 用 ConcurrentHashMap 缓存不同 endpoint 的 RateLimiter 实例：
cache.computeIfAbsent("/v1/pay", k -> RateLimiter.create(5, 10, SECONDS)) - 配合配置中心监听，当收到新配额时，不直接替换实例，而是调用
setRate(newRate)—— 它会平滑过渡，不会清空当前 storedPermits - 避免为每个用户 ID 或订单号单独建 RateLimiter（内存爆炸），按业务维度聚合，比如按「API 路径 + HTTP 方法 + 关键 Header（如 x-api-tier）」组合 key
真正难的从来不是写对一行 RateLimiter.create()，而是搞清第三方 API 的真实限流边界在哪——它的文档写的 100 QPS，到底是 per IP、per API Key，还是 per 请求路径？漏掉这一层，再精准的令牌桶也救不了你。
