异步化

【背景】 最近复盘了几次线上 P99 抖动，根因高度雷同：某个原本"同步直调下游"的接口，在下游一次 GC 或慢查询时，把上游线程池拖满，最终雪崩。事后大家都说"这里早该上 Kafka 异步化了"，但当时为什么没上？我把它拆开看，其实不是"

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

背景 我带了 15 年后端，一半时间在做高并发链路。最近帮一个团队做容量评审，他们面对一个下单接口 P99 从 80ms 抖到 1.2s 的问题，给出的方案是"把下单同步流程拆成消息队列异步化，前端改成轮询结果"。我当场泼了冷水：你这不是把

先抛一个我 2021 年踩过的真实案例，再讲我的困惑，想听听大家的判断。 【背景案例】 某电商的"下单成功页"需要聚合 4 个下游：库存扣减、营销券核销、积分写入、物流预占。同步串行 P50 ≈ 210ms，P99 飙到 480ms（物流预

【背景】 高并发系统里，"把同步调用改成异步"大概是出现频率最高的性能优化建议。RT 从 80ms 降到 15ms，P99 从 300ms 降到 60ms，压测报告一片绿——然后呢？ 我最近帮一个团队做 review，他们的订单支付链路：创

【背景】 B 端订单服务，JDK17 + Spring Boot 3 + Netty 4.1，单机 8C16G，K8s cpu limit=4 / mem limit=8G。下游：Redis 7（3 主 3 从）+ MySQL 8.0.32