Брокер сообщений для сервисной архитектуры на базе ZMQ — или отдых разработчика

У нас как IDENT используется UUID, при этом он не задействован нами в какой-то логики, а скорее как адрес сервиса для правильного роутинга пакета по кластеру. Если его не задавать самому вручную, то он будет сгенерен автоматически, при этом сталкивался с коллизиями идентов, созданных разными машинами.

У нас по большей части php (php-zmq), c++ (cppzmq) и java через jzmq

Брокер сообщений для сервисной архитектуры на базе ZMQ — или отдых разработчика

Серебрянной пули нет.

Приходится выбирать между высокой производительностью/пропускной способностью, которую дают brokerless решения вроде ZeroMQ и его детищ — nanomsg и crossroads, и стабильностью/надежностью/гарантией доставки, которые дают брокеры — RabbitMQ, ActiveMQ, Redis (с оговорками), NATS и остальные.

Есть отличный материал со сравнением и тестами многих систем — Dissecting Message Queues

Crossroads I/O и NanoMSG в какой-то степени детища ZeroMQ. Первое — форк, который сначала забросили, потом с помпой возобновили и опять забросили.
Второе — детище одного из разработчиков ZeroMQ, которое исправляет многие недочеты прародителя, но при этом приносит свои и исповедует все ту же идеологию ZMQ — библиотека сама знает, как лучше отправлять, ибо умнее ее пользователей.

Nanomsg, как и zmq, гарантирует атомарность доставленных сообщений и их порядок, при этом не гарантирует саму доставку. При потере части разделенного сообщения оно все будет дропнуто получателем, сообщения могут не доходить вообще (о чем я писал выше). При этом автор (Martin Sustrik) ясно дает понять, что чинить это никак не собирается:

Guaranteed delivery is a myth. Nothing is 100% guaranteed. That’s the nature of the world we live in. What we should do instead is to build an internet-like system that is resilient in face of failures and routes around damage.

Во многих аспектах nanomsg интереснее, модульнее и проще для разработчика, но с моей точки зрения это такой же черный ящик для мониторинга в проде. И если ZMQ проект уже устоявшийся, обладает большим комьюнити, которое большую часть «особенностей» уже выявило и опубликовало решения на том же StackOverflow, то Nanomsg штука свежая, комьюнити небольшое, и чего от него ждать при нагрузке в боевых условиях я не знаю.

Ну и кому интересно, есть отличный обзор Nanomsg на том же ресурсе — A Look at Nanomsg and Scalability Protocols

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

Если подытожить:
Надо быстро и допустимы потери: brokerless решения — ZeroMQ, NanoMSG, Crossroads I/O
Надо надежно и можно подождать: брокеры — RabbitMQ, ActiveMQ, RATS, etc

Брокер сообщений для сервисной архитектуры на базе ZMQ — или отдых разработчика

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

Первое, что нужно продукту при выходе в прод — мониторинг, желательно всего и вся, чтобы потом не было мучительно больно.
И вот на этом этапе у ZMQ все не так хорошо, как казалось бы:

• Узнать состояние сооединения с клиентом/другим сервисом через API библиотеки невозможно. Эта информация скрыта от пользователя by design. Отлаживать проблемы связи между компонентами вашего приложения, особенно если оно немаленькое и компонентов сильно больше двух, становится задачей нетривиальной
• Точно так же скрыта от разработчика информация об количестве сообщений в очередях получения/отправки IO-процессов. Благодаря этому даже мягко (gracefully) завершить процесс не получится, т.к. приложение не знает, все ли входящие сообщения уже обработаны и все ли исходящие отправлены. И если с входящей очередью можно разобраться алгоритмически, добавив пару-тройку сервисных сообщений между сервисами, то с исходящей очередью все плохо.
• Продолжение предыдущего пункта — невозможно закрыть соединение с другими сервисами. Никак. ZMQ решает это за вас, и считает что при этом умнее. Как показывает практика, не всегда
• А если соединение все-таки закрылось, даже самым похабным образом (exit(1), die, etc) — вторая сторона об этом никогда не узнает, и будет дальше слать сообщения (которые дропнутся на выходе из приложения-отправителя, молча — ZMQ умный же), или ждать ответа от помершего сервиса. Единственный метод решения — повальный heartbeat между сервисами.
• ZMQ_IDENTITY. Еще одна замечательная опция от создателей ZMQ. Честно идентифицирует отправителя, но если вы решили использовать её для адреса сервиса в кластере, то это зря. Если ваш сервис по какой-то причине решит помереть, а потом восстать из пепла (банально — при обновлении версии софта), после чего представится старым идентом и будет ждать сообщений, то получит он шиш. Ибо ZMQ умный же, да. Единственное, что поможет в такой ситуации — рестарт всех сервисов, которые сотрудничали с перезапущенным, что в реальной жизни значит рестарт всего кластера.

Что в итоге
Библиотека просто отлична для прототипирования проекта и для быстрой разработки PoC-решений.
В проде тоже, в общем-то, жизнеспособна, за вычетом того, что подводных камней количество немалое.

Если опыта работы с ZMQ мало, а в прод пустить хочется, то готовьтесь к веселому дебагу по ночам, а лучше подумайте еще раз.
Если опыт есть — почему бы и нет, зато хорошо прокачаете скилл построения протоколов без потерь сообщений; термины heartbeat, «нумерация пакетов», распределение нагрузки и масштабирование больше не будут пустыми звуками, а резюме будет выглядеть куда круче :)

ЗЫ: Меня зовут Денис и я алкоголик с ZMQ в проде больше двух лет.

Автоматизация монтирования samba-разделов в Mac OS

get_inet_pwd () {
  security 2>&1 >/dev/null find-internet-password -gl $1 \
  |ruby -e 'print $1 if STDIN.gets =~ /^password: "(.*)"$/'
}

можно спокойно заменить на

security find-internet-password -gwl $1

ибо
-w Display only the password on stdout

BMW делает ставку на беспилотные автомобили

Всякие i-Stop иже с ними работают только если температура за бортом выше нуля

Ещё раз о невероятной лояльности службы поддержки Logitech

Телефон постоянно трется о ткань в кармане. Но вот что нужно делать мышке, чтобы за полгода ее так уработать?

У меня уже более полутора лет Razer Mamba, используется довольно интенсивно, при этом выглядит как новая.

Идея удобного перемещения курсора и выделения для мобильных интерфейсов

При тапе на статус-бар вверху экрана список прокручивается на начало.

Мой субъективный опыт работы с SSD

OCZ Vertex 2 120 Gb больше полугода — нареканий нет (вопреки всему, что писали)

Бамбуковые «колонки» для iPhone от отечественного дизайнера

Один динамик на нем:

Миллиард таблиц?!

для таких случаев есть EAV — количество таблиц равно количеству типов атрибутов

Подборка генераторов CSS

а это стимул такой: не делай как мы, делай красиво :)

ICQ баг-информер на PHP + ActiveMQ

Похоже, что фразу «Так сложилось исторически» любят в каждой компании :)

Скорость разработки

Мозг ей надо. Но только если своего нет — сверху не прилепишь

Есть к чему стремиться, %username%

вместо того, чтобы комменты писать, тоже что-то полезное можно делать

Подарок копипастеру

Как по мне, так лучший метод научиться слепому набору — ноут-американец или клавиатура типа das keyboard. Только первое мне и помогло :)

Заглушка для IE6 под Drupal 7

А ничего, что сабы по умолчанию выключены, и человек, который не знает что такое браузер, еще должен найти как их включить?

Первое предупреждение от Sony

Беда только в отсутсвии [...] поддержки файловой системы ntfs, для просмотра чего-нибудь hd'шного

А как там с поддержкой HFS/HFS+ и Ext3/Ext4? Так же плохо, как и с NTFS?

Сколько денег в кармане Opera

В третий пункт еще можно добавить дефолтные закладки и иконки в SpeedDial

Hosting.UA и очередная проблема

Дело не в Украине, а в хостере — в той же Воле саппорт куда адекватнее. Вплоть до того, что сами звонят тебе, если вдруг перестал откликаться один из серверов.

Hosting.UA и очередная проблема

спрашивали ссылку на проект, а не на хостинг :)