同步 vs 异步

服务 A 需要服务 B 的数据或动作时，有两种基本姿势：同步请求-响应（等你答完我再走）与 异步消息（我把事丢给你，各走各的）。选型错误会导致 超时链、耦合过紧或一致性问题。

学习目标

• 区分同步 / 异步的延迟与一致性特征
• 判断「用户要不要等这个结果」
• 对照 kafka-intro 与 Feign 同步调用

同步：请求-响应

[订单 API] ──HTTP POST──► [库存 API] ──200/409──► [订单 API] ──► 用户
              用户线程阻塞等待

典型实现：REST、sc-feign、OpenFeign + 负载均衡。

优点	缺点
语义直观，成功/失败立即可知	调用链越长，尾延迟叠加
便于强一致读（同一请求内）	下游故障直接传导给调用方

适合：用户必须立刻知道结果 的操作（扣库存是否成功、支付是否通过）。

异步：发后即忘

[订单 API] ──写 MySQL 提交──► [发 OrderCreated] ──► [Kafka Topic]
     │                                              │
     └── 立即 201 给用户                              ├──► 通知服务
                                                     ├──► 统计服务
                                                     └──► 搜索索引

用户只等「下单成功」；邮件、积分、推荐后台完成。见 kafka-producer。

优点	缺点
解耦、削峰	最终一致，需补偿与幂等
调用方不被慢下游拖死	调试链路变长

适合：可延迟、可重试 的副作用（发邮件、写审计、更新读模型）。

混合架构（常见）

同步：下单 ──Feign──► 扣库存（必须当场知道成败）
异步：下单成功 ──MQ──► 发券、通知、BI

rmq-patterns 的工作队列适合 任务型 异步；Kafka 适合 事件流 与多订阅者。

选型清单

• 用户是否在等？→ 是则同步或 异步 + 轮询/WebSocket 状态
• 能否接受秒级延迟？→ 可则消息
• 是否需要跨服务 同一事务？→ 不行，改 Saga（ip-saga）

练习

• 为「用户注册」列出同步步骤与可异步步骤
• 说明为何「支付结果」不宜纯异步通知用户
• 对照 kafka-vs-mq 写一句选型理由

小结

同步保即时反馈；异步保解耦与吞吐。 下一课：消息传递模式。