Amazon SQS Worker Tier Auto Scaling失败

Question

我们有一个订阅队列的SQS Worker Tier应用程序。当它运行时它工作正常，但是，当它变得繁忙并且向上扩展时，新实例几乎立即开始获取消息，然后才真正准备好。这导致500个响应，并且消息被丢弃到死信队列。

我们的队列配置最大尝试次数为1;由于数据库更改消息将在消费期间产生，我们无法在发生错误时将其重新放回队列中。

我尝试过使用监视器运行状况网址，就像使用普通的网络应用程序一样，但这似乎无法正常工作，因为无论如何都会继续发送消息。

在开始从队列接收消息之前，有没有办法在任何新的自动缩放实例上设置延迟？

Answer 1

我不确定实例在准备好之前是如何“获取消息”的，除非您实际上使用SNS将消息推送到端点，而不是让端点（实例）从队列中提取消息。 / p>

如果你是通过SNS推送消息，那么最简单的解决方案就是让实例POLL SQS队列，以便在它准备好处理消息时 - 更加安全可靠，显然实例可以在准备好时自行决定做的。

对我而言，听起来像你的解决方案没有正确构建。如果两次意外处理相同的消息会导致数据库出现问题，那么就不能以正确的方式使用SQS。 SQS所做的工作应该是idempotent - 即它应该能够处理多次而不会引起问题。即使一切都在100％正确运行，在您的终端和AWS上，也可能会向您的员工多次发送相同的消息 - 您无法阻止 - 并且您的处理需要能够优雅地处理

Answer 2

您可以设置HTTP连接设置（配置＆gt;工作人员配置），以限制与工作人员的并发连接数。如果您将其设置为1，那么您确定1名工作人员不会收到其他请求，除非它已经响应。