Amazon web services Amazon消息队列服务（SQS）发送和确认

场景：

弹性beanstalk环境有几个web服务器，这些服务器向另一个工作环境发送用户注册请求等

问题：

当其中一台工作机器完成任务时，我还希望它向web服务器发送确认

似乎SQS没有“确认”消息

当我们卸载发送电子邮件的任务时，我还想让web服务器知道发送电子邮件是成功的

---

我可以做的一个解决方案是实现web服务器轮询的另一个队列，但是，许多服务器可以在同一队列上轮询，服务器1的确认可以由服务器2接收，我们需要等待消息的超时，但是服务器3可能会截获该消息。服务器1可能需要等待一段时间才能得到确认。

工作机器“确认”消息的方式是从队列中删除消息。队列消息的生命周期为：

Web服务器发送带有请求的消息

工人收到消息

工作进程成功地处理了消息

工作者删除消息

正在删除的邮件是对其已成功处理的确认

如果工作进程在步骤4中未删除消息，则消息将在指定的超时后重新出现在队列中，下一个检查消息的工作进程将获取消息并对其进行处理

如果您担心某个消息可能无法处理并永远在队列中重新出现，则可以设置一个“死信”队列。在收到指定次数但从未删除的消息后，该消息将被传输到死信队列，您可以在该队列中处理这些异常情况

---

Amazon的简单队列服务很好、清晰地解释了此生命周期，以及如何确保每封邮件都经过处理或移动到死信队列进行特殊处理。

感谢您的详细回复。这是否意味着web服务器还需要轮询以查看消息是否仍然保留？如果它消失，则确认任务已成功？增加的等待时间是否证明了解耦系统的价值？因为如果web服务器执行所有电子邮件发送等操作可能会更容易。如果消息消失，则确认消息已成功处理。至于web服务器是否需要轮询，这取决于用例。为什么web服务器需要知道这一点？一旦发现成功或失败，它会做什么？从我对您描述的理解来看，web服务器只需要发送一封电子邮件，那么为什么还要麻烦确认呢？一旦您将消息放入队列，您就可以确信，如果可能的话，它将导致发送电子邮件。如果不可能，则消息最终将进入死信队列进行手动处理。如果您希望web服务器在响应web请求之前等待发送电子邮件，则没有理由使用消息队列。只需从web服务器发送电子邮件，作为响应请求的一部分。消息队列的好处是，您可以请求异步执行操作，并立即进行下一步操作，而无需等待。如果web服务器知道消息已发送，则还可以在可能的情况下通知同一页面上的用户。我用Java编写了后端，但我决定在前端使用Python。使用SQS进行通信似乎更容易。如果希望发送电子邮件的进程希望等待结果，则不应使用消息队列。它应该自己发送电子邮件，或者使用类似web服务的东西来代替。消息队列适用于您希望完成某项工作但不想等待其完成的情况。