Amazon Elastic Beanstalk Worker cronjob (SQS) 多次触发同一消息

Posted 2023-03-04

【中文标题】Amazon Elastic Beanstalk Worker cronjob (SQS) 多次触发同一消息

【英文标题】：Amazon Elastic Beanstalk Worker cronjob (SQS) triggers same message multiple times

【发布时间】：2017-07-03 16:51:34

【问题描述】：

全部，

我的 Amazon Elastic Beanstalk Worker 与 SQS 结合使用时有一个非常令人不安的问题，它应该提供 cron 作业调度 - 所有这些都使用 php 运行。

以下场景 - 我需要在后台定期执行 PHP 脚本，该脚本最终可能会运行数小时。我看到了这个不错的介绍，它似乎完全涵盖了我的场景（AWS Worker Environments - 请参阅定期任务部分）

所以我阅读了很多操作指南，并使用 SQS 设置了一个 EBS Worker（这实际上是在创建 worker 期间自动完成的），并在我的部署包中提供了 cron 配置 (cron.yaml)。

cron 脚本被正确识别。 sqs 守护进程启动，消息被放入队列并准确地按计划触发我的 PHP 脚本。脚本运行，一切正常。

队列的配置如下： SQS configuration

但是经过一段时间的处理（脚本仍然很忙 - 不，它不是下一次计划运行^^）打开第二条消息并执行同一脚本的另一个实例，另一个，另一个...... . 正好间隔 5 分钟。

我怀疑，不知何故，消息没有从队列中删除（尽管我确保脚本返回状态 200），如果脚本运行时间过长，最终会创建新消息。

有没有办法防止产生其他消息？告诉队列或 sqs 守护进程不要创建新的飞行消息？我必须删除代码中的消息吗？虽然教程声明它应该自动发生

我只想触发脚本，从队列中删除消息并让脚本运行。请不要花哨的回退/重试机制:-)

我花了很多时间试图在互联网上找到一些东西。不成功。任何帮助表示赞赏。

谢谢

【问题讨论】：

前段时间有人问过这个问题，但我在 Amazon Linux AMI 2 上遇到了同样的问题，这篇文章帮助了我dev.to/rizasaputra/…

【参考方案1】：

我知道这并不能直接回答您有关配置的问题，但我遇到了类似的问题 - 我的队列配置设置与您的完全相同，在我的 Elastic Beanstalk 设置中，我已将 Visibility Timeout 设置为 @ 987654322@ 秒（或半小时）和Max Retries 到2。

如果一个作业运行超过一分钟，它会再次运行，然后被扔到死信队列中，即使在每次应用程序都返回 200 OK 之后也是如此。

几个小时后，我意识到这是 nginx 服务器超时 - 检查 Nginx 错误日志产生了这种洞察力。我不知道为什么 Elastic Beanstalk 在这种情况下包含一个 Web 服务器......如果一切都失败了，您可能想检查 EB 是否在您的应用程序前面生成一个 Web 服务器。

【参考方案2】：

查看the Worker Environment documentation 以获取有关您可以配置的值的详细信息。您可以配置几个不同的超时值以及“最大重试次数”，如果设置为 1 将阻止重新发送。但是，您的死信队列将填满实际成功处理的消息，因此这可能不是您的最佳选择。

【参考方案3】：

第二条消息被打开，同一脚本的另一个实例被执行，另一个，另一个……每隔 5 分钟。

我怀疑这是第二条消息。我相信这是相同的信息。

如果您在 Inactivity Timeout 到期之前没有响应 200 OK，那么消息会返回到队列中，是的，您会再次收到它，因为系统假定您已经崩溃，并且您想要再看一遍。这是设计的一部分。

您收到的X-Aws-Sqsd-Receive-Count 请求标头会告诉您当前消息已传递的大致次数。 X-Aws-Sqsd-Msgid 请求标头标识唯一消息。

如果您无法确保脚本将在超时之前完成，那么这可能不是此服务的合适用例。听起来服务工作正常。

【讨论】：

嗨，迈克尔，感谢您的回复。你说得对。这是相同的信息。我按照此处link 的描述发送 200，但它不会欺骗守护进程。我会再试验一下。如果我未能足够快地发送 200 - 有没有办法延长不活动超时或防止队列再次产生消息？

任何解决方案了吗？