在消费者变慢或失败时保留任务，通知下游团队，并保护业务结果不被重复投递改变。通过小型订单处理流程学习 SQS 和 SNS。
5 个引导实验覆盖消费、可见性、死信队列、SNS 扇出和重复保护。独立挑战修复失败任务无法到达恢复队列的事件。
你将学到什么
- 发送、领取、处理并确认 SQS 任务
- 观察可见性窗口、再次投递和当前 receipt handle
- 通过死信队列隔离失败任务
- 将 SNS 通知扇出到带过滤器的 SQS 订阅
- 通过 DynamoDB 条件写入保护重复业务操作
- 修复失败任务路由，同时让健康任务继续处理
- 验证存储结果并仅删除自己的资源
适合人群
适合准备为无服务器应用增加异步任务与故障处理能力的学习者。
先修要求： 先掌握 Lambda–DynamoDB 访问（FN03）及其前置。按 Q01 → Q02 → Q03 学习队列处理与失败隔离；Q04 另需 IAM 资源策略，属于 SNS 支线；Q05 需要 DynamoDB 条件写入（D04）和 Lambda 代码更新（FN02）。服务挑战接在 Q03 及其前置之后，PS02 项目还使用 Q05。
学习环境： 所有活动都在 LabEx 提供的浏览器 Linux 环境中进行。使用 Terminal 执行 AWS CLI 命令，并在其旁边的 AWS View 查看相同的资源和应用状态。工具与连接已准备好，无需个人 AWS 账户或访问密钥。每个实验都在全新的 VM 中独立开始。 AWS View 展示队列、消息体、尝试次数、日志、SNS envelope 和存储订单。只读观察不会领取或确认消息。
常见问题
队列配置完成能证明任务已处理吗？
不能。检查实际处理、存储结果、源消息确认和失败任务保留。提供的工作程序与参考数据让你专注于这些结果，只使用示例任务。
为什么消息会有新的 receipt handle？
receipt handle 属于一次投递。可见性过期后，消息可能再次被领取并获得当前 receipt。确认消息时必须使用目标投递的 handle。
重复保护等于恰好一次投递吗？
不等于。Standard 队列可能多次投递；单项目条件写入保护所教业务效果，但队列与数据库操作彼此独立，不构成原子事务或端到端 exactly-once 保证。
消息示例的范围是什么？
覆盖 Standard 队列、单条消息消费者、死信 redrive、同账户 SNS 到 SQS 扇出和消息属性过滤。不包括 FIFO 顺序、任意 batch、生产吞吐、跨账户策略设计或完整服务重试保证。
下一步是什么项目？
Serverless 项目课中的 Recover Poison Messages Without Duplicating Orders。 服务挑战需要 Q03 及其引导前置，项目还需要 Q05。先验证功能，再清理。
