2023年6月8日，亚马逊云科技推出了一组用于Amazon Simple Queue Service（Amazon SQS）的新API。这些新API允许以编程方式管理死信队列（DLQ）重新传输。现在，可以使用AWS SDK或亚马逊云科技命令行界面（AWS CLI）以编程方式将消息从DLQ移至其原始队列或自定义队列目标，尝试再次处理。DLQ是一个队列，Amazon SQS会自动将使用者应用程序未正确处理的消息移至该队列。

为了充分理解这个新API如何为用户提供帮助，跟随亚马逊云科技快速回顾一下历史。

消息队列是现代应用程序架构不可或缺的一部分。这些队列允许消息生产者和使用者之间进行异步和基于消息的通信，从而使开发人员能够分离服务。在大多数系统中，消息会一直保留在共享存储（队列）中，直到使用者对其进行处理。消息队列允许开发人员构建能够抵御临时服务故障的应用程序。有助于确定消息处理的优先顺序，并扩展处理消息的Worker节点的实例集。消息队列在事件驱动型架构中也很常见。

异步消息交换在应用程序架构中并不是什么新鲜事物。在应用程序之间异步交换消息的概念出现在20 世纪 （ 参数 丨 图片 ）60年代，并在IBM于1972年推出OS/360版TCAM时首次进入大众视野。普遍采用出现在20年后，IBM于1993年推出MQ系列（现为IBM MQ），Sun Microsystems于1998年发布Java Messaging Service（JMS），这是Java应用程序与消息队列交互的标准API。

亚马逊云科技于2006年7月12日推出了Amazon SQS。Amazon SQS是一项高度可扩展、可靠且具有弹性的队列服务，可以“恰好满足需求”。正如Werner当时所写的那样：“我们选择了一种并发模型，在这种模型中，处理消息的进程会自动获得该消息的租用锁；如果在租约到期之前没有删除消息，则可以再次对其进行处理。因此，故障处理变得非常简单。”

2014年1月29日，亚马逊云科技推出了死信队列（DLQ）。DLQ可帮助用户避免无法处理的消息永远停留在队列顶部，这可能会阻止队列中的其他消息得到处理。在DLQ中，每个队列都有一个关联的属性，告知Amazon SQS一条消息可能被提交多少次以供处理（maxReceiveCount）。每条消息还有一个关联的接收计数器（ReceiveCount）。每次使用者应用程序接收消息进行处理时，消息接收计数都会增加1。当ReceiveCount>maxReceiveCount时，Amazon SQS会将消息移至指定的DLQ以供人工分析和调试。通常将警报与DLQ相关联，以便在发生此类事件时发送通知。将消息移至DLQ的典型原因是其格式不正确、使用者应用程序中存在错误或者处理消息需要很长时间。

在亚马逊云科技re:Invent 2021上，亚马逊云科技宣布在Amazon SQS控制台上推出死信队列重新传输功能。重新传输解决了失败消息生命周期第二部分的问题。该功能允许将消息重新注入其原始队列中以尝试再次对其进行处理。修复使用者应用程序并准备好使用失败的消息后，可以将消息从DLQ重新传输回源队列或自定义队列目标。只需要在控制台上点击几下即可。

6月8日，亚马逊云科技添加了API，允许编写以编程方式处理重新传输的应用程序和脚本。不再需要人工点击控制台。使用该API可以提高进程的可扩展性并降低人为错误的风险。

可用性

DLQ重新传输API现已在所有提供Amazon SQS的商业区域推出。

将消息从死信队列重新传输到源队列或自定义目标队列会生成额外的API调用，根据现有定价计费（在前一百万次API调用之后，起价为每百万次API调用0.40美元，每个月的前一百万次调用免费）。Amazon SQS对消息进行批处理，同时将其从一个队列重新传输到另一个队列。这样，将消息从一个队列移至另一个队列就成为一种简单且低成本的选择。