Как лучше организовать работу с worker серверами чтобы они сами брали работу из пула или мастер сервер им дает работу?

Question

[Константин Т]

Есть пулл серверов из 15-20 серверов из них один выделен для фронта, остальные для тяжелой работы.

под тяжелой работой я подразумеваю долгие задачи использующие почти всю мощность процессора и оперативной памяти, задачи могут быть запущены параллельно на одном сервере т.е. может одновременно работать 4-8 задачи количество зависит от load overage сервера.

Так вот, пул задач хранится на фронт-сервере который принемает запросы от пользователей. Как лучше организовать распределение задач между серверами, я пока вижу 2 варианта и не могу определиться какой лучше: (далее мастер-сервер это фронт сервер)

1. Каждый worker сервер, смотрить на свой load average, и до тех пока он не пиковый опрашивает мастер сервер на наличие задач, если появляется задача он ее хватает и говорит матер-серверу о том что это задача теперь его и другие серверы не должны заниматься ей впредь
   
2. Мастер сервер смотрит по статистике которую ему передает каждый воркер, какой воркер сейчас наименее загруженный и дает задачу ему и сам рулит процессами распределения задач
   

Минус первого подхода в том что могут возникнуть коллизии и 2 сервера могу взять одновременно задачу на себя и будут выполнять двойную работу, по этому я больше склонен считать что 2 вариант подходит, но может я ошибаюсь или чего-то не учел? Или может есть 3 вариант?

Answer 1

[jacob1237]

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

Зависит от технологий, которые Вы собираетесь использовать. У Вас в варианте №1 структура данных с задачами для воркеров будет называться распределенная очередь (shared queue). У этой структуры данных как раз-таки основная задача - раздавать данные юнитам, предотвращая дублирование и негативные эффекты типа race condition и т.д.

В разных программных пакетах реализуется по-разному. Порекомендую глянуть например на Beanstalkd, где все Ваши проблемы уже решены, либо воспользоваться встроенной в Redis структурой данных List. Она в принципе то что нужно и делает.

Однако преимущество Beanstalkd будет в том, что он специально заточен именно под очереди задач: поддерживается сортировка задач в заданном числовом порядке, резервирование задач, автоматическое снятие резерва при превышении времени на обработку и др.

Плюс предусматривает возможность хранения задач на жестком диске (с ключом -b) помимо хранения в памяти (что в Redis реализуется только через слепки (snapshot), либо через полный лог операций - что не есть оптимальный вариант).

Comments

[Константин Т]

jacob1237 Большое вам спасибо! Этот способ наиболее подходящий, т.к. worker теперь независим, их можно теперь добавлять и удалять без лишних регистраций на мастер сервере! Отличное решение спасибо!

Answer 2

[Макс]

да в общем однофигственно. Организуйте лок задачи, пока ее кто-то забирает - и pull будет работать корректно. Не хотите - делайте push.
а можно нечто среднее - воркер периодически говорит "я готов взять следующее", мастер ему пихает задачу.
И мастер не долбит воркера запросами "как дела?" и воркер не получит уже запущенную задачу.
т.е. очередью управляет мастер, отчет о состоянии создает воркер

Comments

[Константин Т]

Макс Второй вариант как раз это и делает, он не будет долбить каждый воркер, потому что каждый воркер складывает в redis свою инфу и мастер просто смотрит в redis и делает выводы, т.е. вы за 2 вариант?

[Константин Т]

Макс а если бы ты делал лок задачи, как бы ты это делал? забирается задача в доли секунды по апи и в теории в эту долю секунды оба сервера могут ее забрать, как тут сделаешь лок?