Авторы ZeroMQ отрицают вред

[metaclass]

Сидел читал про ZeroMQ (он, несмотря на отсутствие персистентности, наиболее близок к тому, что мне надо для решения задачи). При этом в гайде попались две ссылки, отрицающие энтерпрайзно-бизнесовый вред:
http://swsi.info/
http://www.imatix.com/articles:whats-wrong-with-amqp/
Особенно весело про amqp, как комитет по его разработке объебался во всех формах, что привело к нескольким плохо совместимым реализациям, которые, в свою очередь, начали диктовать разработку стандарта.

Comments

[mikkim08.livejournal.com]

А что за задача и почему ZeroMQ ? Вдруг и мне тоже надо.

[metaclass.livejournal.com]

Около десятка сервисов, которым нужно обмениваться сообщениями, при этом каналы связи ненадежные, и воткнуть broker-based MQ толком некуда.
Сейчас очередь сделана поверх БД, но это приводит к очень дурному характеру нагрузки на диски+плюс баги Firebird, в итоге много тупого геморроя.

[wildman.livejournal.com]

а не смотрели в таком разрезе мессаджинг поверх redis например?

[hshhhhh.livejournal.com]

ну там subscribe дурацкий и не умеет в оффлайн.
а mq это и есть мессаджинг поверх redis

[gds.livejournal.com]

я тоже взял zeromq сначала -- типа легковесное, биндинги есть, модно, но -- былинный отказ. Мудацкий req-rep по отношению к реконнектам, теряет сообщения, мутные router/dealer.
Кароч взял ocamlmq, научил его встраиваться в процесс (а не висеть отдельным процессом), налепил абстракцию "сервер" (хуйнюшка, к которой можно connect, далее send/recv _сообщений_), сделал переходники между "сервером" и потоком байтиков в tcp/ip, и ocamlmq теперь даёт как по tcp/ip, так и внутри процесса.
Сейчас доделываю абстракцию "клиент-сервер поверх очередей сообщений". Соединения, таймауты, очистка очередей по завершении, реконнекты.
Следующий этап -- умение указывать "вот такие-то очереди локального процесса копируй на удалённый процесс" и стыковка с "клиент-сервером". Что получу в конце: процесс срёт только в локальные очереди сообщений (встроенные в процесс), ocamlmq мгновенно кидает на диск сообщения (в том числе в свои надёжные бинлоги, где fsync на каждую запись), а далее, если с сетью всё ок, оно перекидывается к адресату.
Вот это -- надёжно. А не zeromq.

[metaclass.livejournal.com]

Ясно. У меня примерно то же самое, но я надеялся избежать необходимости доделывать его до полноценного mq с транзакциями и fsync :)

[gds.livejournal.com]

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

[eternal-leave.livejournal.com]

fsync() на каждое сообщение? оО

[gds.livejournal.com]

надёжность? Oo

[eternal-leave.livejournal.com]

15k msg/sec с пиками до 30k?

[gds.livejournal.com]

гораздо меньше. Но тут уж выбор -- надёжность или скорость. В требованиях -- 1. максимальная надёжность, 2. не менее 100 сообщений в секунду. Вписываюсь с запасом!

[prepor.livejournal.com]

Можно подумать авторы зероэмку не объебались :)

сначала zeromq, потом crossroads-io (https://github.com/crossroads-io/libxs), сейчас http://nanomsg.org/. Вот и выбирай! :)

C++ lib as specification, бгг

[lionet.livejournal.com]

ZeroMQ даст свой геморрой, неочевидный на ранних стадиях рассмотрения технологии.

Например, при наличии мигрирующих клиентов (клиентов, у которых меняются айпишники) ZeroMQ будет течь. Бай дизайн.

Либо, если у тебя пир отвалился, а у тебя в буфере осталось барахло, то это барахло через полгода сольётся новому пиру, который подключится под таким же айпишником.

Ну или невозможность сделать прокси без встроенной потери сообщений при разрывах коннекта, и необходимостью коиенту завязываться на _per message_ timeouts, вместо реакции на разрыв канала целиком.

[metaclass.livejournal.com]

Да, тоже печаль. Непонятно куды бечь.

[jakobz.livejournal.com]

А чего вообще принято пользовать как эдакую мейнстрим-fits-all MQ? Ну типа надо мне очередь, в перформанс скорее всего не упрусь - чего ща берут в таком случае? Rabbit - ок или там засады какие?

[metaclass.livejournal.com]

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

Другие брокеры(qpid, activemq) поддерживают другие версии протокола, клиенты поддерживают кто во что горазд, единства не наблюдается.

[lionet.livejournal.com]

Kafka

[jakobz.livejournal.com]

Взяли ее

[jakobz.livejournal.com]

Вообще, спасибо за совет. Оно ппц как геморно разворачивается, но в нашем масштабе отобьется. Напишу пост если взлетит. Но если уж взлетит и отобъется - с меня бутылка.

[nivanych.livejournal.com]

> Авторы ZeroMQ отрицают вред
А есть у нас статья за отрицание вреда?
Нет? Срочно надо ввести!

[prepor.livejournal.com]

Кстати, а у вас же ява везде? Что-нибудь про www jgroups org скажете?

[metaclass.livejournal.com]

Не, у меня жабы мало и та в ипостаси кложури :)

[d4s.livejournal.com]

А у тебя большая нагрузка?
И тебе точно MQ надо?

а то есть штуки вроде flume и logstash.
за logstash не скажу, а flume умеет и персистентность и данные любого вида, хотя нативно предполагается AVRO messages

[metaclass.livejournal.com]

Нагрузка - примерно 100 мессаг в секунду, брокер сунуть некуда, железо SOHO/бытовуха, сети ненадежные, процесс эксплуатации и обслуживания подразумевает периодические рестарты любых частей системы )

[d4s.livejournal.com]

если есть куда засунуть отдельные процессы для приема-отправки, то вполне себе ок.
посмотри текста на сайте lvee на эту тему с примером. там процентов 20-30 от возможностей вкратце описаны

[permea-kra.livejournal.com]

... в основном жесткие, мыши грызут проводку, пауки шуршат в жестких дисках, клиент о RAID слышали, но в панике убежали.

[metaclass.livejournal.com]

С RAID проблемы.
Клиенты про них слышали, но используют встроенные в материнские платы серверов или отдельные недоконтроллеры, без батареек и без памяти. Само собой, запасных контроллеров и дисков нет, а настраивать мониторинг здоровья рейдов админы не умеют.

Все это приводит к неприятным последствиям вида "рейд давно сдох, но про это никто не знает".

[permea-kra.livejournal.com]

Бида-пичаль. Ежедневные бэкапы они хотя бы умеют? Про горячее резервирование не спрашиваю.

[metaclass.livejournal.com]

Умеют. На тот же диск, где все остальное :)

[kkirsanov.livejournal.com]

Использую zmq -до 1000 сообщений/ceк, до 100 общающихся процессов в одной сети и через vpn обрывы связи 10 раз в день - проблем нет никаких.

Но думаю при таких условиях у почти любой технологии не было бы проблем.