使用 Amazon SQS 构建异步消息传递 - Standard 与 FIFO 队列的设计
介绍 Standard 与 FIFO 队列的选择、DLQ 对处理失败消息的转移以及 Lambda 事件源映射的自动处理。
SQS 概述
SQS 是全托管的消息队列服务。与 SNS 提供一对多扇出不同，SQS 提供一对一的点对点消息传递。将 Web 应用的请求处理与后端的重型处理分离，提升可扩展性和容错性。SQS 将消息冗余存储在多个可用区，单个可用区故障不会导致消息丢失。消息保留期默认为 4 天，最长可延长至 14 天。可见性超时 (Visibility Timeout) 默认为 30 秒，控制正在被一个消费者处理的消息对其他消费者不可见的时长。
队列设计与 DLQ
Standard 队列提供每秒数万条消息的吞吐量，不保证消息顺序（尽力排序）。保证至少一次投递 (at-least-once)，因此消费者端必须确保幂等性。FIFO 队列按消息组 ID 保证顺序，通过去重 ID 实现 exactly-once 处理。吞吐量为每秒 300 条消息（批量为 3000），启用高吞吐量模式后可扩展至每秒数千条。DLQ 自动将处理失败 maxReceiveCount 次的消息移动，不阻碍主队列的处理。可调查 DLQ 中的消息，修复原因后重新驱动（重新发送）到主队列。DLQ 的保留期可独立于源队列设置，建议设置足够长的调查期间（如 14 天）。
Lambda 集成与大容量消息
通过 SQS 与 Lambda 的事件源映射，队列中的消息会自动由 Lambda 函数处理。设置批量大小（最大 10,000）和批量窗口（最大 300 秒），将多条消息合并处理以减少 Lambda 调用次数。启用部分批量响应 (ReportBatchItemFailures) 后，仅重新处理批量中失败的消息，避免成功消息的重复处理。FIFO 队列中 Lambda 的并发执行数受消息组数限制。Extended Client Library 通过 S3 收发超过 256 KB 的消息，支持大容量数据的异步处理。消息加密可通过 SSE-SQS（免费）或 SSE-KMS 设置。 有关消息队列的详细讲解，也可参阅Amazon 的相关书籍。
设计最佳实践与常见陷阱
将可见性超时设置为大于消费者最大处理时间的值。如果设置过短，消息会被重新投递导致重复处理。Standard 队列的消费者必须实现幂等性，可通过 DynamoDB 条件写入或数据库唯一约束防止重复处理。FIFO 的去重窗口固定为 5 分钟，在 5 分钟内发送相同去重 ID 的消息会被丢弃。务必启用长轮询（将 WaitTimeSeconds 设置为 1 到 20 秒之间），短轮询会频繁产生空响应，导致不必要的请求计费。利用消息属性 (MessageAttributes) 进行路由和过滤，最小化消息体解析以提高消费者性能。
定价与限制注意事项
SQS Standard 队列每 100 万请求约 0.40 美元，FIFO 队列约 0.50 美元。每月前 100 万请求免费。每个请求最大 256 KB，每 64 KB 块计为 1 个请求。长轮询 (WaitTimeSeconds=20) 减少空响应，优化请求数。DLQ 的消息按与普通队列相同的费率计费，因此应定期处理或删除 DLQ 中的消息。处理中消息数上限为 Standard 120,000 条、FIFO 20,000 条。超过此上限将返回 OverLimit 错误，因此通过消费者扩展确保处理速度的设计至关重要。使用 SSE-KMS 加密时会产生额外的 KMS API 调用费用，大量消息的队列建议使用 SSE-SQS（无额外费用）。
SQS 与其他消息服务的比较
SQS 是基于拉取的点对点队列。SNS 是基于推送的发布/订阅模式，将单条消息同时投递给多个订阅者。SNS + SQS 扇出模式将多个 SQS 队列订阅到 SNS 主题，在各队列中独立并行处理。Amazon MQ 是 Apache ActiveMQ 和 RabbitMQ 的托管版本，在需要与 JMS 或 AMQP 等现有协议兼容时选择。EventBridge 面向事件驱动架构，基于规则路由来自 100 多个 AWS 服务和 SaaS 的事件。SQS 针对大量消息的缓冲和 Worker 模式进行了优化，在成本效率和运维简单性方面表现出色。
总结
SQS 是通过异步消息传递构建松耦合架构的服务。Standard 队列提供每秒数万条消息的吞吐量，FIFO 队列实现顺序保证和去重。Lambda 事件源映射自动处理消息，DLQ 转移处理失败的消息。长轮询优化请求数，Extended Client Library 支持超过 256 KB 的消息。确保幂等性和正确配置可见性超时是决定生产环境稳定性的关键设计要点。