Сельдерей SQS + Дублирование заданий + Тайм-аут видимости SQS

Question

Большинство моих задач Celery имеют ETA дольше максимального максимального времени видимости, определенного Amazon SQS.

сельдерея documentation говорит:

Это вызывает проблемы с ETA/обратный отсчет/повторами задач, где время выполнения превышает таймаут видимости; на самом деле, если это произойдет, то будет выполнен снова и снова в цикле.

Таким образом, вам необходимо увеличить тайм-аут видимости, чтобы соответствовать времени самой длинной ETA, которую вы планируете использовать.

В то же время он также говорит, что:

Максимальный таймаут видимости поддерживается AWS от написания этой статьи 12 часов (43200 секунд):

Что я должен сделать, чтобы избежать многократного выполнения задач у моих работников, если я использую SQS?

Answer 1

Как правило, это не очень хорошая идея иметь задачи с очень длинными ETA.

Прежде всего, существует проблема «visibility_timeout». И вы, вероятно, не хотите очень большой тайм-аут видимости, потому что, если рабочий сработает за 1 минуту до того, как задача вот-вот начнется, очередь будет по-прежнему ждать завершения видимости_timeout перед отправкой задачи другому работнику, и, я думаю, вы не хотите это будет еще 1 месяц.

От сельдерея Документов

Обратите внимание, что сельдерей будет возвращать сообщения на рабочей остановке, так что наличие длинный тайм-аут видимости только задержать Redelivery из «потерянных» задач в случае сбоя питания или принудительно прекращено работников.

А также, SQS допускает, что в списке должно быть столько задач.

SQS называет эти задачи «Сообщениями о вспышках». От http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html:

сообщение считается находящимся в полете после того, как он получил от очереди потребителем, но не удаляется из очереди.

Для стандартных очередей может быть не более 120 000 информационных потоков сообщений в очереди. Если вы достигнете этого предела, Amazon SQS вернет сообщение об ошибке OverLimit. Чтобы избежать ограничения, вы должны удалить сообщения из очереди после их обработки. Вы можете также увеличить количество очередей, используемых для обработки сообщений.

Для очередей FIFO может быть не более 20 000 сообщений в полете в очереди. Если вы достигнете этого предела, Amazon SQS не возвращает сообщение об ошибке .

Я вижу два возможных решения, вы можете использовать либо RabbitMQ вместо этого, который не делает полагаться на видимость тайм-аута (есть «RabbitMQ как сервис» услуги, если вы не хотите, чтобы управлять самостоятельно) или изменить свой код, чтобы иметь действительно небольшие ETA (лучшая практика)

Это мои 2 цента, возможно, @asksol может предоставить дополнительную информацию.