一、先把痛点说清楚

我们做了一个 IM 推送服务。上游各种营销/通知/异步任务都往里塞消息，下游对接一家三方 IM 提供商。三方 IM 卖账号给我们的时候，合同里写了一行：单账号 QPS 配额。

业务侧看到这行时往往有两种反应：

• “QPS？我业务峰值还达不到”
• “QPS？那我加个限流器就行了”

我们当时是后一种。某天线上高峰瞬时调用打到 + QPS，三方直接 ban 了几个使用者的消息。复盘会上 PM 当着大家面问了一句很有杀伤力的话：

这就是大家都在问的问题——限流命中后到底该怎么办？话说回来，

二、三种姿势各自适配场景一览表

姿势	优点	缺点 / 典型不适用场景
直接丢	实现最简单。毫无资源使用情况，适合可容忍丢失的事件。	无法满足使用者体验要求；IM 推送、订单状态变更等业务不可选。不过，
阻塞等待	保证最终一定能发送；对后台任务友好，	说到线程资源稀缺，短暂阻塞即可占满整个线程池。 HTTP 请求超时：前端 30s 超时可能在服务器端已阻塞超过预期。 从雪崩风险来看，一波批量唤醒导致 触发限流。
延迟重投削峰	不占线程，只在异步方法重试。 可以把瞬时高峰摊平到可接受区间，实现真正削峰填谷。	需要精心设计退避窗口和随机抖动，否则会产生惊群效应。 必须限制最大重试次数，否则可能永远卡在延迟队列里。

直接丢 - 为何通常不合适?

The simplest approach:

if ) {
log.warn;return，}
doSend;

适用场景：

"不适用场景": 使用者可感知的业务消息—IM 推送、订单状态变更、支付结果通知等，一条消息丢失就代表着一次完整使用者体验损失。PM 拍桌子完全合理，我们的实际业务属于此类，方案一排除。

阻塞等待 - 哪些情况不能这么做?

rateLimiter.acquire;话说回来，// 阻塞直到拿到令牌
doSend;

# 场景分析:

- 阻塞几秒会让有限数量线程被挂起，从而导致正常请求堆积。
- 如果入口是 HTTP 接口。则前端可能因超时报错而未收到任何响应，即使最终成功发送也毫无意义。
- 一旦出现大量并发阻塞。当程序恢复后所有线程同时被唤醒，触发限流形成振荡循环。

# 实际案例:

- 使用者池只有几十个线程，一旦大部分被挂起就无法继续消费新消息。

MQ 使用者池这一场景也排除。

延迟重投 - 为什么选择它?

if ) {
retrier.retry;// 入延迟队列几秒后
尝试
return;}
doSend，

# 主要思路:

• 把瞬时高峰摊平为可接受速率，实现削峰填谷；即使下游配额是固定 QPS，也能按需分配时间窗口内平均发出。
• 不占用线程，仅通过异步延迟队列完成重试；避免后台任务或使用者池被堵住。

# 四大细节:

1. **延迟窗口**：太短易撞墙，太长使用者体验差。
2. **最大重试次数**：防止无限循环导致队列膨胀。
3. **随机抖动**：消除惊群效应，让回传请求均匀散布在窗口内。
4. **异常降级**：若限流器挂掉也要保证业务继续执行，而不是让它成为单点故障。

下面给出完整落地方案。

三、落地方案细节拆解

全局令牌桶——Redisson RRateLimiter

BUTS 集群多个实例同时向同一个第三方发消息。本地令牌桶毫无意义——每个实例都有自己的 QPS，却相加仍可能超过外部配额。必须使用全局分布式令牌桶。

`RRateLimiter` 内部使用 Redis + Lua 实现原子计数，可支持集群安全配置：

RRateLimiter limiter = redissonClient.getRateLimiter;limiter.trySetRate;// 留一点余量给运营手动调节
boolean ok = limiter.tryAcquire;

# 工程细节：

 

`OVERALL` 而非 `PER_CLIENT` ：共用一个桶，而不是每个实例自己维护一份！

`配额留余量` ：合同写的是 “不配”。但实际滑窗往往允许瞬间突刺，需要留一些安全余量防止突然爆表导致 ban。

`桶 key 按资源分组` ：单聊接口一个桶 `single_msg`，群发接口另一个 `batch_msg`。因为不同接口通常各自独立配额，否则互相抢占额度导致误判。

命中后入延迟队列——RocketMQ 延迟消息

---