Реализация шаблона обмена сообщениями в ферме задач с помощью zeromq - PullRequest
Новая
       5

Реализация шаблона обмена сообщениями в ферме задач с помощью zeromq

4 голосов
/ 18 октября 2011

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

Это актеры, которых я определила до сих пор в схеме, которую я придумала:

  • Клиент: это субъект, который запрашивает выполнение единицы работы (или «задания»)
  • Контроллер: это актер, который распределяет «задания» по доступным двигателям
  • Engine: это актер, который получает запрос задания от контроллера и публикует результат обратно клиенту.

Я до сих пор не выяснил, как движок возвращает сообщение клиенту. Я предполагаю, что одним из способов реализации этого с использованием zeromq будет:

Клиент:
Сообщения о задании PUSH на одном сокете для контроллера. SUBscribe на завершенные результаты, опубликованные Engine, на другом. Гнездо * * 1 021

Контроллер:
Потяните сообщения о заданиях от клиента на одном сокете. Публикуйте сообщения о заданиях на движки на другом сокете (очевидно, это будет устройство пересылки)

Двигатель:
ПОДПИСАТЬСЯ на рабочие сообщения в одном сокете. Опубликовать результат в другом сокете

Было бы очень полезно, если бы кто-то предоставил скелет / фрагмент, который покажет схему того, как этот шаблон может быть реализован, с использованием фреймворка zeromq.

Фрагмент кода может быть на C, C ++, PHP, Python или C #

[[Изменить]]

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

Было бы очень полезно, если бы кто-то, кто знаком с zeromq, мог набросать скелет, который показал бы, как я могу использовать основные компоненты для создания такой структуры.

Ответы [ 2 ]

5 голосов
/ 11 ноября 2011

Существует множество подходов к этому, и IPython.parallel включает две такие реализации с ZeroMQ - одну простую и чисто zmq, а другую, более сложную, с контроллером, реализованным в Python.

Мы разделили контроллер на двух участников:

  1. Концентратор - удаленный процесс, который видит весь трафик и отслеживаетсостояние кластера, отправка результатов в базу данных и т. д., уведомление клиентов о подключении / отключении двигателя и т. д.
  2. Планировщик - по сути, простое устройство ROUTER-DEALER, которое передаетзапросы от клиентов к механизмам и резервное копирование ответов.

Рассматривая только часть нашей топологии, обрабатывающую задачи:

  • Планировщик являетсяУстройство 0MQ Queue с разъемом ROUTER и DEALER, оба из которых связаны.
  • Клиенты имеют разъемы DEALER, подключенные к планировщику ROUTER
  • Двигатели имеют разъемы ROUTER, подключенные к DE планировщикаALER

, который использует эти два свойства:

  • Запросы балансировки нагрузки DEALERS LRU между одноранговыми узлами
  • Маршрутизаторы используют префиксы идентификации для отправки ответов обратноПир, который сделал определенный запрос.

Игрушечная ферма задач с балансировкой нагрузки с pyzmq, которая маршрутизирует ответы обратно запрашивающему клиенту: https://gist.github.com/1358832

Альтернатива, гдерезультаты отправляются куда-то, но не возвращаются запрашивающему клиенту, это шаблон Ventilator-Sink в Руководстве 0MQ.

3 голосов
/ 18 октября 2011

Это классический параллельный шаблон «ведущий / ведомый» (также известный как «Ферма» или «Ферма задач»).

Есть миллиард способов реализовать это. Здесь есть способ реализовать его с помощью MPI, может быть, он может вдохновить вас на реализацию этого в zeromq.

...