Стратегия подсчета повторных заданий SQS / task-queue?

Question

Я реализую очередь задач с помощью Amazon SQS (но я думаю, что этот вопрос относится к любой очереди задач), где от работников ожидается, что они предпримут разные действия в зависимости от того, сколько раз работа уже была повторенапереместите его в другую очередь, увеличьте время ожидания видимости, отправьте уведомление ... и т. д.)

Каков наилучший способ отслеживать количество неудачных заданий?Я хотел бы избежать необходимости иметь централизованную базу данных для работы: записи повторных подсчетов.Должен ли я смотреть на время, проведенное в очереди вместо этого в процессе мониторинга?ИМО, который в лучшем случае был бы уродливым или нечистым, перебирая задания, пока не найду древние ..

спасибо!Андраш

Answer 1

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

http://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html

Answer 2

Я добился большого успеха, комбинируя SQS с SimpleDB.Он «централизован», но только настолько, насколько SQS.

Каждая работа получает запись в simpleDB и задачу в SQS.Вы можете поместить любую информацию, которая вам нравится, в SimpleDB, например, время создания вакансии.Когда работник извлекает задание из очереди, он может получить соответствующую запись из simpleDB, чтобы определить ее историю.Вы можете видеть, сколько лет заданию, и сколько раз его пытались выполнить.Когда вы закончите, вы можете добавить рабочие данные в запись SimpleDB (время завершения, результат, журналы, ошибки, трассировка стека и т. Д.) И подтвердить сообщение из SQS.

Я предпочитаю этот метод, потому что онпомогает диагностировать неисправности, предоставляя множество отладочной информации для сбойных задач.Это также позволяет работникам обрабатывать работу по-разному, в зависимости от того, как долго работа была поставлена ​​в очередь, сколько отказов у ​​нее было и т. Д.

Это также дает вам возможность напрямую запрашивать SimpleDB и вычислять такие вещи, как среднее время зазадание, процент отказов и т. д.

Answer 3

Amazon только что выпустил Simple Serice Serice (SWF), который вы можете представить как более сложную / гибкую версию очередей задач GAE.

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

Оформить заказ http://docs.amazonwebservices.com/amazonswf/latest/developerguide/swf-dg-intro-to-swf.html для обзора.

Answer 4

SQS расшифровывается как «Простая служба очереди», которая, по сути, является неправильным названием этой службы. Первая и главная особенность «Очереди» - это FIFO (First in, First out), а в SQS этого нет. Просто хочу уточнить.

Кроме того, в службах очередей Azure этого также нет. Для лучшей службы облачной очереди используйте служебную шину Azure, поскольку это концепция ИСТИННАЯ очередь.