Реализация шины сообщений с использованием ZeroMQ

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

Для этого я использую ZeroMQ через TCP. Шаблон - PUB-SUB с форвардером. Моя шина работает как отдельный процесс, и все клиенты подключаются к SUB-порту для приема сообщений и PUB для отправки сообщений. Каждый процесс подписывается на сообщения уникальным тегом. A send вызов от процесса отправляет сообщения всем. A receive вызывает получение этого процесса сообщений, помеченных тегом этого процесса. Это нормально работает.

Теперь мне нужно обернуть материал ZeroMQ. Мои клиенты должны предоставить уникальный тег. Мне нужно поддерживать глобальный список тегов по сравнению с параметрами контекста и сокетов ZeroMQ. Когда клиент говорит, initialize_comms("name"); Шина должна проверить, уникально ли это имя, создать контексты и сокеты ZeroMQ. Точно так же, если клиент говорит receive("name");, шина должна получать сообщения с этим тегом.

Подводя итог проблемам, с которыми я столкнулся;

  • Нужно ли все-таки добиться этого, используя средства, предоставляемые ZeroMQ?
  • Является ли ZeroMQ правильным инструментом для этого, или я должен искать что-то вроде nanomsg?
  • Является ли PUB-SUB с форвардером правильным шаблоном для этого?
  • Или я здесь что-то не хватает?

ОТВЕТЫ

Ответ 1

Ответы

  • Да, ZeroMQ способен удовлетворить эту потребность

  • Да. ZeroMQ - это правильный инструмент (а скорее мощный инструментарий с компонентами с малой задержкой). В то время как nanomsg имеет прямой примитив для шины, основная распределенная логика может быть интегрирована в инфраструктуру ZeroMQ

  • Да и Нет. PUB-SUB, как указано выше, может служить для эмуляции "крик-литой" -то-шины и основываться на побочном эффекте SUB использования ключа (ов) подписки. ВЕСЬ ОТДЕЛЕНИЕ логики нужно передумать и спроектировать так, чтобы весь объем изготовления соответствовал вашим планам (см. Ниже). Также любезно помните, что в начальных версиях ZeroMQ использовался примитив PUB/SUB как "фильтрация подписки" входящего потока сообщений, выполняемых со стороны приемника, поэтому массивные проекты должны проверять на объемы трафика/наводнение/неэффективность процесса в массовом масштабе...

  • Да. ZeroMQ - довольно хорошо настроенная основа примитивных элементов (поскольку архитектура обсуждается, а не мощность и производительность) для создания более умных, более надежных и почти линейно масштабируемых формальных шаблонов связи. Не зацикливайтесь на примитивах PUB/SUB или PAIR после рисования Архитектуры. Любой дизайн будет оставаться слабым, если вы забудете, откуда исходят True Powers.

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

Таким образом, лучший следующий шаг, который можно сделать, - это ИМХО, чтобы получить более глобальный вид, который может казаться сложным для первых нескольких вещей, которые один пытается кодировать с помощью ZeroMQ, но если вы по крайней мере перейти на страницу 265 [Код подключен, том 1] [доступно asPdf → > http://hintjens.wdfiles.com/local--files/main%3Afiles/cc1pe.pdf], если бы это было не так, шаг к этому.

Самая быстрая кривая обучения должна состоять в том, чтобы сначала просмотреть незакрытый вид в обновленной версии Fig.60 Republishing Updates и Рис .62 HA Clone Server для возможный подход с высокой доступностью, а затем вернуться к корням, элементам и деталям.

Ответ 2

Вот что я в конечном итоге конструировал, если кто-то заинтересован. Спасибо всем за советы и указатели.

  • У меня есть шина сообщений, реализованная с использованием ZeroMQ (и CZMQ) как отдельный процесс.
  • Образец - ИЗДАТЕЛЬ-АБОНЕНТ с СПИСОК. Они подключены с помощью PROXY.
  • Кроме того, есть ROUTER, вызываемый с использованием нового разветвленного потока.
  • Эти три конечных точки работают на TCP и связаны с предопределенными портами, о которых знают клиенты.
  • PUBLISHER принимает все сообщения от клиентов.
  • SUBSCRIBER отправляет сообщения с уникальным тегом клиенту, который подписался на этот тег.
  • LISTENER прослушивает все проходящие сообщения. в настоящее время это для тестирования и целей ведения журнала.
  • ROUTER предоставляет клиентам отдельный канал связи. Такие сообщения, как управляющие команды, направляются сюда, чтобы они не передавались ниже по течению.
  • Клиенты подключаются,
    • PUBLISHER для отправки сообщений.
    • ПОДПИСАТЬ, чтобы получать сообщения. Подписка использует уникальные теги.
    • ROUTER для отправки команд (проверка уникальности тегов и т.д.)

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