📨 1. 消息传递模型
- SNS（发布/订阅模式）
- 推送机制：消息发布到主题（Topic）后，自动实时推送给所有订阅者（如Lambda、SQS、Email、SMS等）。
- 多对多关系：一个主题可关联多个发布者和订阅者，支持广播式消息分发。
-
无持久性：若订阅者不可用，消息可能丢失（需结合SQS解决此问题）。
-
SQS（队列模式）
- 轮询机制：消息存储在队列中，消费者需主动拉取（Polling）处理。
- 多对一关系：多个生产者可向同一队列发送消息，但通常只有一个消费者处理（支持多个消费者竞争消息）。
- 持久性：消息保留1分钟至14天（默认4天），确保可靠传递。
⚙️ 2. 核心特性对比
| 特性 | SNS | SQS |
|---|---|---|
| 消息顺序 | 标准主题无序；FIFO主题有序（需显式启用） | 标准队列无序；FIFO队列严格有序 |
| 可靠性 | 无重试机制，依赖订阅者可用性 | 支持重试策略+死信队列（DLQ），处理失败消息 |
| 批处理 | 不支持，单条消息处理 | 支持批量发送/接收（标准队列最多10,000条/批） |
| 消息大小 | 最大256KB | 最大256KB（大文件需借助S3存储指针） |
🚀 3. 典型使用场景
SNS 适用场景：
- 实时广播通知：如订单状态更新同时触发短信、邮件、APP推送。
- 事件驱动架构：微服务间事件广播（如库存变更触发下游服务）。
- 系统告警：CloudWatch监控指标超阈值时，通过SNS发送告警到多渠道。
SQS 适用场景：
- 异步任务处理：耗时任务（如图像处理）解耦，避免阻塞主流程。
- 流量削峰填谷：突发请求缓冲到队列，消费者按能力处理（如投票系统）。
- 可靠消息传递：需保证消息必达且有序的场景（如金融交易流水）。
🤔 4. 选型建议
- 选择 SNS 当：
需一对多广播、实时推送、多协议支持（短信/邮件等）。 - 选择 SQS 当：
需持久化存储、错误重试、批量处理或严格消息顺序。
🔄 5. 组合使用：扇出模式（Fan-out）
结合两者优势的经典架构：
1. SNS 作为消息分发中心：接收事件并广播到多个SQS队列。
2. SQS 作为缓冲层：每个队列对应一个消费者（如Lambda），实现并行处理与流量控制。
案例：社交媒体发帖后，同时触发翻译队列、数据分析队列和用户通知。
💎 总结
SNS是“通知者”，专注高效广播；SQS是“暂存者”，确保可靠传递与异步处理。实际中常协同使用（如SNS→SQS→Lambda），构建弹性消息架构。理解两者的核心差异，是设计高可用、解耦系统的关键一步。