@levinzhang
2023-07-30T08:13:28.000000Z
字数 1362
阅读 359
by
亚马逊云科技最近宣布在SQS中支持使用AWS SDK或命令行接口进行死信队列的重驱动。新功能允许开发人员将未消费的消息从死信队列中移出并转移回其源队列。
亚马逊云科技最近宣布在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