Amazon sqs 带有DLQ的SQS-消息处理

我怀疑SQS源队列及其DLQ如何处理消息处理

我知道SQS并不像JMS那样实现传输，而是使用一个带超时的锁，以便其他订阅者在超时过期后可以从队列中取出

说到这里，我如何使用更多的SQS配置而不是客户端实现来实现下面的行为

订户侦听SQS中的消息； 尝试处理消息； 例如，如果失败，则重试3次； 如果重试失败，我必须将消息发送到DLQ并将其从源队列中删除。

---

这基本上是为您构建在SQS中的。一般来说，您的配置是将死信队列作为主队列的重新驱动目标。指定3作为重新驱动策略的最大接收数。然后，您的主代码将如下所示：

while( true ) {
    ReceiveMessageRequest receiveMessageRequest =
          new ReceiveMessageRequest(eventQueueUrl)
                        .withMaxNumberOfMessages(10)
                        .withWaitTimeSeconds(5);

    List<Message> messages = amazonSQS.receiveMessage(receiveMessageRequest)
                                                              .getMessages();

   for (Message nextMessage: messages) {
       // handle the message.  if the handling fails just continue.

       // if the message was processed correctly, delete it
       amazonSQS.deleteMessage(queueURL,nextMessage.getReceiptHandle() );
   }
}

这里的关键是，如果您不从主队列中删除消息，默认情况下，它将在30秒内再次可用。这可以作为主队列默认可见性超时的一部分进行更改。如果你真的删除了它，那么它就再也看不到了。在您的失败场景中，您将处理消息3次，在消息失败多次后，它将自动移动到死信队列

关于死信队列的一个小警告-在您尝试第四次读取该消息之前，该消息不会移动到死信队列。您的代码永远不会看到它，但是如果您尝试了3次，并期望它在第三次读取后在DLQ中结束，您将看不到它。当你第四次尝试阅读它时，AWS意识到它不能给你并为你移动它

---

另一方面，我假设Java是因为您提到了JMS。

除此之外，我会使用可运行的实现，我喜欢这样做。谢谢：