背景
社区里关于 MQ 的讨论大多默认了一个前提——这条链路已经决定要异步化了，然后才去争 Outbox 谁负责、幂等表怎么设计、顺序/重试怎么保（#589、#474）。但我在三个项目里反复撞到的是更前置的一个问题：
这条链路，到底该不该上 MQ？还是同步 RPC + 重试就够？或者一张数据库表 + 一个 worker 扫描就够？
我自己的经历：
- 项目 A（2 人团队，日活 2000）：上线第一天就搭了 Kafka（3 broker KRaft），结果 80% 的 topic 每天不到 100 条消息。运维成本（磁盘监控、broker 升级、consumer lag 告警）占了一个人 30% 的时间。
- 项目 B（5 人团队，QPS 峰值 500）：没上 MQ，用本地消息表 + 每 2 秒扫表投递，跑了 8 个月零事故。直到某天下游从 1 个变 4 个，扫表逻辑开始互相干扰，才被迫迁移到 Kafka——迁移花了 3 周。
- 项目 C（3 人团队，QPS 峰值 20）：同步 RPC 调下游，超时 3 次重试，简单粗暴。但某天下游一个慢查询把整条链路拖到 P99 2s，才意识到"同步耦合"才是真正的风险。
常见分歧 / 几种做法
做法 1：QPS 驱动 "超过 1000 QPS 就得上 MQ"——但 QPS 高不等于需要异步。一个 5000 QPS 的只读查询链路，同步 RPC 跑得好好的。
做法 2：下游数量驱动 "下游超过 2 个就得上 MQ"——但下游多也可能是 fan-out 的问题，不一定需要 MQ，事件总线（进程内）或数据库触发器也能解决。
做法 3：团队规模驱动 "团队超过 5 人就需要 MQ 做解耦"——但小团队用 MQ 的运维成本反而更高（没人熟悉 broker 运维，出事全靠文档）。
做法 4：风险驱动（我的倾向） 不看 QPS、不看下游数量，只看一件事：下游慢了，会不会把上游拖死？
- 会 → 需要异步（MQ 或本地队列都行）
- 不会 → 同步 RPC + 超时 + 重试就够了
我的倾向与理由
我现在的判断标准是一个三问 checklist，按顺序问：
-
下游 P99 > 上游能容忍的超时时间吗？ 是 → 必须异步（否则同步调用会阻塞上游线程池） 否 → 继续问第 2 个
-
下游失败后，上游能不能"等一会儿再试"？ 能（业务允许最终一致）→ 本地消息表 + worker 就够，不需要 MQ 不能（必须实时知道结果）→ 同步 RPC，不要假装异步
-
下游数量 > 1，且各下游处理速度差异大吗？ 是（一个下游 10ms 处理完，另一个 2s）→ 需要 MQ 做缓冲，让快的不被慢的拖 否 → 本地 worker 或事件总线足够
核心判断：MQ 解决的是"生产者速率 ≠ 消费者速率"的缓冲问题，不是"要不要解耦"的问题。 解耦可以用同步 RPC + 超时实现，缓冲才是 MQ 不可替代的价值。
想听大家
- 你们团队的触发线是什么？是 QPS、下游数量、团队人数，还是别的什么？
- 有没有"上了 MQ 之后发现根本不需要"或"没上 MQ 差点出事故"的具体案例？
- 2 人团队和 20 人团队，这个决策的 tradeoff 会有什么本质区别？
- 你们怎么判断"本地消息表 + worker"什么时候该升级到 MQ？有没有一个可量化的信号（比如 worker 延迟 > X 秒、消息积压 > N 条）？