AWS Beanstalk：SQS的指数补偿？

Question

我们正在使用Beanstalk上的worker层来发送webhook。我们需要使用指数补偿，以防在与第三方联系时出现任何错误。但是，我不清楚这将如何工作。

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

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

来自Environment Tiers - AWS Beanstalk：

工作者环境层中的Web应用程序应仅侦听本地主机。当Web应用程序处于工作环境中时层返回200 OK响应以确认已收到并成功处理请求后，守护程序发送DeleteMessage调用SQS队列，以便将邮件从队列。 （SQS会自动删除队列中的邮件的时间比配置的RetentionPeriod更长。）如果应用程序返回除200 OK以外的任何响应，然后Elastic Beanstalk等待在配置后将消息放回队列VisibilityTimeout期限。如果没有响应，则为ElasticBeanstalk等待将消息放回队列后InactivityTimeout时间段，以便该消息可用于其他消息尝试处理。

Answer 1

ChangeMessageVisibility的限制为12小时，仅适用于飞行中作业（正在运行的作业，您希望通知SQS“我需要更多时间来完成此作业”）。

唯一的解决方案是在队列中创建一个具有相同详细信息的新作业，并使用一个额外的重试计数器（在消息中或作为属性），并使用DelaySeconds和基于retries + 1的指数补偿。

[不幸的是DelaySeconds的限制为15分钟（900秒），因此您可以安排比其他时间更长的工作：

1. 请每隔15分钟重新安排作业的时间，但是在重试次数足够多之前，请不要执行任务。这将运行95个作业，直到第96个作业才执行任何操作。这可能会产生大量的虚拟作业。
2. 将作业放置在其他地方（例如数据库或缓存），使用cron或其他计划的过程在达到最小时间戳后将其重新放入队列。例如，时间戳记现在为+ 1天。

Answer 2

增加失败作业的ChangeMes​​sageVisibility的利弊：

优点：

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

缺点：

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

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

欢呼声