![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Авторы ZeroMQ отрицают вред
Сидел читал про ZeroMQ (он, несмотря на отсутствие персистентности, наиболее близок к тому, что мне надо для решения задачи). При этом в гайде попались две ссылки, отрицающие энтерпрайзно-бизнесовый вред:
http://swsi.info/
http://www.imatix.com/articles:whats-wrong-with-amqp/
Особенно весело про amqp, как комитет по его разработке объебался во всех формах, что привело к нескольким плохо совместимым реализациям, которые, в свою очередь, начали диктовать разработку стандарта.
http://swsi.info/
http://www.imatix.com/articles:whats-wrong-with-amqp/
Особенно весело про amqp, как комитет по его разработке объебался во всех формах, что привело к нескольким плохо совместимым реализациям, которые, в свою очередь, начали диктовать разработку стандарта.
no subject
no subject
Сейчас очередь сделана поверх БД, но это приводит к очень дурному характеру нагрузки на диски+плюс баги Firebird, в итоге много тупого геморроя.
no subject
no subject
а mq это и есть мессаджинг поверх redis
no subject
Кароч взял ocamlmq, научил его встраиваться в процесс (а не висеть отдельным процессом), налепил абстракцию "сервер" (хуйнюшка, к которой можно connect, далее send/recv _сообщений_), сделал переходники между "сервером" и потоком байтиков в tcp/ip, и ocamlmq теперь даёт как по tcp/ip, так и внутри процесса.
Сейчас доделываю абстракцию "клиент-сервер поверх очередей сообщений". Соединения, таймауты, очистка очередей по завершении, реконнекты.
Следующий этап -- умение указывать "вот такие-то очереди локального процесса копируй на удалённый процесс" и стыковка с "клиент-сервером". Что получу в конце: процесс срёт только в локальные очереди сообщений (встроенные в процесс), ocamlmq мгновенно кидает на диск сообщения (в том числе в свои надёжные бинлоги, где fsync на каждую запись), а далее, если с сетью всё ок, оно перекидывается к адресату.
Вот это -- надёжно. А не zeromq.
no subject
no subject
no subject
no subject
no subject
no subject
no subject
сначала zeromq, потом crossroads-io (https://github.com/crossroads-io/libxs), сейчас http://nanomsg.org/. Вот и выбирай! :)
C++ lib as specification, бгг
no subject
Например, при наличии мигрирующих клиентов (клиентов, у которых меняются айпишники) ZeroMQ будет течь. Бай дизайн.
Либо, если у тебя пир отвалился, а у тебя в буфере осталось барахло, то это барахло через полгода сольётся новому пиру, который подключится под таким же айпишником.
Ну или невозможность сделать прокси без встроенной потери сообщений при разрывах коннекта, и необходимостью коиенту завязываться на _per message_ timeouts, вместо реакции на разрыв канала целиком.
no subject
no subject
no subject
Вроде принципиальных проблем я не наблюдал с ним.
Другие брокеры(qpid, activemq) поддерживают другие версии протокола, клиенты поддерживают кто во что горазд, единства не наблюдается.
no subject
no subject
no subject
no subject
А есть у нас статья за отрицание вреда?
Нет? Срочно надо ввести!
no subject
no subject
no subject
И тебе точно MQ надо?
а то есть штуки вроде flume и logstash.
за logstash не скажу, а flume умеет и персистентность и данные любого вида, хотя нативно предполагается AVRO messages
no subject
no subject
если есть куда засунуть отдельные процессы для приема-отправки, то вполне себе ок.
посмотри текста на сайте lvee на эту тему с примером. там процентов 20-30 от возможностей вкратце описаны
no subject
no subject
Клиенты про них слышали, но используют встроенные в материнские платы серверов или отдельные недоконтроллеры, без батареек и без памяти. Само собой, запасных контроллеров и дисков нет, а настраивать мониторинг здоровья рейдов админы не умеют.
Все это приводит к неприятным последствиям вида "рейд давно сдох, но про это никто не знает".
no subject
no subject
no subject
Но думаю при таких условиях у почти любой технологии не было бы проблем.