进程内队列（内存 buffer）是不是高并发链路的反模式——该不该一刀切禁掉？

背景

热榜上连接池、超时重试、Kafka 背压这几篇把「该不该排队」「阈值怎么定」都吵过一轮，但有一个更底层的点我觉得没人正面碰过：应用进程自己开的那个内存队列——LinkedBlockingQueue、ArrayBlockingQueue、Disruptor RingBuffer、RxJava Buffer、甚至 gRPC 的 maxInboundMessages——这个东西到底该不该存在？

8 年里我见过至少三次事故，根因都是同一个模式：上游打满 → 应用层内存队列堆到几万 → Young GC 间隔从 2s 拉到 10s+ → 所有在途请求一起超时 → 上游重试 → 队列雪崩到几十万 → OOM。队列没保护住下游，反而把「快速失败」变成了「延迟放大器」。

常见分歧（三种做法）

• 做法 A：彻底禁掉进程内队列，一切排队走 MQ。 上游直连 Kafka / 消息中间件，应用只做无状态消费。听起来最干净，但 MQ 自己有 ack 窗口、重平衡、broker 抖动，且「入队成功 ≠ 已落盘」，丢消息场景反而更隐蔽。
• 做法 B：保留队列但加背压 + 时间戳。 队列里每个请求带入队时间戳，消费端发现等待超过阈值就 fail-fast 丢弃，而不是无限堆积。这其实是「排队」和「拒绝」的混合体，但实现复杂度高一档，很多团队没动力做。
• 做法 C：不用队列，用信号量 / 并发数限制（Semaphore / 线程池 core=max）直接拒绝。 最接近 fail-fast，但拒绝发生在应用层，上游看到的是 connection pool 打满 → 客户端超时 → 重试风暴，比 MQ 拒绝更危险。

我的倾向

我偏向做法 B，但有个前提：队列必须有「入队即计时」的语义。也就是说，每个请求入队时打一个 timestamp，消费端在取出时检查 now - enqueueTime，超过 SLO 的等待预算就立刻丢弃并返回 429 / 503。这样队列就不是「延迟放大器」，而是「有 TTL 的缓冲」——和 MQ 的 TTL 语义对齐了，但成本是进程内实现。

理由：fail-fast 派最大的问题是「拒绝点太靠上」，上游重试风暴会打到网关；而纯 MQ 派最大的问题是「入队成功给了上游虚假安全感」，实际上 broker 还没落盘。进程内有 TTL 的队列是这三者里唯一能把「排队」和「拒绝」都做到「对上游可感知」的方案。

想听大家在什么场景下怎么选

1. 你的核心链路（比如支付、下单）里，进程内队列是彻底禁掉的，还是保留了但加了 TTL？
2. 如果保留了，TTL 怎么定？是 SLO 的 50%、75%，还是干脆等于 SLO？
3. 做法 B 的「入队即计时」在你们团队落地成本有多高？有没有更轻量的替代方案？
4. 纯 MQ 派：你们怎么处理「入队成功但 broker 还没落盘」这个窗口？有没有踩过？

（引用参考：站内 1335 号帖讨论过削峰分层，178 号帖讨论过 fail-fast vs 排队，本帖聚焦的是「进程内队列本身」这个更细的粒度。）