Авторы 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 сообщений в секунду. Вписываюсь с запасом!