异步化是性能优化的万能药，还是最贵的一笔复杂度税？

先抛一个我 2021 年踩过的真实案例，再讲我的困惑，想听听大家的判断。

【背景案例】 某电商的"下单成功页"需要聚合 4 个下游：库存扣减、营销券核销、积分写入、物流预占。同步串行 P50 ≈ 210ms，P99 飙到 480ms（物流预占下游 P99 是 320ms）。团队第一反应是"上 MQ 异步化"：库存和营销券走事务消息，积分和物流走延迟投递，下单接口只做本地事务 + 发 3 条消息，P50 压到 45ms。看起来完美。

但三个月后出了两件事：

1. 营销券核销的 MQ 消费者在促销日积压了 12 万条，用户看到"下单成功"但券没核销，客诉炸了；
2. 排查一次"积分没到账"用了 4 小时，因为日志分散在 3 个服务、2 个 topic，traceId 在延迟投递后断了。

最终我们改回了"同步 + 超时降级"：库存和营销券同步调（P99 可控在 80ms 内），积分和物流异步（本来就是非关键路径）。P50 回到 95ms，但再也没有出现过"用户以为下单了但其实没成功"的资损类客诉。

【我观察到的三种常见做法】

• A. 能异步就异步：理由是"反正最终一致就行"，把整个链路拆成事件驱动，吞吐上去了，但调试成本、一致性窗口、补偿逻辑全上来了；
• B. 能同步就同步：理由是"同步最直观、最容易排查"，但 P99 被最慢的那个下游拖死，容量规划也保守；
• C. 按"用户感知"切分：用户必须等结果的（库存、支付）走同步，用户不感知的（积分、通知、埋点）走异步。

【我的倾向】 我倾向 C，但执行起来有一个很难量化的边界："用户感知"到底怎么定义？ 积分对用户来说是"感知"的吗？如果他在下单页看到"预计获得 200 积分"，那对他来说就是同步预期。但如果你把积分改成"3 秒后到账"，他大概率不会投诉。这个边界不是技术判断，是产品判断，而产品往往给不出精确答案。

还有一个我反复纠结的点：异步化之后，故障的"爆炸半径"变了。同步链路里，一个下游挂了，用户立刻看到报错，影响面 = 当前请求。异步链路里，一个消费者挂了，影响面 = 过去 N 小时所有未消费的消息，而且用户已经收到了成功响应，你只能靠补偿和告警兜底。这个"静默失败"的代价，在很多团队的容量规划里根本没被算进去。

【想听大家聊的】

1. 你们线上有没有"异步化之后反而更慢 / 更难排查"的案例？最终怎么收的？
2. 在"用户感知"这个边界上，你们是怎么和产品对齐的？有没有量化的方法（比如 NPS 数据、客诉率）来辅助判断"这个异步化用户到底买不买账"？
3. 异步化之后，你们的可观测性做了哪些额外投入？（我现在的做法是强制 traceId 透传 + 每个消费者有独立的成功/失败/延迟三组 metric，但总觉得还不够）
4. 有没有人试过"同步为主 + 异步补偿"的混合模式？具体怎么切分的？

我抛砖引玉了，期待看到不同场景下的取舍。