S46：同步 API、异步 Event、Schema 变化与 DLQ

内容类型：预习教材（不代表已完成）
日期：2027-01-07
阶段：P2 · AI Systems Engineering 90
总路线：Day 136 / 360
周次：W7 · Protocols & Enterprise Integration
节奏：周四案例与连接
状态：教材已备；学习未完成
标签：sync-api、async-event、schema-evolution、duplicate-delivery、dlq

一句话定义

同步与异步不是快慢二选一，而是不同的时间耦合和责任模型；schema、重复投递与 DLQ 决定异步系统能否被长期运维。

学习目标

1. 根据等待、耦合、扇出、失败反馈和权威状态选择 API 或 event。
2. 理解异步事件的重复、乱序、迟到和 schema 演进是正常条件。
3. 解释 DLQ 的隔离、诊断、修复和重放生命周期。
4. 能完成一张集成模式选择表，而不是追求统一协议。

核心知识

• 同步 API 让调用方在请求周期内获得明确响应，适合即时查询与短事务，但产生可用性和延迟耦合。
• 异步 event 解耦时间并支持多消费者，却引入最终一致、重复、乱序、积压和运营责任。
• Command 表达“请做某事”，可能拒绝；event 表达“某事实已经发生”，不应命名为含糊的 processData。
• Consumer 必须声明兼容窗口。事件 schema 新增、删除、重命名和语义变化会与 backlog 中旧事件同时存在。
• DLQ 收纳反复处理失败的消息，避免阻塞主流；但需要 reason、原始事件引用、consumer version、重试次数、owner 和处置状态。
• 重放 DLQ 前必须确认处理器修复、幂等边界、事件仍具业务意义以及重放速度不会压垮下游。

机制与推导

选择可从等待语义开始：

必须立即返回权威结果 + 下游短时可用 -> sync query/API
只需确认接收，处理可延后           -> command + accepted response + completion event
事实要被多个独立消费者使用         -> event
需要多轮、长时、跨 Agent 协作      -> task/workflow protocol
需要判断而非计算                    -> human queue

队列积压可粗略理解为到达率 (\lambda) 大于可持续处理率 (\mu) 时不断增长。DLQ 不会改变 (\lambda) 与 (\mu)，只是隔离无法处理的一部分。若 schema 破坏导致大量消息进入 DLQ，盲目重试会形成重放风暴。

最小练习或观察步骤

1. 列四个交互：查询案件、提交升级、通知多个消费者、等待人工决定。
2. 为每个选择 sync API、event、workflow 或 human queue，并说明权威状态。
3. 构造一个 v2 事件新增 enum 值导致旧 consumer 失败的案例。
4. 写一条 DLQ record，含失败原因、consumer version、owner 和下一动作。
5. 设计重放前五项检查，不实际启动 broker。
6. 标出哪些失败可自动 retry，哪些应直接隔离或升级。

常见误区与边界

• 所有操作都异步化，却不给调用方查询状态的方式。
• 同步 API 返回 accepted 后让用户误以为业务完成。
• consumer 假设事件严格有序且只到一次。
• DLQ 没有 owner，逐渐变成永久数据墓地。
• 修复 consumer 后全速重放，触发下游限流和重复副作用。
• 本日不要求部署消息系统，架构案例足以学习核心取舍。

系统 / 金融 / Web3 场景连接

支付授权常需要即时响应，但清算、通知与对账是异步事实流。AML 案件升级可先确认接受，再等待核心系统事件。Web3 读链查询可同步返回某一高度的视图；交易确认与跨链消息完成则是长时异步过程，且要注明确认深度和重组风险。

自检问题

1. 同步和异步各引入哪种耦合？
2. 为什么 backlog 中可能同时存在多个 schema 版本？
3. DLQ 重放前为什么要重新检查业务意义？
4. accepted response 怎样与 completion event 配合？

专业课程对齐

• 阅读 AsyncAPI 官方文档 的 message、channel、operation 与 bindings 内容，映射 producer/consumer 责任和异步契约。
• 阅读 CloudEvents 官方站点 的事件属性与 SDK/规范入口，关注 envelope 怎样帮助跨 broker 传递身份与类型，而非解决顺序和幂等。
• 阅读 OpenAPI Specification 的 Responses、Callbacks/Webhooks 与 schema 相关部分，比较同步响应、回调和异步事件在契约上的表达。

深入学习提示

用同一个业务动作分别画纯同步、accepted+event、纯异步三种时序，再逐项比较调用方等待、失败可见性和运营负担。深入时研究 schema 演进要包含“旧事件仍在路上”，不要只比较两个静态文件。

学后填写区

• 集成模式选择表：
• 一个 schema 破坏案例：
• DLQ record 与 owner：
• 重放前检查项：
• 尚未理解的问题：