Amazon SQS 支持从死信队列重新生成消息

亚马逊云科技最近宣布在 SQS 中支持使用 AWS SDK 或命令行接口进行死信队列的重驱动。新功能允许开发人员将未消费的消息从死信队列中移出并转移回其源队列。

当出现错误时，SQS 会将未消费的消息转移至死信队列（dead-letter queue，DLQ），从而能够让开发人员探查未成功消费的消息并调试应用程序的故障。亚马逊云科技的开发人员倡导者 Sébastien Stormacq 解释到：

每当消费者应用捡取一个要处理的消息时，消息的接收计数就会加 1。当ReceiveCount>maxReceiveCount 时，Amazon SQS 会将消息移动到指定的 DLQ 中，供人工分析和调试。我们通常会将警报与 DLQ 关联起来，以便于在这种情况发生时发送通知。

在失败的消息调试完成或消费者应用能够消费它时，新的重驱动功能 就会将消息移回源队列，从而能够在分布式系统中以编程的方式管理大规模未消费消息的生命周期。

过去，这只能通过在控制台手动处理 才能实现。Ampt 公司的 CEO 兼创始人 Jeremy Daly 当时这样写到：

这不是一个特性，这不是一个 API，而是一种只能在 AWS Console 中才能获取的“体验”。我想要它吗？想要！但是，我想登录 AWS Console 来使用它吗？绝对不想要！

要重新处理 DLQ 消息，开发人员可以使用如下的任务：StartMessageMoveTask 用于从死信队列启动新的消息移动任务；CancelMessageMoveTask 用于取消消息移动任务；ListMessageMoveTasks用于获取特定源队列最近的消息移动任务（最多 10 个）。

社区对这项特性给出了积极的反馈，MUSIC Tribe 的云计算和平台主管 Tiago Barbosa评论 说：

这是一个很好的改进。我一直不喜欢使用 DLQ，其中一个原因就是需要建立一种机制来重新处理最终出现在 DLQ 中的条目。

Curantis Solutions 的 CTO Benjamen Pyle 撰写了一篇文章，介绍了如何使用 Golang 和 Step Functions 来重新驱动消息。

在 DLQ 的配置中，可以使用自定义目的地选项的 ARN 来指定将消息发送回源队列还是其他队列。PostNL 首席工程师、AWS Serverless Hero Luc van Donkersgoed 在推特上写到：

如果能重新驱动到原始队列就好了。这一点非常棒，因为它允许我们指定任意的目标队列。这使得以前完成此项任务的 Lambda Functions 瞬间化为乌有。

文档强调了一些限制：SQS 仅支持标准队列的死信队列的重新驱动，不支持在重新生成它们时过滤和修改消息。除此之外，一个 DLQ 重新驱动任务最多可运行 36 小时，每个账户最多可以有 100 个活跃的重新驱动任务。有些开发人员质疑其缺少对 Step Functions 的支持。

SQS 不会自动创建 DLQ，队列必须在接收到未消费的消息之前进行创建和配置。

原文链接：

Amazon SQS Supports Reprocessing Messages from Dead-Letter Queue(https://www.infoq.com/news/2023/06/aws-sqs-dlq-redrive/)

相关阅读：

大模型竞争突然升级！亚马逊 CEO 亲自监督、组建新的核心技术团队，集中优势资源打造“最具野心”的大语言模型 (https://www.infoq.cn/article/3utpk9247A6CtoyztLTB )

亚马逊云科技开源 PBAC 领域特定语言 Cedar(https://www.infoq.cn/article/CC2RaXSKw5oRwzpymyxx )

声明：本文为 InfoQ 翻译，未经许可禁止转载。

点击底部阅读原文访问 InfoQ 官网，获取更多精彩内容！