Какой будет правильный шаблон ZMQ? - PullRequest
Новая
       87

Какой будет правильный шаблон ZMQ?

1 голос
/ 02 августа 2020

Я пытаюсь создать шаблон ZeroMQ, где:

  1. Может быть много клиентов, подключающихся к одной конечной точке сервера
  2. Сервер будет распределять входящие клиентские задачи среди доступных рабочих (будет быть сопоставленным количеству ядер на сервере)
  3. Эти задачи выполняются долго (в часах) и должны выполнять много локальных операций ввода-вывода
  4. Во время выполнения каждой задачи (итерация) будут передаваться данные / сообщения (потенциально в порядке [GB] с) между клиентом и работником сервера
  5. Работники клиента и сервера должны знать, есть ли сбои / ошибки на стороне однорангового узла , чтобы они могли восстановиться (повторить попытку) или корректно завершить работу и повторить попытку позже

Исходя из вышеизложенного, я полагаю, что шаблон ROUTER/DEALER будет полезен. PUB/SUB отбрасывается, поскольку мне нужно знать, выходит ли из строя одноранговый узел.

Я пробовал использовать различные комбинации шаблона ROUTER/DEALER, но я не могу гарантировать, что несколько сообщений от клиента достигнут одного и того же рабочего в пределах итерация. Я понимаю, что мне нужно реализовать брокер / пересылку / устройство, которое направляет входящие сообщения правильному получателю / обработчику / работнику. Но я не могу сопоставить сокеты внешнего и внутреннего интерфейса в брокере. Я смотрю на шаблон MajorDomo, но полагаю, что должна быть более простая модель брокера, которая могла бы просто направлять сообщения назначенному исполнителю. (на самом деле не попадаю в службы)

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

1 Ответ

0 голосов
/ 03 августа 2020

Q : «Что будет правильным ZMQ Pattern?»

В случае, если вы никогда не работали с ZeroMQ ,
, здесь вы можете впервые взглянуть на "ZeroMQ: Принципы менее чем за Пять секунд "
до
углубление в подробности

Исходя из сложной композиции всех требований, изложенных в пунктах 1-5,
смею сказать,
Правильно будет НЕ для использования единственного
стандартных, встроенных, тривиальных примитивных ZeroMQ Образцов архетипа связи, а для создания многоуровневой c специфической для приложения композиции из ( M + N + 1 с горячим резервом - достаточно надежная?) (Самонадежная?) Инфраструктура сигнализации и обмена сообщениями, которая покрывает все ваши текущие (и, возможно, расширяемые для любого будущего) требования на уровне приложений, как показано здесь для упрощения вариант использования, где был реализован простой удаленный SigKILL.

enter image description here

Yes, the best would be to create ( and maintain ) your own formalised signalling, that the application level can handle and interact across -- like the heart-beating for detecting dead-worker(s) + permitting to re-instate such failed jobs right on-detected failures (most probably re-located and/or re-scheduled to take place & respective resources not statically pre-mapped, but where physically most feasible at the re-instating moment of time - so even more telemetry signalling will help you decide about the re-instating of the such failed micro-jobs).

ZeroMQ is a fabulous framework right for such complex signalling and messaging hiearachies, so your System Architect's imagination is the only ceiling in this concept.

ZeroMQ will take the rest and do all the hard work nice and easily.

Examples ?

Feel free to follow примеры и обсуждения из прошлого около ~ 6 лет, которые были достигнуты и, надеюсь, помогли примерно 1 300 000 StackOverflowers.

...