2017-02-15 18 views
0

Все,Amazon Elastic Beanstalk работник cronjob (SQS) вызывает то же сообщение несколько раз

У меня есть довольно тревожная проблема с моей Amazon Elastic Beanstalk работником в сочетании с SQS, который, как предполагается обеспечить планирование заданий хрон - все это работает с PHP.

Следующий сценарий - Мне нужен PHP-скрипт, который будет выполняться регулярно в фоновом режиме, что может в конечном итоге работать в течение нескольких часов. Я увидел это замечательное введение, которое, по-видимому, охватывает точный мой сценарий (AWS Worker Environments - см. Раздел «Периодическая задача»)

Итак, я прочитал довольно много howtos и создал EBS Worker с SQS (который фактически выполняется автоматически во время создания рабочего) и предоставил cron config (cron.yaml) в моем пакете развертывания.

Сценарий cron правильно распознается. Демон sqs запускается, сообщения помещаются в очередь и запускают мой PHP-скрипт точно по расписанию. Скрипт запускается, и все работает нормально.

Конфигурация очереди выглядит следующим образом: SQS configuration

Однако по прошествии некоторого времени обработки (сценарий все еще занят - и NO не следующий запланированный запуск ^^) открывается второе сообщение и выполняется другой экземпляр того же скрипта, а другой, а другой ... ровно через 5 минут.

Я подозреваю, что сообщение не удаляется из очереди (хотя я убедился, что сценарий отправляет статус 200 назад), который заканчивается созданием нового сообщения, если скрипт работает слишком долго.

Есть ли способ предотвратить появление других сообщений? Скажите очереди или демону sqs не создавать новые сообщения для бега? Должен ли я удалить сообщение в своем коде? Хотя в учебнике указано, что это должно произойти автоматически

Я хотел бы просто запустить сценарий, удалить сообщение из очереди и запустить скрипт. Никаких причудливых механизмов возврата/повтора пожалуйста :-)

Я провел много часов, пытаясь что-то найти в Интернете. Неудачный. Любая помощь приветствуется.

Благодаря

ответ

1

открывается второе сообщение, а другой экземпляр того же сценария выполняется, и еще, и еще ... ровно через 5-минутными интервалами.

Сомневаюсь, что это второе сообщение. Я считаю, что это то же сообщение.

Если вы не ответите 200 OK до истечения времени бездействия, тогда сообщение вернется в очередь, и да, вы получите его снова, потому что система предполагает, что вы разбились, и вы захотите чтобы увидеть его снова. Это часть дизайна.

Существует заголовок запроса X-Aws-Sqsd-Receive-Count, который вы получаете, который сообщает вам, сколько раз было передано текущее сообщение. Заголовок запроса X-Aws-Sqsd-Msgid идентифицирует уникальное сообщение.

Если вы не можете гарантировать, что сценарий завершится до истечения таймаута, это вряд ли будет подходящим вариантом использования этой службы.Похоже, сервис работает правильно.

+0

Эй, Майкл, спасибо за ответ. Ты прав. Это одно и то же сообщение. Я отправляю 200, как описано здесь [link] (http://stackoverflow.com/questions/15273570/continue-processing-php-after-sending-http-response), но это не обманет демона. Я буду экспериментировать с ним немного больше. В случае, если я не могу отправить 200 достаточно быстро - существует ли способ продлить время ожидания бездействия или предотвратить повторное появление очереди? – Jarek

0

Дополнительную информацию о значениях, которые вы можете настроить, см. В the Worker Environment documentation. Вы можете настроить несколько разных значений тайм-аута, а также «Макс. Попытки», которые, если установлено в 1, будут предотвращать повторные отправки. Тем не менее, ваша очередь мертвых букв будет заполняться сообщениями, которые были успешно обработаны, так что это не лучший вариант.

 Смежные вопросы

  • Нет связанных вопросов^_^