消息驱动链路里「反压」到底该在哪一层做：消费者自限流、broker 侧背压、还是让下游自己扛？

【背景】

做了 5 年全栈，最近半年一直在啃一条消息驱动的核心链路：上游订单事件 → Kafka（3 broker，KRaft，12 partition）→ 消费者（Java，Spring Boot 3.2）→ 下游 3 个 RPC 服务（物流、风控、对账）。

去年 Q3 出过一次典型事故：上游批量补单（一次 8 万条事件涌入），消费者 8 个实例全打满，下游物流 API 的 P99 从 80ms 飙到 2.3s，触发熔断，熔断期间 Kafka consumer lag 从 2000 涨到 47 万。事后复盘时发现一个尴尬的事实：链路里没有任何一层在"主动拒绝"或"减速"，所有层都在"硬扛"，最后扛不住的是最脆弱的那层（下游物流 API）。

从那以后我一直在想一个问题：反压（backpressure）到底应该在哪一层做？

【常见分歧 / 三种做法】

我见过三种典型思路，团队里经常吵：

做法 A：消费者自限流（pause/resume / 信号量）

• Kafka consumer 用 pause(partition) / resume(partition) 控制拉取节奏
• 或者在消费者内部用 Semaphore 限制并发处理数
• 优点：不依赖 broker 配置，逻辑可控
• 缺点：lag 会涨（消息还在 broker 里堆着），上游看不到压力信号，broker 存储压力转移到了消费端

做法 B：broker 侧背压（调 fetch 参数 / 调 partition 数）

• Kafka：调小 fetch.min.bytes、max.poll.records，让 consumer 少拉
• RabbitMQ：调 prefetch_count，让 broker 不推
• 优点：从源头减少"在途"消息量
• 缺点：Kafka 的 consumer group rebalance 机制让"调 fetch 参数"很脆弱——一个 consumer 慢了，整个 group 的 lag 统计就失真了；而且 partition 数固定，扩不出去

做法 C：让下游自己扛（队列缓冲 + 降级）

• 消费者不管，把消息全部拉出来，在内存队列里缓冲，下游慢就排队
• 极端情况：下游不可用时，消息落本地磁盘队列，等下游恢复后重放
• 优点：消费者逻辑最简单
• 缺点：内存队列是"假反压"——队列满了 OOM，或者下游永远不恢复，消息就永远堆着

这三种做法，没有一种是"对的"，只有"在你那个场景下代价最小"。 但我发现大多数团队没有认真比较过代价，而是"抄了一个参数就上线了"。

【我的倾向与理由】

我的倾向是：在消费者侧做"软反压"，在下游侧做"硬熔断"，broker 侧只调"拉取粒度"不做"背压"。

具体做法（可复现）：

1. 消费者侧（软反压）：

   • 用 max.poll.records = 50（不是默认的 500），每次 poll 拿 50 条
   • 处理完 50 条后，检查下游 RPC 的滑动窗口 P99（最近 100 次调用的 P99）
   • 如果 P99 > 500ms，Thread.sleep(100) 再 poll（不是 pause，pause 后 resume 的 lag 统计会跳变）
   • 如果 P99 > 2s，直接 pause(partition)，等 P99 回落到 200ms 以下再 resume
   • 这个逻辑本质是"用下游的延迟信号驱动自己的拉取节奏"，而不是"用消息量驱动"

2. 下游侧（硬熔断）：

   • 物流 API：超时 800ms，熔断阈值 50%（10s 窗口），熔断后直接写本地 DLQ（dead letter queue，用 RocksDB 落盘，不是内存）
   • 风控 API：超时 300ms，熔断后走默认放行（业务可接受）
   • 对账 API：超时 5s，不熔断（对账是幂等的，可以慢慢重试）

3. broker 侧：

   • max.poll.records = 50（配合消费者侧逻辑）
   • session.timeout.ms = 45000（默认 10s 太短，软反压 sleep 期间容易触发 rebalance）
   • 不调 fetch.min.bytes（Kafka 的 fetch 机制是 push 式的，调小反而增加网络往返）

这个方案的核心假设是：反压信号应该从"最脆弱的那层"（下游 RPC）向上游传播，而不是从 broker 向下压。 这和 Reactive Streams 的 request(n) 模型一致，但在 Kafka 这种"拉取式"架构里，需要消费者主动把这个信号"翻译"成拉取节奏。

【想听大家怎么选】

几个具体问题想听听不同场景下的选择：

1. 你的链路里，反压信号是从哪一层发出的？ 是下游 RPC 的延迟？是消费者内存占用？还是 broker 的 lag？
2. Kafka consumer 的 pause/resume 你有没有实际用过？ 我见过一个坑：pause 期间如果发生了 rebalance，resume 的 partition 可能已经不是原来那个了，lag 统计会跳变。你们怎么处理的？
3. 下游不可用时，消息落盘重放 vs 直接丢弃告警——你的业务容忍哪种？（对账场景我选落盘，实时风控场景我选丢弃，但这两个判断的依据是什么？）
4. 有没有人试过在 broker 侧做"动态背压"？ 比如根据 consumer lag 自动调 fetch 参数？我查过 Kafka 源码，KafkaConsumer.poll() 的 fetch 逻辑里没有这个 hook，但社区有没有 plugin 或 sidecar 方案？
5. 你团队里对"反压"有共识吗？ 还是说每次出事故都是"临时加个 sleep"？

我不预设标准答案。想看看不同业务场景（金融 / 电商 / 日志管道 / IoT）下，大家是怎么权衡"消息不丢"和"下游不被打爆"这两个目标的。