文件与 ExcelCASE 01
十万行 Excel 导入为什么不能让页面一直等？
用户正在做什么
运营提交大文件，解析和写入需要几分钟。
业务会出什么问题
同步请求可能超时，浏览器关闭后结果也难以找回。
技术怎样介入
接口立即创建异步任务并返回 Job ID，后台继续处理，前端轮询或接收推送更新状态。
产品与设计怎样落地
设计任务中心、排队、处理中、进度、取消、失败和完成通知。
M2 · Chapter 07
异步、事件与消息
理解为什么系统不会让所有任务都在当前请求里完成。
先看哪些场景
文件与 Excel、消息与通知、异步任务、订单与支付
它是什么
异步系统把耗时或可延后任务交给队列、Worker 或事件订阅者处理。
为什么需要
它可以缩短用户等待、吸收流量高峰，并让多个业务能力松散协作。
位于哪一层
连接后端服务、后台任务和外部处理系统。
和谁连接
Message Queue、Producer、Consumer、Event、Pub/Sub、Job、Worker、Retry 和 Idempotency。
项目里怎么出现
发送通知、生成报告、解析文件、同步搜索索引和数据分析经常异步执行。
Learning Outcomes
学完这一章，你应该能
- 区分同步请求与异步任务
- 理解队列、生产者和消费者
- 区分命令、事件与发布订阅
- 理解重试、重复消费和最终一致性
07.01
同步与异步
同步流程等待结果，异步流程先接受任务，再在后台完成。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
保存一条简单记录可以在请求中同步完成。生成大报告、发送大量邮件或解析视频可能耗时很长，继续占用请求会导致超时和差体验。
异步接口常先返回任务 ID，前端通过轮询、SSE 或 WebSocket观察状态。系统要设计排队中、处理中、成功、失败和取消。
Submit → Accepted + Job ID → Background Processing → Result
System View
同步
- 当前请求等待
- 结果立即返回
- 适合短任务
异步
- 先返回任务标识
- 后台执行
- 适合耗时或高峰任务
Designer Lens
看到“生成中”时，需要区分任务已提交、真正开始、处理进度和最终结果。
SynchronousAsynchronousJob ID
07.02
Message Queue、Producer 与 Consumer
队列把任务发送方和执行方解耦。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
消息与通知CASE 01
下单成功后，短信发送慢会不会拖住支付结果页？
用户正在做什么
订单创建成功后还要发短信、邮件、积分和数据统计。
业务会出什么问题
这些附加任务串行执行会增加下单延迟，某个通知故障还可能影响核心订单。
技术怎样介入
订单服务作为 Producer 写入 Message Queue，多个 Consumer 分别处理通知和积分；Backlog 表示待处理积压。
产品与设计怎样落地
核心成功先反馈，附加任务可显示“通知发送中”或后台完成，避免让用户重复下单。
Producer 把消息写入队列，Consumer 从队列读取并处理。双方不必同时在线，消费者也可以按能力稳定消费。
流量高峰时队列临时积压，避免所有请求直接压垮下游。队列深度和处理延迟需要监控。
Producer → Queue / Topic → Consumer → Result Store
System View
业务服务
→
发布消息
→
消息队列
→
Worker 消费
→
执行任务
→
记录结果
Designer Lens
任务中心的“排队人数”和预计等待，与队列积压和消费者处理速度有关。
ProducerConsumerBacklog
07.03
Kafka、RabbitMQ 与任务队列
不同消息系统在路由、吞吐、持久化和消费模型上各有侧重。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
异步任务CASE 01
Excel 解析任务和全站用户行为流为什么选不同消息系统？
用户正在做什么
一个系统需要可靠分发导入任务，另一个系统需要保存海量点击事件供多方消费。
业务会出什么问题
两类场景对顺序、吞吐、保留时间和消费方式要求不同。
技术怎样介入
RabbitMQ 常用于任务路由与确认；Kafka 通过 Topic 保存高吞吐事件流并支持多个消费组。
产品与设计怎样落地
产品侧要明确任务可否取消、是否需要顺序、是否允许延迟和是否需要重放。
RabbitMQ 常用于灵活路由和任务分发，Kafka 常用于高吞吐事件流和可重放日志。云平台也提供托管队列和 Pub/Sub。
选择取决于消息量、顺序、重放、延迟、消费组和运维能力。学习全景时重点理解它们都位于服务之间。
Services → Messaging Infrastructure → Workers / Other Services
System View
任务分发
- RabbitMQ/云队列
- 一条任务由消费者处理
- 路由与确认
事件流
- Kafka
- 高吞吐与可重放
- 多个消费组独立读取
Designer Lens
技术名称影响不大时，先问：这是任务队列、事件流，还是简单定时任务？
RabbitMQKafkaTopic
07.04
Command、Event 与 Pub/Sub
命令要求执行动作，事件描述已经发生的事实。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
订单与支付CASE 01
“创建订单”和“订单已创建”为什么是两种消息？
用户正在做什么
用户提交订单后，库存、积分和通知系统需要协作。
业务会出什么问题
把要求执行的动作和已经发生的事实混在一起，会导致责任边界不清。
技术怎样介入
CreateOrder 是 Command，由明确接收者处理；OrderCreated 是 Event，通过 Pub/Sub 通知多个订阅者。
产品与设计怎样落地
状态文案和操作按钮应区分“正在执行”与“事实已发生”。
GenerateReport 是命令，目标执行者明确；ReportGenerated 是事件，多个订阅者可以据此发送通知、更新统计或同步索引。
Pub/Sub 让发布者无需知道所有订阅者。新增分析服务时，只需订阅已有事件，原业务服务不必直接调用它。
Command → Specific Handler；Event → Many Subscribers
System View
Command
- 请做某事
- 通常有目标执行者
- 可能成功或失败
Event
- 某事已经发生
- 可有多个订阅者
- 用于后续反应
Designer Lens
事件名称适合用过去式表达事实；产品状态也需要反映事件处理可能存在延迟。
CommandEventPub/Sub
07.05
重试、重复消费与幂等
消息系统默认要面对失败和重复。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
订单与支付CASE 01
支付成功消息被消费两次，积分会加两遍吗？
用户正在做什么
消费者处理完成后确认消息时网络中断，队列再次投递同一消息。
业务会出什么问题
At-least-once 保证消息尽量不丢，但可能重复执行扣款、发券或加积分。
技术怎样介入
消费者通过业务唯一键实现幂等；成功后发送 Acknowledgement；多次失败进入 Dead Letter Queue。
产品与设计怎样落地
后台需要展示失败任务、重试次数和人工处理入口，用户侧避免重复权益。
消费者可能处理到一半崩溃，消息可能再次投递。网络错误也会触发重试。处理逻辑需要幂等，避免重复扣款、重复发券或创建多条记录。
持续失败的消息可以进入死信队列，等待人工或专门流程处理。重试要设置间隔和上限，避免故障放大。
Consume → Success Ack / Retry → Dead Letter Queue
System View
消费消息
→
执行业务
→
成功确认
→
失败重试
→
超过上限
→
死信与人工处理
Designer Lens
页面的“重试”要区分前端重新请求、服务端任务重试和人工重新执行。
AcknowledgementDead Letter QueueAt-least-once
07.06
最终一致性与产品状态
异步协作意味着不同系统不会在同一时刻完成更新。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
订单与支付CASE 01
订单显示已支付，积分为什么晚几秒到账？
用户正在做什么
支付服务先更新订单，积分服务通过事件异步处理。
业务会出什么问题
分布式系统无法保证所有服务同一瞬间成功，可能出现 Partial Failure。
技术怎样介入
系统接受短暂 Eventual Consistency；持续失败时执行 Compensation 或人工修复。
产品与设计怎样落地
界面明确区分核心结果与附加结果，使用“积分发放中”而非错误提示。
订单创建后，库存、通知、积分和分析可能在几秒内陆续完成。系统最终达到一致状态，但短时间内不同页面可能看到不同结果。
产品需要表达处理中、同步延迟、局部失败和可恢复操作。对用户承诺“已提交”与“已完成”要清楚区分。
Primary Action Complete → Events Processing → Eventually Consistent State
System View
用户提交
主记录创建
发布事件
多个消费者处理
搜索/通知/统计陆续更新
系统最终一致
Designer Lens
对异步任务使用准确文案：已提交、排队中、处理中、正在同步、部分失败、已完成。
Eventual ConsistencyPartial FailureCompensation
Chapter Recap
本章小结
- 01异步任务先被接受，再由后台处理。
- 02队列把生产者和消费者解耦，并吸收流量高峰。
- 03命令表达动作，事件表达事实，Pub/Sub 支持多个订阅者。
- 04重试、幂等、死信和最终一致性是异步系统的核心问题。
Practice
把认知变成一张图
把“上传 Excel 并导入 10 万条数据”设计成异步流程，列出所有用户可见状态和后台消息。
Quick Check
随堂检查
QUESTION 01
生成一个耗时十分钟的报告，最适合哪种方式？
长任务适合异步执行并提供任务状态。
QUESTION 02
为什么消费者需要幂等？
消息系统中重复投递很常见，幂等可避免重复副作用。