所有
我的Amazon Elastic Beanstalk Worker与SQS相结合存在一个非常令人不安的问题，SQS应该提供一个cron作业调度 - 所有这些都运行在PHP上。
以下场景 - 我需要在后台定期执行PHP脚本，最终可能会运行数小时。我看到这个很好的介绍似乎涵盖了我的场景（AWS Worker Environments - 参见周期性任务部分）
因此，我阅读了大量的howtos并使用SQS设置了一个EBS Worker（实际上是在创建worker期间自动完成的）并在我的部署包中提供了cron config（cron.yaml）。
正确识别cron脚本。 sqs守护程序启动，消息被放入队列并按计划完全触发我的PHP脚本。脚本运行，一切正常。
队列的配置如下所示： SQS configuration
但是经过一段时间的处理（脚本仍然忙碌 - 并且不是下一次调度的运行^^），会打开第二条消息，执行相同脚本的另一个实例，另一个执行另一个，另一个。间隔5分钟。
我怀疑，消息不会从队列中删除（尽管我确保脚本发回状态200），如果脚本运行时间过长，最终会创建新消息。
有没有办法阻止其他邮件的产生？告诉队列或sqs守护进程不要创建新的flighing消息？我是否必须删除代码中的消息？虽然教程声明它应该自动发生
我想触发脚本，从队列中删除消息并让脚本运行。请不要使用花哨的后备/重试机制： - ）
我花了很多时间试图在互联网上找到一些东西。不成功。任何帮助表示赞赏。
由于
答案 0 :(得分：1)
打开第二条消息，执行另一个相同脚本的实例，另一个，以及另一个......以恰好5分钟的间隔执行。
我怀疑这是第二条消息。我相信它是相同的消息。
如果您在非活动超时到期之前没有回复200 OK，那么该消息将返回队列，是的，您将再次收到该消息，因为系统认为您已经崩溃，你想再看一遍。这是设计的一部分。
您收到的X-Aws-Sqsd-Receive-Count请求标头会告诉您当前消息的传送次数大约是多少次。 X-Aws-Sqsd-Msgid请求标头标识唯一消息。
如果您无法确保脚本在超时之前完成，那么这可能不是此服务的合适用例。听起来服务工作正常。
答案 1 :(得分：0)
查看the Worker Environment documentation，了解有关可配置值的详细信息。您可以配置多个不同的超时值以及“最大重试次数”，如果设置为1将阻止重新发送。但是，您的死信队列将填满实际处理成功的邮件，因此这可能不是您的最佳选择。
答案 2 :(得分：0)
我知道这并没有直接回答你关于配置的问题，但我遇到了类似的问题 - 我的队列配置设置与你的完全一样，在我的Elastic Beanstalk设置中，我设置了{ {1}}到Visibility Timeout秒（或半小时）和1800到Max Retries。
如果一个作业运行超过一分钟，它会再次运行然后被抛入死信队列，即使每次从应用程序返回200 OK之后。
几个小时后，我意识到Nginx服务器正在超时 - 检查Nginx错误日志产生了这种洞察力。我不知道为什么Elastic Beanstalk在这种情况下包含Web服务器...您可能想要检查EB是否在您的应用程序前面生成Web服务器，如果所有其他方法都失败了。
