Выбор MQ сервера

Что то давненько я тут не спрашивал странного.
на текущем проекте вырисовывается в ближайшем будущем необходимость в MQ как интеграционного средства. И скорее всего нужно именно AMQP
Область сия мне не очень знакома. по этому есть вопросы по серверам.

Доступные альтернативы:
— rabbitMQ — выглядит вменяемо но там Erlang (идеологически мне повигу но не дай бог придется лесть в сорцы)
— Azure Service Bus — его я поссыкиваю, MS такой MS. хотя при том что у нас azure везде и всюду — возможно это будет первым в списке.
— qpid ?
— что то еще?
Кто с чем сталкивался, какие впечатления. Был бы рад услышать самое мясо- что настраивается через зад, что падает, какие впечатления от комунити... Любые мнения вплоть до приступов ярости на конкретные продукты — welcome

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

ActiveMQ, він підтримує офіційні специфікації AMQP 1.0
Пізніше ви можете переключитися на FuseMQ — fuse.fusesource.org/mq

ActiveMQ, стандарт де-факто в жава мирке.

p.s. Если что, то пользовался в 3 проектах, в одном из которых система на С++ интегрировалась с системой на Java.

p.p.s Если среда разработки не гетерогенная, то я советую Apache Camel, это такой легковесный почти сервис бас.

Посмотрите в сторону ZeroMQ.

Выбор MQ сервера
И скорее всего нужно именно AMQP
Посмотрите в сторону ZeroMQ.
Есть мнение что вы хотели выпендритсо, но у вас не получилось (если есть вопросы где именно вы не в курсе, гуглите).

сказано «Скорее всего именно AMQP», но человек не знает точно. Я общался с автором ZeroMQ и использовал как ZeroMQ так и RabbitMQ. ZeroMQ намного удобнее в поддержке. Он проще и дает больше возможностей.

вырисовывается в ближайшем будущем необходимость в MQ как интеграционного средства.
сказано «Скорее всего именно AMQP», но человек не знает точно.
Так а зечем ему тогда 0MQ? Может оно ему вообще ничего не надо, человек не знает точно.
Я общался с автором ZeroMQ
А он вам не говорил что 0MQ никакая не MQ?
использовал как ZeroMQ так и RabbitMQ
Я так и понял :)

начинается пустая дискуссия. Вы как я понимаю «спец» в MQ Вам и карты в руки.

з 0MQ вам потрібно писати кожну частину інфраструктури самостійно. так що ви повинні написати власну чергу iз блекджеком та повіями. так що ви будете винаходити колесо. again and again and again.

Page Not Found: /sonic/

Stay tuned. Please email us if you need to get in touch.

Это прекрасно. 5 минут назад открывал — работало. Сейчас действительно стей тюнд.

ВТФ

Zero-downtime operations guarantee the timely and continuous delivery of information and business services, even if hardware fails or systems are upgraded

Как такое можно гарантировать без звездочки?

@До Автора:

Викладіть в кінці ваші проц енд конс по тому, що ви знайшли будь-ласка.

будет, оперативно не обещаю тк приоритет у этого процесса пока не высокий.

Вам нужна вменяемая абстракция (без перегибов) и запуск проекта. Потом поймете что к чему и передете

хороший совет. особенно в контексте вполне конкретного вопроса. Щеки от важности по утрам не трещат, осмелюсь спросить?

Не понял от чего столько ненависти, хотя ДОУ есть ДОУ. Просто много таких выбираторов видел. Нагрузок не знают, требований не знают, частот использования не знают и выбирают. Или знают, но не пишут в составе вопроса

И еще нужно всем чтобы скейлилось как фейсбук, ясное дело

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

MSMQ
 — Майкрософтом закинутий і по суті не розивавається. Всякими розподіленими сценаріями, високою доступністю, захищеністю від збоїв там по суті не пахне, вмре машина де ваша черга живе, вмруть і ваші черги з даними. Плюс привязка до вінди і зберігання данних в папці Windows (якщо не помиляюсь). Одним словом сильно нерекомендоване рішення, навіть якщо ви .net-тчик і не любите мазохізм. Візьміть нормальний MQ на зразок ActiveMQ, RabbitMQ до них є вагон враперів під будь-які мови. Якщо стоїть задача інтеграції, то можливо є зміст брати цілий ESB, аля ServiceMix?

я только что понял что я прогнал. не MSMQ предлагался а Azure Service Bus
но у меня и к нему доверия 0

и либ дляпосторонних языков программирование тоже 0

MQ прост как тапок — но работает надежно. ActiveMQ — повалить не сложно — может таки пофиксили?. Чем винда не походит? ESB — ага, втюхайте еще от оракля — переходите в СС в сейлзы — суть вы уже понимаете.

Из того с чем я работал — RabbitMQ или MSMQ, и точно не ActiveMQ — ненадёжен.

абсолютно безкомпетентный ответ человека который занят программированием микроконтроллеров. видно что не знает даже разница между технологией постронения брокера и фактическими реализациями. если бы он был дотнетчиком — он бы пошустрил на codeplex и нашел там реализацию pure .net брокера который юзает win сокеты через P/Invoke

pure .net брокера
яким боком тут msmq.
Як ви побудуєте high availability на msmq без biztalk. Що станеться якщо накриється диск машини де ваш msmq хоститься.
Радити брати message broker з codeplex може лише теоретик. Там всього з десяток проектів набереться які не закинуті і які можна використати в продакшн.

Около полугода используем rabbitMQ. Полет нормальный.

мистики никакй не наблюдали пока? Нагрузка большая? failover схема у вас примерно какая если не секрет?

У нас нагрузка доходила до 20к/сек, с чем спокойно справлялся m1.small на амазоне. Failover’ом не заморачивались, т.к. пока жареный петух не клюнет... =)

нагрузка с использованием Python bindings for Qpid — dream on, уважаемый

чому? поясніть будь ласка

и что: софт под другие реализации AMQP пробовали на него переводить?

вырисовывается в ближайшем будущем необходимость в MQ как интеграционного средства
И скорее всего

zeromq.org/...lcome-from-amqp — рекомендую бегло ознакомиться, в т.ч., с тем, что выделено жирненьким.

Читал, читал... мне лично на AMQP похрен, просто у кастомеров уже есть именно оно. Т.е. глобально вопрос выбора стандарта не стоит. Продавить другой стандарт меснджинга у кастомера с нет инкомом большим чем украинский рынок аутсортинга — не вариант :)

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

Ну и обычно советуют при повышении нагрузок, сваливать с облаков на реальное железо: буст 10-30% попугаев.

так и будем делать.
пока у нас есть azure в очень серьезных количествах как у MS партнера, от сюда вылез MSMQ. Но мне на него завязываться ОЧЕНЬ не хочется.

ну вот допустим я сейчас буду писать для MSMQ bindings под один из языком программирования. могу заюзать твои use cases и нагрузочные тесты. если интересно — личка в помощь. Так же работал с Qpid.

Огромное спасибо за предложенную помощь!
У меня еще нет тестов, стартовала тягомотина политического толка и писание вилами по воде :( В этой части я на процесс не влияю совсем

а можно в личку мне отписать и продолжить обсуждение в частном порядке?

А чем классика не нравится?
ru.wikipedia.org/...Message_Service

Ну тоесть
Apache ActiveMQ

круто, но я же говорю о AMQP. в activeMQ поддержка заявленна, но не понятно на сколько она полная, там они больше говорят о мепинге на JMS что мне вообще не нужно. окружение не java only, хочется обойтись без JMS совсем.

ок, уже веселее. Но вообще как он в сравнении с тем же rabbit?

Я не знаю, никогда не юзал ни то ни другое, но по отзывам rabbitmq конечно предпочтительнее.

ну вот мне примерно то же Рабиновичь напел, дескать activeMQ источник рака и противоестесвенной содомии а кролик источник счастья. Но хотелось бы больше кровавых подробностей от пользователей.

ActiveMQ простіший в настройках і конфігурації, простіший(суб’єктивно) в адмініструванні, підтримує багато транспортів (наприклад нам для інтеграції сервісів на java, php та node.js було зручно використовувати nio та stopm // на момент девелопменту activeMQ ще не підтримував amqp в стабільному релізі).
Є кілька статтей про низький перфоманс(5/50 повідомлень на секунду), але ми з цим не стикнулися, на амазон мікро інстансі 500-1000 повідомлень в секунду нормально тримав і по CPU було в межах 5-20%

По перфомансу RabbitMQ потужніший, ми його пробували у якості альтернативи на заміну, працює, але для нас переїзд вимагає додаткових ресурсів, а вигоди мізерні і тільки теоретичні, тому досі працюємо на ActiveMQ.

якщо перфоманс критичний, або потрібні специфічні речі AMQP — варто використовувати RabbitMQ

нормально короче, не все так плохо значит с ActiveMQ
я себе шортлист составляю что надо пробовать.

Мы его тестировали в одном операторе платежных терминалов — я его вешал так, что он потом KahaDB убивал, доводили до потери сообщений на короткое время. Может починили — но выбрали потом Rabbit.

Поддерживаю. Валится весьма часто и добротно — потом не восстанавливается. Такие падения у нас чинились только удалением хранилища сообщений — ни о какой гарантированной доставке сообщений говорить не приходится. :)
В общем и целом расклад примерно следующий:

ActiveMQ — куча настроек, широкий функционал. Выглядит как экспериментальный проект, ибо в общем и целом работает крайне не надежно — падает при массовом вбросе сообщений от достаточно небольшого количества клиентов (по 10-100 сообщений от около 100 клиентов). Если сообщений поступают в очередь быстрее, чем их обрабатывают и очередь переполняется, то activemq зависает намертво при использовании KahaDB. Частично решается при использовании реляционных СУБД (пробовали MSSQL и Firebird). Если у java-машины заканчивается выделенная при запуске память, то activemq падает — решается исключительно перезапуском java-машины. При всем этом надежным ActiveMQ назвать не получается. При использовании встроенной библиотеки Camel возможна реализация трансформаторов, роутеров и прочих интеграционных паттернов. Однако camel никак не интегрирован с activemq — с таким же успехом можно запустить camel в другом процессе. Админка есть, но глючит сильно — зачастую начинает показывать сообщения, которых нет в очереди. Через 2 месяца после внедрения перешли на MSMQ.

MSMQ — прост как тапок. Ничего лишнего — только очереди сообщений. Никаких паттернов интеграции. Подключиться к серверу с другого сервера, если он не в домене, у нас так и не получилось — возможно готовить не умеем. Однако в остальном работает безотказно. Выдерживает недостаток памяти, переполнение очередей и т.д. Админки почти нет — надо пользоваться сторонними утилитами. В нашей системе отработал в течение 1.5 лет — ни одного отказа. Потом перешли на RabbitMQ.

RabbitMQ — весьма специфически устроен внутри (имеется ввиду Exchanger). Работает надежно и без проблем. Админка есть и весьма информативная. Выдерживает нехватку памяти и переполнение очередей. Работает уже более 2-х лет.

Единственным преимуществом ActiveMQ для нас являлась такая фича как селекторы стандарта JMS. В остальных упомянутых MQ-серверах такого нет. В MSMQ пришлось реализовывать собственными силами, что повлекло написание собственных интерфейсов работы с MSMQ и определенную потерю в производительности (нам было не критично). В RabbitMQ эту фичу так и не реализовали.

В качестве факультатива пробовали MQ сервер от JBoss — падал при тех же условиях, что и activemq.
Так же был опыт с WeblogicMQ — напоминает MSMQ, прост как тапок и просто работает.

у самого опыта с ActiveMQ нет, но я насмотрелся как с ним мучаются до сих пор, зависания, проблемы с перформансом. я бы не стал связываться

redhat предоставляет python веб морду для администрирования qpid

Подписаться на комментарии