部署基于AWS SQS队列的异步任务Worker应用最佳实践及终止处理

一、通用部署最佳实践 #

• 用自动扩缩容组（ASG）管理EC2实例：别手动维护单台EC2，用ASG自动替换故障实例，配合启动模板统一实例规格、Worker部署脚本，确保新实例启动后自动加入队列消费。
• 分离配置与代码：把SQS队列URL、IAM实例角色（别硬编码凭证）、任务超时时间等配置放在环境变量或AWS Parameter Store/Secrets Manager里，减少代码变更频率。
• 保证任务幂等性：SQS可能重复发消息（比如消息超时未确认），Worker处理任务时必须确保重复执行无副作用——比如用消息ID做唯一键，处理前先查是否已完成该任务。
• 设置合理的消息可见性超时：按任务平均处理时长设置，比如任务平均耗时5分钟，就设10分钟留冗余。任务处理超时的话，消息会重回队列，避免丢失。
• 做好监控告警：用CloudWatch监控SQS待处理消息数、可见消息数，以及Worker实例的CPU/内存使用率，设置告警阈值（比如待处理消息数1小时超1000），及时发现消费瓶颈。

二、蓝绿部署适配要点 #

你判断蓝绿部署不影响SQS轮询是对的——蓝绿切换的是前端流量，Worker是主动轮询队列，只要新旧实例都有权限访问队列，就能并行消费。但要注意两点：

• 部署前让旧实例停止拿新任务：终止旧实例前，给旧Worker发信号（比如SIGTERM），触发停止消费逻辑，避免刚拿到消息就被终止。
• 等旧实例处理完现有任务再终止：给旧实例留足“优雅停机”时间，确保正在处理的任务全部完成。

三、旧实例关机时的任务处理方案 #

这是Worker部署的核心痛点，具体落地方法如下：

1. 实现优雅停机逻辑
   • 在Worker应用里监听系统终止信号（比如Linux的SIGTERM、Windows的Ctrl+C），收到信号后：
     • 立刻停止调用SQS的ReceiveMessage接口，不再获取新消息；
     • 标记当前处理中的任务为“收尾状态”，等待这些任务执行完毕；
     • 所有任务完成后，主动退出应用进程。
   • Java、Python等主流语言都有对应的信号监听库（比如Python的signal模块），实现起来很简单。
2. 利用EC2实例终止通知
   • 给EC2实例配置EventBridge规则，当实例进入terminating:wait状态时，发通知给Worker应用（比如HTTP请求、SNS主题），触发优雅停机流程。
   • ASG终止实例前会先发通知，默认有5分钟等待时间（可调整），足够大部分任务完成。
3. 超时与重试机制兜底
   • 就算优雅停机失败，只要设置了合理的消息可见性超时，未完成的任务会在超时后重回队列，被新Worker处理。
   • 给消息加“重试次数”属性，超过阈值的消息转入死信队列（DLQ），避免无限重试浪费资源。
4. 拆分长耗时任务
   • 如果有处理时间超1小时的任务，拆成分步任务：先完成一部分，把中间状态存在S3或DynamoDB，再发下一条消息到SQS处理后续步骤。这样就算实例终止，后续Worker能从中间状态继续处理，减少损失。

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