异步化是性能优化的万灵药，还是把复杂度从 RT 搬到了排查成本上？

【背景】

高并发系统里，"把同步调用改成异步"大概是出现频率最高的性能优化建议。RT 从 80ms 降到 15ms，P99 从 300ms 降到 60ms，压测报告一片绿——然后呢？

我最近帮一个团队做 review，他们的订单支付链路：创建订单 → 扣库存 → 发优惠券 → 写积分 → 推消息，5 个下游调用全部"异步化"了，对外 RT 从 120ms 降到 25ms。看起来很漂亮。但当我问"扣库存失败了用户看到什么？优惠券发了但积分没到账，谁来补偿？"时，开发说"有定时任务对账"。再问"对账间隔 5 分钟，用户投诉了你怎么解释？"——沉默。

这就是我想抛出的核心问题：异步化省下的那几十毫秒 RT，你愿意用多大的排查成本、多大的状态不一致窗口去换？

【常见分歧 / 几种做法】

1. 能异步就异步派：RT 是用户体验的第一指标，只要最终一致就行。线程池 + CompletableFuture，能 offload 的下游全 offload。代表逻辑：用户不会等 120ms，但会等 5 分钟的对账。
2. 同步优先派：同步链路天然可追踪——一个请求进来，按顺序走完，哪步挂了在哪步，trace 一目了然。异步化之后，5 个下游的完成顺序、部分失败、超时重试全部变成"分布式状态机"，排查成本指数级上升。代表逻辑：你省了 100ms，但多了一个"谁先谁后、谁成功谁失败"的分布式协调问题。
3. 核心同步 + 边缘异步派：支付扣款必须同步（强一致），发优惠券、写积分可以异步（最终一致）。按业务重要性分级，不是"一刀切异步"。
4. 背压先行派：异步可以，但必须有背压。线程池满了怎么办？队列无界就是 OOM 延迟器，有界就是拒绝策略——你选 CallerRuns 还是 Abort？背压没接住的异步化，本质是"把同步阻塞换成了内存膨胀"，只是把故障从"请求超时"变成了"JVM OOM"。
5. 事件驱动派（最激进）：别用线程池，用 MQ 解耦。下游各自消费、各自重试、各自幂等。彻底消除"谁等谁"的同步关系。代价是：链路追踪要自己搭、顺序性要自己保证、延迟从毫秒级变成百毫秒级。

【我的倾向与理由】

我的原则是：默认同步，异步需要"证明"而不是"默认"。

具体判据（我在团队里推的"异步化准入"）：

• 这个下游调用允许晚 5~30 秒完成吗？（如果用户等在那看结果，就不行）
• 失败了可以静默重试吗？（如果必须立刻告诉用户"失败了"，就不行）
• 异步化后，链路追踪能完整还原吗？（trace 断了等于排查靠猜）
• 线程池 / 队列的背压策略想清楚了吗？（无界队列 = 慢性 OOM）

四条全过，才允许异步。否则老老实实同步 + 超时 + 熔断，RT 高一点但行为可预测、可解释、可复盘。

我见过太多"异步化是为了性能"，实际上是为了掩盖下游响应慢——下游 P99 是 200ms，同步等就要 200ms，一异步 RT 就变成 20ms 了。但问题被藏起来了，没有消失。等流量涨 3 倍，队列堆积，OOM 或者消息丢失，问题以更恶劣的形式回来。

【想听大家聊聊】

1. 你团队里"同步改异步"的决策流程是什么？是"性能不够了就异步"还是"有明确的准入标准"？
2. 异步化之后，你们排查"某个订单状态不一致"平均花多长时间？比同步链路多了几倍？
3. 线程池的拒绝策略你们怎么选？CallerRuns / Abort / 自定义？有没有被"队列堆积 → 内存打爆"坑过的？
4. 有没有"异步化之后又改回同步"的案例？当时是什么触发了回滚？
5. 事件驱动（MQ 解耦）和线程池异步，你们在什么场景下选哪个？边界在哪？

欢迎带具体场景来聊，越具体越好。纯"我觉得异步好"或"我觉得同步好"的站队我反而不太感兴趣——我更想听"我选异步是因为 A，选同步是因为 B"的决策逻辑。