ZeroMQ: сокеты по-новому

[selenite]

— ZeroMQ давно форкнут в более активно развивающийся проект Crossroads и официально почти мертв (идет поддержка, но не развитие)
— для C# есть версия на .NET — NetMQ, которая не требует носить за проектом р̶̶̶а̶̶̶с̶̶̶п̶̶̶р̶̶̶о̶̶̶к̶̶̶л̶̶̶я̶̶̶т̶̶̶у̶̶̶ю̶̶̶ ̶̶̶.̶d̶l̶l̶ библиотеку (да, нужно таскать .dll-сборку, но ее при желании проще засунуть в ресурсы/код проекта, чем нативную .dll)

[aleks_raiden]

Crossroad I/O был попыткой сделать улучшенный ZeroMQ, но не вышло и проект заброшен (https://github.com/crossroads-io/libxs последний коммит почти год назад). Как верно сказали дальше — сейчас активно развивается nanomsg в котором решили многие из существенных проблем ZeroMQ. мы сейчас как раз переводим часть системы от ZMQ на nanomsg именно из-за этих сложностей. Выглядит очень мощно, хотя некоторые из фич zmq там нет.

Однак и хоронить ZMQ рано — активно развивается, хоть и без Мартина, уже и 4 стабильная и пилится дальше.

[selenite]

Вот что бывает, когда перестаешь следить за апдейтами; а впрочем, мой коммент все равно на пару лет актуальнее статьи.

[nicolausYes]

Crossroads вроде как тоже уже мертв (и еще). А ZeroMQ перезагружают и переписывают на С (проект nanomsg).

[grossws]

Дополню, для java есть JNI-обертка для zmq — jzmq, которая упоминается в посте, но она не очень удобна (иногда требует пересборки при обновлении java).

Также есть jeromq на чистой java, которая чуть менее производительная и не поддерживает протоколы ipc:// и pgm://. Первый не поддерживается, т. к. в java не поддерживает unix-domain socket'ы (и между jeromq эмулируется через tcp), второй — т. к. автор не нашел соответствующей библиотеки под java.

[grossws]

Про обмен через файлы в наши годы уже стыдно говорить, но и такое случается.

А что хранит файлы лучше, чем файловая система (возможно, распределенная)? Хранить, например, относительно тяжелые файлы (скажем, со средним размером 100к) в БД уже накладно. Особенно, если с ними работают как с файлами. Не говоря уже про всякие развлечения типа mmap'а.

[nitro2005]

Про хранение — спору нет. Речь про методы обмена между приложениями или его частями.
Работаю в сфере где все очень консервативно и направлено на максимально быстрое написание кода, зачастую это как раз через файлы. Одно приложение положило сообщение в файл, другое — сканирует каталог и забирает сообщения из файлов. Вот так вот, в 21-м веке :)

[grossws]

Тут стоит вспомнить особо энтерпрайзные bash-скрипты.

Сложно не согласиться, что в качестве границы обмена между разными системами при интеграции это может быть наиболее дешево, сердито и надежно. Как с точки зрения технологической (и на этой, и на той стороне интеграции могут быть идиоты), так и с административной (количество бумажного геморроя для подключения к какой-нибудь базе/esb в большой организации может быть довольно большим).

[nitro2005]

Дешево и сердито — да. Насчет надежности вопрос спорный. Там уже вопрос упирается в тип сетевой файловой системы. Было много негативного опыта, когда админы настраивали NFS, не удосужившись даже слегка погрузиться в настройки. А между тем по-умолчанию процесс, обращающийся к точке монтирования NFS в режиме hard в случае потери связи с файл-сервером тупо виснет, а в случае если выключена опция intr, виснет очень хорошо. С Samba и CIFS тоже немало глюков. Плюс сложности с резервированием.
Вобщем эта экономия приносит немало бед эксплуатирующему персоналу.

[Googolplex]

Автор ZeroMQ сейчас занимается разработкой nanomsg, которая, как я понимаю, есть «ZeroMQ done right». Вот здесь рассказывается об отличиях nanomsg и ZeroMQ.

[HDDimon]

Автор, а чем данный подход превосходит подход с использованием шины данных? то есть в случае использования rabbitMQ(как пример) получаем из коробки гибкую возможность масштабирования, конфигурирования, управления очередями, гарантии доставки тд. Я понимаю что в этом случае уровень абстракции гораздо выше, но и плюшек гораздо больше он привносит.

[nitro2005]

В большинстве случаев не нужен Ворд, чтобы написать записку соседке по парте :)
Пока мной RabbitMQ толком не изучен, поэтому и писать нечего.

[Googolplex]

Всё просто — для раббита и аналогичных MQ вам нужно запускать отдельный демон, вероятно, даже на отдельной машине. Соответственно, там в комплекте есть куча возможностей, как вы уже заметили. Но это ещё одно звено в вашем приложении.

ZeroMQ же (и nanomsg, и другие последователи) — это «сокеты на стероидах», тонкий слой абстракции поверх BSD-сокетов. Дополнительные (сверх обычных сокетов) возможности там довольно низкоуровневые, но для ZeroMQ не требуется дополнительных программ. Вся функциональность линкуется в виде библиотеки (довольно маленькой, кстати) в вашу программу.

Пример, зачем оно в принципе нужно. Есть такая среда, IPython, которая, помимо всего прочего, предоставляет возможность создания красивых фронтендов к ней, типа веб-приложения в браузере. Общение между BE и FE ведётся с помощью ZMQ. Настоящий брокер сообщений, как можно себе представить, был бы здесь просто overkill'ом.

[vit1251]

Следует помнить, что MQ имеет преимущества в виде хранения данных в своей очереди, а в случае падения вашего приложения данные в ZeroMQ будут утеряны. Опять таки уровень абстракции немного пугает тем что неясно как выяснить в ZMQ: кто подключился, он все еще подключен и т.д. Насчет nanomsg существует мнение, что он еще не готов для промышленного использования. Опять такие сложность протокола своидит на нет ZMQ против например очередей в том же Redis. Одним словом в копилку, но хотелось бы от статьи ответов на поставленные в ней же вопросы.

[Googolplex]

Просто ZeroMQ — это не MQ, несмотря на его название. Это просто слой абстракций над сокетами, применяемый там, где сокеты — это слишком низкоуровнево, а полноценные очереди сообщений и аналогичные системы — уже overkill. Их некорректно сравнивать, это совершенно разные инструменты.

[erthad]

Скорость передачи, например, где latency критична.

[Googolplex]

del