同步还是异步
同步调用链路短、结果即时、错误处理直观，但把调用双方的时延与可用性绑在一起：下游慢，上游就慢；下游挂，上游就报错。异步消息解耦时间与可用性，能削峰、能独立伸缩，代价是引入最终一致、幂等与消息治理的复杂度。选择依据是调用方对“结果要多快拿到”和“失败时能不能接受延迟补偿”的实际要求，而不是技术偏好。
基本信息
| 同步适用 | 需要即时结果的查询与命令，如校验、扣减、读取详情 |
|---|---|
| 异步适用 | 通知、长流程编排、削峰、跨团队解耦与批量处理 |
| 混合形态 | 关键路径同步确认，后续流程异步推进（先落库再发事件） |
| 代价口径 | 异步要额外投入幂等、重试、死信与消息顺序治理 |
典型使用场景
- 支付结果查询：用户需要立即看到结果，走同步
- 订单创建后的通知与积分：可接受秒级延迟，走异步
- 库存扣减：核心一致性要求高，优先同步或强一致方案
- 报表与对账：批量异步处理，不占用在线链路资源
- 第三方回调处理：接收后落库并立即返回，后续处理异步化
维度
| 维度 | 同步 | 异步 |
|---|---|---|
| 结果时效 | 即时返回 | 最终一致 |
| 耦合 | 时间与可用性耦合 | 解耦，双方独立伸缩 |
| 复杂度 | 错误处理直接 | 需幂等、重试与死信治理 |
| 典型场景 | 查询、强一致命令 | 通知、长流程、削峰 |
混合形态示意
混合形态示意
POST /orders
1. 同步校验库存并写入订单（事务内） → 返回 201
2. 事务提交后发送 order.created 事件
3. 消费端异步处理：通知、积分、报表
# 关键：事件在事务内以 outbox 方式落库，
# 避免“业务成功但事件没发出去”使用要点
- 按业务语义分层：强一致的关键路径同步，通知与统计类旁路异步
- 异步化后必须补齐失败补偿：重试、死信队列与人工介入入口
- 异步链路要有可观测性：积压量、消费延迟与失败率都要监控
- 同步调用要设超时与熔断，避免下游抖动直接传导为上游超时
- 跨团队边界用异步解耦更划算：双方可以各自选择发布节奏与技术栈
混合形态常见：关键路径同步确认，后续流程异步推进（如先落库再发事件），这样既保住用户可感知的即时性，又不让通知类逻辑拖慢主链路。
异步化会把一致性责任转移到业务侧：如果上游把“消息已发出”当作“业务已完成”，而消费端失败无人处理，业务状态会长期悬空。