为什么需要消息队列
同步调用链路过长时，用户等待写库、发邮件、推搜索索引全部完成。异步化 后核心接口只发消息即返回。
API → 写 DB → 发 MQ → 返回用户
↓
消费者：发通知、建索引核心概念
- Producer / Consumer / Broker
- Topic / Queue / Partition
- Consumer Group：组内竞争消费，组间广播
- Offset：消费进度
削峰填谷
秒杀：网关限流 + MQ 排队，下游按能力消费，避免 DB 被打挂。注意 积压监控 与 过期策略。
解耦
订单服务只发 OrderCreated 事件；库存、积分、BI 各自订阅，新增下游不改订单代码。
顺序消息
全局顺序难；同一 key 进同一 partition 保证分区内有序（如订单 id hash）。
失败处理
- 重试 + 退避
- 死信队列 DLQ 人工介入
- 消费 幂等：业务 id 去重表、Redis SETNX
与 Redis List 对比
List BRPOP 轻量队列，无持久化 ACK 语义、无 consumer group 完善；生产用 Kafka/RabbitMQ/RocketMQ。
面试系统设计
画订单创建异步化；说明消息丢失环节（producer、broker、consumer）及对策。下一篇：week06-kafka-reliability 深入。
实战巩固与面试表达
本篇属于 8 周冲刺 week06-message-queue-basics 主题。复习时先闭卷回答 frontmatter 中三张 flashcard，再展开口述两个「为什么」：为什么这种方案能 work、边界失败时如何降级。与相邻章节对照：算法篇强调复杂度与模板，Go 篇强调工程默认写法，中间件篇强调线上故障案例。
动手与自检清单
用 25 分钟限时做 1 道相关练习题或画出一张架构/数据结构示意图；用 5 分钟写 STAR 片段说明你在项目里是否用过类似技术。记录 3 个面试追问及你的标准答法，存入 /zh/notebook/master-plan 笔记。若某点不熟，回到对应 /chapters 交互 Lab 重新走一遍流程，比死记卡片更有效。
易错点提醒
避免只背名词不会画图；避免只说优点不谈 trade-off（性能、一致性、运维成本至少提一项）；避免把学习 Demo 说成百万 QPS 生产。回答时使用「场景 → 方案 → 结果 → 反思」四段式，体现工程成熟度。
自检
列举同步改异步的一个项目例子（STAR 预演 Week 8）。