我是否正确使用SQS？如何正确追踪队列状态？

核心思路：建立消息全生命周期状态追踪机制 #

基于你现有的SQS+Lambda架构，核心要解决的是「短信发送状态无法同步回用户端」的问题，结合MessageAttributes和持久化存储就能搞定，具体方案如下：

1. 消息入队时初始化状态记录 #

处理请求的Lambda在将消息放入SQS时，需要同步完成：

• 生成唯一消息追踪ID（比如UUID），作为这条短信的唯一标识
• 在DynamoDB中创建一条记录，字段包含：tracking_id（主键）、user_id、target_phone、message_content、status（初始设为PENDING）、created_at
• 将tracking_id作为MessageAttributes存入SQS消息，同时可附带user_id等必要关联信息

2. 短信发送Lambda同步更新状态 #

负责发短信的Lambda从SQS取出消息后：

• 解析MessageAttributes中的tracking_id
• 执行短信发送操作：
  • 发送成功：更新DynamoDB对应记录的status为SUCCESS，同时记录sent_at和服务商返回的message_id
  • 发送失败：区分错误类型——可重试错误（如临时网络波动）就把消息放回SQS（利用SQS自带重试机制），同时更新DynamoDB状态为RETRYING；不可重试错误（如号码无效）则更新状态为FAILED，记录失败原因

3. 前端状态同步逻辑 #

• 用户提交短信请求后，前端获取处理请求Lambda返回的tracking_id，定期轮询后端接口（可单独做一个查询Lambda或用API Gateway直接集成DynamoDB）获取状态
• 页面刷新时，前端根据用户ID从DynamoDB拉取该用户的短信记录，展示真实的发送状态，而非仅依赖请求提交结果

4. 结合SQS特性强化故障处理 #

• 配置死信队列（DLQ）：当消息重试次数超过阈值后自动移入死信队列，再单独写Lambda处理死信消息（比如通知运营、修复后重新入队）
• 在MessageAttributes中加入retry_count字段，每次重试时递增，辅助判断是否需要移入死信队列

MessageAttributes使用最佳实践 #

• 只存必要追踪字段（tracking_id、user_id、retry_count等），避免消息体积超限
• 字段类型优先用String或Number，方便Lambda快速解析
• 把重试次数这类决策性信息存在这里，辅助发送Lambda做重试判断

额外优化点 #

• 前端用WebSocket实现状态推送，替代轮询，状态更新时主动通知用户，提升体验
• 给DynamoDB的user_id建立全局二级索引，快速查询用户所有短信记录
• 所有日志（CloudWatch Logs）都带上tracking_id，方便排查问题时追踪整条链路

内容的提问来源于stack exchange，提问作者WeAreHawk09