AWS Beanstalk：SQS的指数退避？

Question

我们正在使用Beanstalk上的工作层发送webhook。如果在联系第三方时出现任何错误，我们需要使用指数退避。但是，我不清楚这是如何工作的。

如果作业失败并且我调用ChangeMessageVisibility来增加退避时间，我有两个选择：

1. 返回成功200.然后SQS将其从队列中删除 - 不是很好。
2. 返回错误代码。那么SQS会将消息可见性覆盖为默认值吗？

来自Environment Tiers - AWS Beanstalk：

  

工作者环境层中的Web应用程序应该只监听   当地主人。当工作环境中的Web应用程序时   tier返回200 OK响应，以确认它已收到和   成功处理了请求后，守护进程发送了一个DeleteMessage   调用SQS队列，以便从中删除该消息   队列。 （SQS会自动删除队列中的消息   比配置的RetentionPeriod更长。）如果是应用程序   返回除200之外的任何响应，然后Elastic Beanstalk等待   在配置完成后将消息放回队列中   VisibilityTimeout期间。如果没有回应，那么弹性   Beanstalk等待将消息放回队列之后   InactivityTimeout期间，以便该消息可供另一个使用   试图加工。

Answer 1

Create<Type>的限制为12小时，仅适用于 inflight 作业（在他们正在运行时，您想要通知SQS的作业“我需要更多时间来完成此操作”）。

唯一的解决方案是在队列中创建具有相同详细信息的新作业和用于重试的附加计数器（在消息中或作为属性），并使用具有基于ChangeMessageVisibility的指数退避的DelaySeconds。

不幸的是retries + 1有15分钟（900秒）的限制，因此您安排的工作时间比您有几个选项的时间长：

1. 每15分钟重新安排一次工作，但在重试达到足够高之前不要完成任务。这将会运行95个工作，直到第96个工作都没有。这可能会产生大量的虚拟工作。
2. 将作业放在其他地方（如数据库或缓存），使用cron或其他一些预定进程，一旦达到最小时间戳，就将其放回队列中。例如，时间戳现在为+ 1天。

Answer 2

增加失败的作业的ChangeMes​​sageVisibility具有优点和缺点：

优点：

• 在删除和重新排队的过程中，您不会失去工作。

缺点：

• 工作进行中的12小时限制。
• 一次只能有2万个机上工作

因此，减轻弊端的一个办法是，如果作业失败太多次，则将重新驱动策略设置为dlq。