Масштабируемая динамическая обработка очереди заданий

Question

В настоящее время я работаю над проектом, в котором мне нужно обрабатывать большое количество повторяющихся заданий. Обычно, когда работа закончена, я хочу начать ее снова через 15 минут.

Набор заданий динамически меняется со временем, и поэтому мне нужно будет отслеживать новые и удаленные задания. Каждая работа может занять некоторое время, поэтому мне нужно иметь возможность масштабировать. У меня будет веб-сайт для управления этими заданиями.

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

Есть несколько очень очевидных проблем с этой настройкой:

• "Брокер заданий" является узким местом и единой точкой отказа
• Очень частый запрос MongoDB к потенциально огромной коллекции кажется плохим решением.

Я не ограничен этой технологией, но я просто не знаю, как мне планировать архитектуру для этого. Есть идеи?

Answer 1

Один из вариантов, который вы можете рассмотреть, это beanstalkd .Это рабочая очередь, которая поддерживает приоритеты и отложенное выполнение.Последняя функция может быть отлично подходит для того, что вам нужно.Позволяет отправить в очередь задание, которое не будет готово для использования работником в течение указанного количества секунд.Вы можете использовать это для повторной отправки задания, которое будет использовано через 15 минут.

Существуют клиентские библиотеки практически для каждого языка.См. Список .Протокол прост и удобен в использовании.

Мы используем его на работе и иногда заполняем очереди сотнями тысяч рабочих мест без каких-либо проблем.На самом деле я не помню, чтобы когда-либо возникали проблемы со стабильностью при использовании более 2 лет.

Answer 2

Использовать AMQP.Для каждого типа работника есть очередь, которая передает задания этому работнику через сообщение.Но добавьте еще один рабочий тип, задерживающий.

Каждый работник получит сообщение, выполнит работу, подтвердит свое сообщение и отправит сообщение задерживающему.

Задержка немного отличается, потому что она получает сообщение, задерживает 15минут, затем отправьте сообщение обратно работнику-источнику и затем подтвердите его.Поскольку задержка по своей сути блокирует, у вас должно быть много процессов задержки, чтобы сообщения не задерживались в очереди, а только тогда, когда они находятся в руках задерживающего.