同步链路拆异步是「性能解药」还是「一致性债务」？聊聊该在哪个位置做这道分叉

背景

我做了 8 年数据工程，长期在数据管道和离线/近实时链路上做异步化改造。最近翻社区热榜，发现大家聊「怎么把 P99 打下来」已经聊得很透：连接池从 200 调到 2000 反而雪崩的复盘、Kafka 事务 initTransactions 偶发 8s 卡顿、CallerRunsPolicy 嵌套线程池把 P99 从 45ms 拉到 42s、幂等生产者 max.in.flight 被锁死在 5……这些帖子都在讲「异步链路内部怎么调参」。

但有一个更前置的问题，我很少看到被正面讨论——当你把一个同步链路拆成异步链路的那一刻，你实际上在做什么交易？

举个具体场景：用户下单接口要同步调风控（~80ms）+ 同步调库存扣减（~50ms）+ 同步写订单（~30ms），P99 已经到 200ms。团队第一反应通常是「把风控挪到异步，先落单」。听起来很合理，但实际踩坑的人都知道，这一步做完之后：

1. 用户「下单成功」的语义变了——从「风控通过 + 库存扣减完成」变成「订单已写入」，但用户并不知情；
2. 下游如果失败，你需要一套补偿/回滚链路，而这条链路的 P99 往往比原同步链路还难看（因为要处理重试、幂等、死信）；
3. 监控指标从「下单成功率」裂成「落单成功率」+「风控异步通过率」+「库存异步扣减成功率」三个，业务方开始质疑「到底哪个才是真的成功率」。

常见分歧 / 几种做法

我见过团队在这件事上有三种典型立场：

• 激进派：只要不是「强一致读」，全部异步化，用 Kafka/RocketMQ 串起来，同步接口只负责「受理」，一切结果走消息。优点是 P99 极好控（只测「受理」），缺点是下游一致性靠 MQ 兜底，一旦消费侧出问题，业务方看到的是「我的数据呢」。
• 保守派：只有「用户能立刻感知结果」的步骤才同步，其余全异步。判断标准是「用户关掉页面之后，这件事还成立吗」。优点是语义清晰，缺点是同步段经常卡在 3~5 个下游 RPC 上，P99 治理空间被压缩得很小。
• 混合派（也是大多数团队的现状）：核心路径同步，非核心路径异步，但「核心 vs 非核心」这个边界随业务迭代漂移——风控从非核心升到核心，营销券从核心降到非核心，每次漂移都要重新评估整条链路的 P99 和一致性。

我的倾向与理由

我个人的倾向是：在同步段里只保留「用户语义上必须立刻知道结果」的步骤，且同步段长度 ≤ 3 个下游调用。理由有三：

1. 从数据管道经验看，异步化最大的成本不在「写 MQ」，而在「消费侧的幂等、重试、死信、对账」——这四件事加起来的工作量，通常是同步链路改造的 2~3 倍。如果同步段本来就只有 2 个下游，拆异步反而不划算。
2. P99 抖动的根因分布里，「单点下游慢」占 60%+，「链路长度叠加」占 20%+，「线程池/连接池竞争」占 10%+。拆异步对第一类几乎无效（只是把慢从同步段挪到异步段），对第二类有效，对第三类无效。所以拆异步前，先确认瓶颈到底在哪一段，比「拆了再说」更省钱。
3. 监控裂变的成本经常被低估。一个同步接口的 SLO 是一条线，拆成 3 个异步段之后是 3 条线 + 1 条对账线，SRE 的告警规则、值班手册、故障定级全部要重写。这笔成本应该在拆之前算进 ROI。

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

抛几个具体场景，想听听各位的取舍：

1. 下单链路：风控同步 vs 异步，你的阈值是什么？（风控 RT P99 到多少你会坚持同步？超过多少你会拆？）
2. 支付回调：用户付完款，「支付成功」这个状态是同步写库返回，还是异步写？如果异步，用户看到「支付成功」但查不到订单，这个窗口你们怎么兜底？
3. 注册后发券：注册接口同步发券 vs 异步发券，业务方接受「发券延迟 3s」的边界在哪里？
4. 数据一致性要求：如果下游是「只读报表」，拆异步基本没争议；如果是「用户可写可查」的业务数据，拆异步的门槛是不是应该高一个数量级？
5. 反例征集：有没有谁拆异步之后，反而发现 P99 没降、一致性债务翻倍，最后又拆回来的？这种「拆了又拆回去」的 case 特别想听听，因为这种决策的成本最高，但社区里几乎没人写。

欢迎从「你们团队的判断标准」「踩过的坑」「拆回去的经历」三个角度聊。我会跟帖补充自己数据管道侧的几条经验（比如「异步段的幂等键设计，决定了你将来能不能回滚」）。