Использование MySQL в качестве очереди заданий

Question

Я бы хотел использовать MySQL как очередь заданий. Несколько машин будут производить и потреблять рабочие места. Рабочие места должны быть запланированы; некоторые могут работать каждый час, некоторые каждый день и т. д.

Это кажется довольно простым: для каждого задания есть столбец «nextFireTime», и рабочие машины ищут работу с помощью nextFireTime, меняют статус записи на «inProcess», а затем обновляют nextFireTime, когда задание заканчивается.

Проблема возникает, когда работник умирает молча. Он не сможет обновить nextFireTime или вернуть статус в состояние «бездействия».

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

Кто-нибудь может предложить шаблон проектирования, который бы правильно обрабатывал ненадежные рабочие машины?

Answer 1

Использование MySQL в качестве очереди заданий обычно заканчивается болью, так как это очень плохо подходит для обычных целей СУБД. Пользователь 'toong' уже связан с https://www.engineyard.com/blog/5-subtle-ways-youre-using-mysql-as-a-queue-and-why-itll-bite-you,, который может рассказать о нем много интересного. Ненадежные работники являются лишь одним из осложнений.

Существует множество систем управления распределением заданий, в основном отличающихся сложностью их возможностей организации очередей и планирования. На простом конце FIFO есть такие вещи, как Resque, Celery, Beanstalkd и Gearman; на сложном конце находятся такие вещи, как GridEngine, Torque / Maui и PBS Pro. Я настоятельно рекомендую новую систему Amazon Simple Workflow, если вы можете терпеть зависимость от сервиса Amazon (я считаю, что не требует, чтобы вы были в EC2).

К вашему первоначальному вопросу: сейчас мы внедряем супервизор для каждого узла, который может определить, все ли еще заняты узлы, и, если это так, отправляет сердцебиение на монитор заданий. Это боль, но по мере того, как вы обнаруживаете и будете продолжать обнаруживать, есть много деталей и случаев ошибок, которыми нужно управлять. В основном, однако, я должен побудить вас сделать себе одолжение, узнав об этой области и с самого начала правильно построив систему.

Answer 2

Может быть так

Когда работник выбирает работу, он может добавить свой идентификатор процесса или другой уникальный идентификатор в поле в работе

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

То есть, другими словами, сторож работает с рабочими процессами, а не с самими заданиями.

Answer 3

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

Другой вариант - не иметь больших рабочих мест. Разбейте длительно выполняемые задания на промежуточные этапы. Если задание длится дольше (скажем) 1 минуты, сохраните промежуточные результаты как новое задание (с некоторой ссылкой на старое задание), чтобы новое задание можно было снова поставить в очередь. сделать еще одну минуту работы.