170 lines
6.0 KiB
Markdown
170 lines
6.0 KiB
Markdown
# 第18天：SQS 与 SNS——消息队列和通知服务
|
||
|
||
## 今天你将学到什么
|
||
|
||
今天学习两个让系统"松耦合"的服务：SQS（消息队列）和 SNS（通知服务）。它们解决的核心问题是：**让系统的各个部分不再紧密依赖，一个部分出问题不会拖垮整个系统。**
|
||
|
||
---
|
||
|
||
## 为什么需要消息队列——用餐厅来理解
|
||
|
||
### 没有消息队列的世界（紧耦合）
|
||
|
||
想象一个餐厅，流程是这样的：
|
||
|
||
顾客点单 → 服务员站在厨房门口等 → 厨师做好菜 → 服务员端菜上桌 → 服务员回来接下一个顾客
|
||
|
||
**问题**：
|
||
- 服务员在等厨师做菜的时候什么都干不了（阻塞）
|
||
- 如果厨师突然肚子疼去了厕所，服务员和顾客都得干等（一个环节故障影响全部）
|
||
- 午餐高峰期 100 个人同时点单，厨房根本忙不过来（没有缓冲）
|
||
|
||
### 有消息队列的世界（松耦合）
|
||
|
||
改进后的流程：
|
||
|
||
顾客点单 → 服务员把订单**贴在窗口**（消息队列）→ 服务员立刻回去服务下一个顾客
|
||
|
||
厨师按自己的节奏从窗口**取订单**做菜 → 做好了放在出菜口 → 服务员来取
|
||
|
||
**好处**：
|
||
- 服务员不用等厨师（异步，不阻塞）
|
||
- 厨师去厕所了？订单还贴在窗口，回来继续做（容错）
|
||
- 高峰期订单堆在窗口，厨师按自己的速度做，不会崩溃（削峰）
|
||
- 可以加更多厨师来加快速度（水平扩展）
|
||
|
||
**这就是消息队列的价值。**
|
||
|
||
---
|
||
|
||
## SQS（Simple Queue Service）
|
||
|
||
SQS 是 AWS 的消息队列服务——一个"订单窗口"。
|
||
|
||
### 工作流程
|
||
|
||
```
|
||
生产者（发送消息的人）→ SQS 队列 → 消费者（处理消息的人）
|
||
```
|
||
|
||
**举个真实例子**：电商下单流程
|
||
|
||
用户点击"提交订单"后，需要做很多事：
|
||
1. 扣减库存
|
||
2. 发送确认短信
|
||
3. 生成物流单
|
||
4. 更新用户积分
|
||
5. 通知仓库备货
|
||
|
||
**没有 SQS**：所有步骤串行执行。用户要等所有步骤完成才看到"下单成功"。任何一步失败，整个订单失败。
|
||
|
||
**有 SQS**：
|
||
- 订单创建成功后立刻返回"下单成功"给用户（用户不用等）
|
||
- 同时把"有新订单"这个消息发到 SQS 队列
|
||
- 库存服务、短信服务、物流服务各自从队列取消息处理
|
||
- 某个服务暂时挂了？消息还在队列里，恢复后继续处理
|
||
|
||
### SQS 的关键特性
|
||
|
||
**消息保留**：消息最多保留 14 天。如果 14 天内没人处理，才会被删除。
|
||
|
||
**可见性超时**：消费者取走一条消息后，这条消息对其他消费者"隐藏"一段时间。如果消费者处理成功就删除消息；如果处理失败（比如消费者崩溃了），超时后消息重新出现，可以被其他消费者重试。
|
||
|
||
**死信队列**：如果一条消息反复处理失败（比如重试了 5 次都失败），自动转移到"死信队列"。你可以人工检查这些"问题消息"，避免它们阻塞正常处理。
|
||
|
||
---
|
||
|
||
## SNS（Simple Notification Service）
|
||
|
||
SNS 是"发布/订阅"模式的通知服务——一条消息可以同时发给多个接收者。
|
||
|
||
### SQS vs SNS 的区别
|
||
|
||
**SQS = 点对点**（一条消息只被一个消费者处理）
|
||
- 类比：快递柜。一个包裹只能被一个人取走。
|
||
|
||
**SNS = 广播**（一条消息发给所有订阅者）
|
||
- 类比：小区广播。一条通知所有住户都能听到。
|
||
|
||
### SNS 的工作方式
|
||
|
||
```
|
||
发布者 → SNS 主题（Topic）→ 订阅者 A（邮箱）
|
||
→ 订阅者 B（短信）
|
||
→ 订阅者 C（SQS 队列）
|
||
→ 订阅者 D（Lambda 函数）
|
||
→ 订阅者 E（HTTP 接口）
|
||
```
|
||
|
||
**举个例子**：用户注册成功后
|
||
|
||
```
|
||
用户注册成功 → 发布"新用户注册"事件到 SNS
|
||
→ 邮件服务收到 → 发送欢迎邮件
|
||
→ 积分服务收到 → 赠送新人积分
|
||
→ 推荐服务收到 → 生成个性化推荐
|
||
→ 数据分析收到 → 记录注册统计
|
||
```
|
||
|
||
一个事件，多个服务各自处理自己关心的部分。互不影响。
|
||
|
||
---
|
||
|
||
## 经典组合：SNS + SQS（扇出模式）
|
||
|
||
这是 AWS 最推荐的异步架构模式：
|
||
|
||
```
|
||
订单服务发布"新订单"事件
|
||
↓
|
||
SNS 主题（广播给所有订阅者）
|
||
├── SQS 队列 A → 库存服务（扣减库存）
|
||
├── SQS 队列 B → 通知服务（发短信/邮件）
|
||
├── SQS 队列 C → 物流服务（生成运单）
|
||
└── SQS 队列 D → 积分服务（加积分）
|
||
```
|
||
|
||
**为什么中间要加 SQS，不直接用 SNS 推给各服务？**
|
||
|
||
因为 SQS 提供了"缓冲"和"重试"：
|
||
- 某个服务暂时挂了 → 消息在 SQS 里等着，恢复后继续处理
|
||
- 某个服务处理慢 → 消息在 SQS 里排队，不会丢失
|
||
- 流量突然暴涨 → SQS 帮你削峰，各服务按自己的速度消费
|
||
|
||
---
|
||
|
||
## 同步 vs 异步：什么时候用哪种
|
||
|
||
| 场景 | 方式 | 原因 |
|
||
|------|------|------|
|
||
| 用户查询商品详情 | 同步 | 用户在等结果，必须立刻返回 |
|
||
| 用户下单扣库存 | 同步 | 必须确认库存够才能下单 |
|
||
| 下单后发确认短信 | 异步 | 短信晚几秒发不影响下单结果 |
|
||
| 下单后更新推荐 | 异步 | 推荐更新慢一点无所谓 |
|
||
| 上传图片后生成缩略图 | 异步 | 缩略图不需要立刻生成 |
|
||
|
||
**判断标准**：用户是否在等这个结果？如果是，同步。如果不是，异步。
|
||
|
||
---
|
||
|
||
## 今天的小测验
|
||
|
||
1. 消息队列解决的核心问题是什么？用你自己的话解释。
|
||
2. SQS 和 SNS 的区别是什么？各自适合什么场景？
|
||
3. 什么是"死信队列"？它解决什么问题？
|
||
4. 为什么说"SNS + SQS"是最佳组合？
|
||
|
||
---
|
||
|
||
## 延伸阅读
|
||
|
||
- [SQS 开发者指南](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/)
|
||
- [SNS 开发者指南](https://docs.aws.amazon.com/sns/latest/dg/)
|
||
- [AWS 消息传递模式](https://aws.amazon.com/messaging/)
|
||
|
||
---
|
||
|
||
## 明天预告
|
||
|
||
明天是第二阶段的收尾：用一个完整的项目案例，把这 11 天学到的所有核心服务串联起来，看看它们在真实架构中是怎么配合工作的。
|