异步化到底是万金药还是遮羞布？聊聊什么时候该拆 MQ，什么时候该老老实实同步

背景

社区里聊连接池、聊超时重试、聊 Kafka 幂等都已经聊得很透了，但我发现还有一个更前置、也更容易翻车的问题没人正面聊过：一个业务操作里，哪些步骤该同步走完、哪些该扔进 MQ / 线程池异步掉？

我做了 10 年数据工程，见过太多"为了性能"把链路全异步化的案例，最后演变成：用户下单返回 200，后台 3 分钟才真正扣库存；客服查单说"系统显示成功"，财务对账说"账上没这笔"；线上排障时，一次请求要横跨 5 个 topic、3 套幂等表才能拼出完整链路。反过来也见过另一种极端——所有操作同步串行，主链路 P99 被最慢的那个下游拖到 800ms，用户体感灾难。

常见分歧（我观察到的三种流派）

1. "能异步就异步"派：主接口只负责"受理"，下游全部 MQ 化，追求 P99 漂亮。代价是最终一致性、幂等、补偿、可观测都要额外建一套。
2. "主链路必须同步闭环"派：只有"通知类、统计类"才允许异步，凡是影响用户决策的动作（扣款、扣库存、改状态）必须同步拿到结果。代价是主链路长，任何一个下游抖都会拖垮整体。
3. "按业务语义切"派：把操作按"用户是否强感知"、"是否可逆"、"是否影响一致性"三个维度打分，再决定同步/异步。代价是需要团队对业务语义有共识，且很难沉淀成通用规则。

我的倾向与理由

我倾向第 3 种，但会再加两条硬约束：

• 凡是"用户拿到结果后不能再撤销"的动作，必须同步闭环（扣款、改合同状态、发券）。异步只适合"通知、审计、统计、衍生计算"。
• 异步必须有"同步降级通道"：MQ 挂了、消费积压超阈值时，要么回落到同步（如果业务允许），要么明确告诉用户"已受理，处理中"，而不是假装成功。

理由：P99 漂亮但用户看到"假成功"，比 P99 慢 300ms 但结果可信，代价高一个数量级。可观测性和补偿机制的建设成本，往往被"拆 MQ"那一刻低估了 10 倍。

想听大家怎么选

想请走过来的同学在帖子里聊几个具体场景，我特别关心：

1. 下单链路：扣库存 + 扣款 + 发券 + 写审计，你们团队各自是同步还是异步？边界画在哪一步？
2. 支付回调：支付网关回调你的服务，你是同步处理完再 ACK，还是先 ACK 再异步处理？怎么保证不重复、不丢失？
3. 数据同步：业务库 → 数仓 / 搜索 / 推荐，这类"衍生消费"你们用 binlog 订阅、MQ 双写、还是应用层双发？踩过什么坑？
4. 异步降级：MQ 挂了你怎么办？有没有真的做过"异步回落到同步"的方案，代价是什么？

欢迎把你们的取舍、踩坑、数字（QPS、P99、积压时长）贴出来，越具体越好。空谈"要幂等"没意义，聊一下你们幂等表怎么建、去重窗口开多大、key 用什么才是真讨论。