自定义拒绝策略实现精准反向限流，核心是将拒绝转化为可感知、可调控、可回溯的流量反馈信号，驱动上游主动降速，避免堆积与雪崩；需注入topic/partition等业务语义，按分区动态限流，配合调度器、巡检线程与可观测埋点形成闭环。
在自研 mq 客户端的拉取线程池中，用自定义拒绝策略实现精准反向限流，核心不是“拒绝任务”，而是把拒绝动作变成一种可感知、可调控、可回溯的流量反馈信号。它让上游生产者（比如消息发送方或业务入口）能真实感知下游消费能力瓶颈，并主动降速，从而避免堆积、oom 或雪崩。
理解“反向限流”的本质
普通限流控制的是入口请求速率（如 Sentinel、RateLimiter），而反向限流是消费侧向上游“喊停”：当拉取线程池持续触发拒绝策略，说明当前消费吞吐已达极限。此时拒绝策略不应静默丢弃或简单重试，而应：
- 记录被拒任务的原始消息批次、主题、分区、时间戳等上下文
- 触发本地限流器（如 Guava RateLimiter 或滑动窗口计数器）对对应 topic/partition 的拉取频率做动态下调
- 通过心跳或元数据通道，将“消费滞后信号”上报至协调服务，供集群级调度参考
拒绝策略需携带业务语义
标准 RejectedExecutionHandler 接口只传入 Runnable 和 ThreadPoolExecutor，但自研 MQ 拉取任务通常是封装了 FetchRequest 或 PollTask 的对象。建议在提交任务前，将关键限流维度注入 Runnable：
- 所属 topic 和 partition 编号
- 本次拉取期望的 maxBytes / maxRecords
- 当前客户端 lag 值（从 offset commit 状态推算）
这样，自定义拒绝策略就能按 partition 精准降频，而不是全局锁死整个拉取线程池。
策略实现要点：拒绝即信号，非失败
不要在拒绝策略里做耗时操作（如发 HTTP、写磁盘、同步调 MQ）。推荐结构：
- 原子更新对应 partition 的“拒绝计数器”（如
ConcurrentHashMap<TopicPartition, LongAdder>） - 检查该 partition 近 10 秒拒绝次数是否超阈值（如 ≥3 次），是则触发本地限流器
setRate(0.5 * currentRate) - 记录一条轻量日志（含 partition、拒绝原因、当前队列长度、活跃线程数），级别为 WARN
- 不抛异常、不阻塞、不重试 —— 让上层拉取循环自然等待下一轮 poll
配套机制才能闭环
仅靠拒绝策略无法完成反向限流闭环。还需：
- 拉取调度器配合：每次 poll 前查本地限流器，若被限速，则跳过该 partition 或降低 fetchSize
- 后台健康巡检线程：定期扫描各 partition 的拒绝计数器，连续无拒绝则缓慢恢复速率（如每 30 秒 +10%）
-
可观测性埋点：将拒绝事件打点到 metrics（如
mq.client.fetch_rejected_count{topic="",partition=""}），接入告警
不复杂但容易忽略
