RabbitMQ VS. ActiveMQ

В целом без разницы. Проблема лишь в том, что кролик на эрланге, а это для сильных духом.

а что не так с эрлангом?

Один хрен. ActiveMQ можно в ява приложение встроить.

ActiveMQ сейчас вроде как «легаси», разработчики активно работают над Artemis. Который пока отстаёт по фичам.

ActiveMQ сейчас вроде как «легаси», разработчики активно работают над Artemis. Который пока отстаёт по фичам.

Вроде, всё это вместе взятые легаси же, нет? Пульсар, Кафка и другие стриминг системы же - будущее и трендинг.

Есть ещё NATS. Это нечто из того же ряда, но при этом хрень неведомая, нигде внятно не описанная.

Кролик точно не легаси.

Кадры из Pivotal недавно рассказали как они с Гуглом тестировали Кафку против кролика.

И примерно одинаковые результаты кроме случая по настоящему больших потоков которых даже в Гугл в прод нет

Хочу простой кроссплатформенный message passing, посоветуй (комментарий)

Кафка лучше держит большое количество сообщений на хранении (неделю держать несколько терабайт - запросто). Кролик иногда натурально теряет сообщения при высоких рейтах (>500 msg/sec). Кролик проще и понятнее, но кластеризация там придумана марсианами.

Ты забыл еще ZeroMQ

AMQP 1.0 уже 10 лет, а кролик до сих пор в него не умеет.

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

Именно теряет? Там же очереди имеют ограниченную вместимость. Дефолтное поведение — это как раз «потеря» самых старых сообщений. То есть, всё штатно. Какие ещё варианты, если ресурсы ограничены, а консьюмеры отстают? Можно либо запретить продьюсерам писать, либо отбрасывать старые сообщения.

https://www.rabbitmq.com/maxlength.html

Какие ещё варианты, если ресурсы ограничены, а консьюмеры отстают?

Зажигать мониторинг и чинить консьюмеры.

Вообще Кафка теряет данные при потере питания. Это её архитектурное поведение by-design. Свежие причем данные, а не старые.

Кафка

знаем, кушаем, ну ее нафиг, как и все остальные MQ. если задача не требует 100500 тыщ-мильёнов сообщений постоянно в разные стороны - уж лучше пачка brpoplpush на редисе, сильно упрощает архитектуру и делает данные более явными. А то у нас был какой-то любитель MQ, вплоть до попыток заменить ими grpc, до сих пор стреляет в самых неожиданных местах

ты лучше скажи на кой тебе MQ. А то ставят ради трех с половиной консьюмеров и десяти сообщений в минуту, и потом начинается веселье

А то ставят ради трех с половиной консьюмеров и десяти сообщений в минуту, и потом начинается веселье

Да, иногда просто достаточно обычного игрушечного сервера MQTT, который закрывает многие потребности.

Так ведь в очередях есть возможность подтверждения, а в Кафке хранение + оффсеты. То есть, как только появляется требование гарантии обработки сообщения, твой механизм никуда не годится в отличие от.

иногда просто достаточно обычного игрушечного сервера MQTT

обычно достаточно редиса с brpoplpush из очереди задач в мониторинг их выполнения и обратно в случае жопы.

хз, я не mq-гуру, и у меня от работы с ними всегда ощущение что в 99.9% случаев магия вроде работает, а в 0.1% я вообще хз где черт возьми сообщение, в какой момент консьюмер опять отвалился, и какая очередь успела набежать за это время.

Он админ, ему это админить.

То есть, как только появляется требование гарантии обработки сообщения, твой механизм никуда не годится в отличие от

а куда по твоему brpoplpush делает этот самый push, и зачем он его вообще делает.

Плюс гарантия обработки - понятие растяжимое, и в кривых руках очень веселое для всех кто будет через 4 года разгребать эту радось (в данный момент это как раз я)

Я к настройкам отношения не имею.
Был на Spring One и оттуда информация.
По их утверждению при прямых руках и то и то работает одинаково.

У меня проблем не было ни с Кафоц ни с Кроликом.

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

Сообщения однозначно проще и удобнее всех этих РПС

Только если нужно что-то вызвать когда-нибудь, а результат при этом никого не интересует. Иначе это безумие с очередями в две стороны и лапшой из коллбеков.

Он админ

А непохоже )

Он несколько приуныл.

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

по личному опыту для очереди в три с половиной калеки-консьюмера и с «хайлоадом» в 20 сообщений в минуту монитор в разы проще и дешевле, особенно в облаке на небольших тачках

в плане, я не против MQ, просто их сейчас модно пихать даже туда где их вообще быть не должно

Сообщения однозначно проще и удобнее всех этих РПС

ну да, почти. Вот у нас один умник так и сделал. Уже год с переменным успехом вытаскиваю эту дрянь оттуда. Почему дрянь - см ответ ведьмака. Особенно «смищно» бывает когда события start и finish приходят в разные топики в рандомном порядке, вот тогда полный финиш. Или когда в цепочке сообщений одно сдохло/заело/тормознуло, и потом сидишь и думаешь как откатить все что в этой цепочке было и что из него успело куда пролезть.

Я не спорю что говнокод, но grpc в разы удобнее для нормальной доставки сообщений с гарантией ответа и его ожиданием

Именно теряет. Отследить место потери не удалось: то ли при записи, то ли при роутинге, то ли при чтении. Но проблема имеет место быть, в проде сталкивались не единожды.

Да нормально и кроликом можно пользоваться. Просто если давать ему нормальную нагрузку, то стоит завести в штате эрлангиста :)

Я скорее с реббитом сравниваю. Лично я кафку вообще не осилил. Делал то же самое, что админы, но у них работало, а у меня нет. 🤷‍♀️

Да прям. Эрланг ещё ничего, вон, Слак, вроде, на ноде написан, а сколько народу пользуется.

Это я к тому, что для использования Рэббита ковыряться в Эрланге не нужно.

Вообще нужно, когда он в логи гадит какими то странными сообщениями и трейсами. Хотелось бы понимать о чем оно

Не наблюдали такого, поток сообщений по самой активной очереди 600-2k в секунду в зависимости от времени суток, с прыжками до over 9000 в случаях слива буферов накопившихся за время аварии. Причём эта очередь работала в персистентном режиме т.к. потеря сообщений критична Странные глюки ловили, которые внезапно решаются обновлением ерланга или glibc. В целом крови он попил. Интересно было бы тарантул попробовать для очередей

Иначе это безумие с очередями в две стороны и лапшой из коллбеков.

Вылазьте из криокамеры.
Уже лет 10 Observable и прочие reactive фичи в моде.

Вот у нас один умник так и сделал. Уже год с переменным успехом вытаскиваю эту дрянь оттуда.

Мне тяжело сказать у кого кривые руки, у вас или у него.

От того, что коллбечная лапша теперь под капотом запрятана, коллбечной лапшой она быть не перестала.

а что не так с эрлангом?

Все нормально если он тебе нравится.

Пульсар, Кафка и другие стриминг системы же - будущее и трендинг.

Они не эквивалентны по функционалу кролику и другим mq. Не то, что бы это беда, но одно на другое не меняется без вдумчивой переделки системы.

Ну Кафка тоже теряет сообщения и это её предусмотренный режим работы. Я про ретеншен политику, с которой надо очень аккуратным быть.

хз, я не mq-гуру, и у меня от работы с ними всегда ощущение что в 99.9% случаев магия вроде работает, а в 0.1% я вообще хз где черт возьми сообщение, в какой момент консьюмер опять отвалился, и какая очередь успела набежать за это время.

Эта технология не самоподдерживающаяся. Надо активно мониторить, нужна дежурная смена админов (хотя бы на смс), нужны политики передачи информации, все протоколы общения должны быть четко зафиксированы и протестированы, а все сообщения должны копироваться в долговременное хранилище на случай разбора инцидентов. Тогда работает.

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

Кролик иногда натурально теряет сообщения при высоких рейтах

ActiveMQ тоже.

Именно теряет? Там же очереди имеют ограниченную вместимость.

AMQ именно терял при большом числе запросов за короткое время <1с. То же число запросов секунд за 10-20 обрабатывалось нормально. Правда, после апдейта на 5.15 проблема перестала воспроизводиться.

тестировали Кафку против кролика.

Да это писькомерство изо всех щелей сейчас. И у каждой стороны свои, правильные бенчмарки. Rabbit vs Kafka, ActiveMQ vs Redis pub-sub, zeromq vs everything else. И везде побеждает продукт тестирующего.

если тебе надо застегнуть между собой 50+ разных систем

О том и речь, что в 90% случаев (в которые у тебя не то что 50, а даже 5 разных модулей нету) mq нафиг не нужна и её лепят просто потому что модно

Вот ты на примере грима понимаешь почему у меня предвзято негативное отношение к mq и их фанатам? Пихают туда куда не нужно, потом удивляются когда магия резко перестаёт работать

А ты знаешь как твой observable работает? Сможешь его с нуля написать? Просто когда магия внезапно перестаёт работать - бывает очень смищно

И примерно одинаковые результаты

ну и как в кролике сдвинуть курсор и вычитать поток еще раз?

У ZeroMQ (никогда не юзал, мб ошибаюсь), вроде как, дуплекс и там как раз можно играть в запрос-ответ. Не знаю, последовательные они или нет, но там по крайней мере нет брокера, это p2p. Если бы грим говорил об этом, я бы ещё понял, а так, нафиг-нафиг эту дичь.