LINUX.ORG.RU

Вышел RabbitMQ 3.0.0

 , ,


0

5

Команда разработчиков рада объявить о выпуске RabbitMQ 3.0.0 — новой версии одной из популярнейших систем передачи сообщений на основе стандарта AMQP.

Основные изменения:

Исходные коды, распространяемые на условиях лицензии Mozilla Public License, и бинарные сборки могут быть получены на странице загрузки.

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

Напоминаю, что RabbitMQ создан на основе испытанной в боевых условиях Open Telecom Platform, обеспечивающей высокую надёжность и производительность промышленного уровня, и написан на языке Erlang.

>>> Подробности

★★★★★

Проверено: JB ()

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

Komintern ★★★★★ ()

одной из популярнейших систем передачи сообщений

впервые слышу

heam ()

как то Crossroads I/O больше нравитсяб, и лицензия LGPL

st4l1k ★★ ()
Ответ на: комментарий от heam

продолжай оставаться в криокамере, бро.

ymn ★★★★★ ()
Ответ на: комментарий от Komintern

Шины интеграции не на таких ли системах строятся? Я сам хотел использовать RabbitMQ для интеграции продуктов на предприятии, да не успел реализовать. А теперь не актуально.

winlook38 ★★ ()
Ответ на: комментарий от Komintern

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

В качестве менеджера очередей для крупного проекта.

Dobriy_i_Prostoy ()

одной из популярнейших систем передачи сообщений

в каких широких кругах оно популярнейшее? желтые тексты новостей достали

Kompilainenn ★★★★★ ()

Хорошая новость, мы его используем. Надо поиграться с новой версией.

riki ★★★★ ()

в веб-морде на странице queues по-прежнему нет сводной информации по числу консьюмеров?

leave ★★★★★ ()

Разработчики призывают всех пользователей обновиться до новой версии

Разработчики всё никак не придумали, как обновиться до новой версии без даунтайма? Кластер, итить...

Юзаю пока кролика, но посматриваю на nsq. Там гораздо более похоже на кластер по сути, чем это поделие.

AngryElf ★★★★★ ()
Ответ на: комментарий от Komintern

Для передачи сообщений между узлами системы

boombick ★★★★★ ()

изменений, конечно, вагон.

aliens ★★ ()
Ответ на: комментарий от heam

это не ещё одна асечка. вот поэтому и впервые слышишь.

anonymous ()

Полезная вещь, читал про неё, хоть и не приходилось использовать.

sT331h0rs3 ★★★★★ ()
Ответ на: комментарий от boombick

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

anonymous ()
Ответ на: комментарий от anonymous

Тогда нужно было описывать соответственно, а не как асечка+.

anonymous ()
Ответ на: комментарий от anonymous

Тогда нужно было описывать соответственно, а не как асечка+

асечка это система интернет-пейджинга а не «система сообщений»

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

JL ()
Ответ на: комментарий от JL

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

А сходить в гугл уже не модно? :)

Хотя, правильно говорят: «если вы не знаете, что это такое, вам это не нужно»

boombick ★★★★★ ()
Ответ на: комментарий от JL

интернет-пейджинга

Это из прошлого века, так никто не говорит.

anonymous ()
Ответ на: комментарий от boombick

До модераторов пробрался, а как новости правильно оформлять не удосужился узнать. Они должны быть написаны так, чтобы в гугл ходить не надо было. Возможно для тебя это новость.

anonymous ()
Ответ на: комментарий от anonymous

это да, автор «постарался»

пример внедрения «на пальцах» не помешал бы.

anonymous ()
Ответ на: комментарий от Dobriy_i_Prostoy

> а для чего его на практике можно использовать?
В качестве менеджера очередей для крупного проекта

В крупном проекте сабж сожрёт всю память и, живя на отдельных серверах, успешно грохнется, попутно уронив весь кластер. До сих по не ясно, почему дисковые очереди у сабжа так сильно жрут RAM. Годиться только как диспатчер сообщений с короткими очередями для получателей.

shahid ★★★★★ ()

Используем кролика в своих проектах (Python, PHP, C++) для горизонтального масштабирования. Других AMQP систем не использовали, так что сравнивать не с чем. И да, пользователям асечки оно не нужно :)

kkk ★★ ()
Ответ на: комментарий от anonymous

Когда понадобилось сделать очереди на кластере и уйти от rabbitmq, то быстренько налабал свой костыль под специфику конкретной задачи.

Rabbit vs 0 vs AM что выберешь?

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

Остальных двух не юзал, но
- ZeroMQ можно использовать в около-рапределенном режиме, без совсем единых точек отказа.
- Apache ActiveMQ - выглядит как монстроклон rabbitmq, только на джаве. Нужен ли аналог, если есть оригинал?

Что выберу зависит от задачи. Под мои задачи обычно не подходит вообще ничего из amqp.

shahid ★★★★★ ()
Последнее исправление: shahid (всего исправлений: 1)
Ответ на: комментарий от anonymous

На сайте самый первый пример показывает как использовать это в качестве асечки.

winlook38 ★★ ()
Ответ на: комментарий от anonymous

До модераторов пробрался, а как новости правильно оформлять не удосужился узнать. Они должны быть написаны так, чтобы в гугл ходить не надо было. Возможно для тебя это новость.

Несколько секунд - и читаешь об этом в wiki. Зачем замусоривать текст новости?

ak375648 ()

пока я не базировал свой проект на ZeroMQ... имеет ли смысл попробовать RabbitMQ? убедите меня :)

I-Love-Microsoft ★★★★★ ()

А erlang очевидно был выбран, чтоб способствовать более быстрому глобальному потеплению.

d9d9 ★★★ ()
Ответ на: комментарий от shahid

В крупном проекте сабж сожрёт всю память и, живя на отдельных серверах, успешно грохнется, попутно уронив весь кластер. До сих по не ясно, почему дисковые очереди у сабжа так сильно жрут RAM. Годиться только как диспатчер сообщений с короткими очередями для получателей.

Вообще не характерно для эрланга, с его иммутабельностью и легковесными процессами. Прожорливость и тормоза наблюдались при использовании в частности дисковых схем мнезии и/или вообще при использовании мнезии. Непомню уже, вроде кролик не использует мнезию. Насчет диспатчера - это правильно.

swwwfactory ★★ ()
Ответ на: комментарий от shahid

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

УМВР

Dobriy_i_Prostoy ()
Ответ на: комментарий от Dobriy_i_Prostoy

Сделай именно очереди, чтоб по 100000(0) элементов в сотне очередей.

shahid ★★★★★ ()
Последнее исправление: shahid (всего исправлений: 1)
Ответ на: комментарий от swwwfactory

Тут эрланг не при чём. Ключи всех элементов очередей храняться в RAM для быстродействия. Если очередь станет большой, то приехали.

RabbitMQ - это только брокер сообщений в кластере, но не менеджер очередей. Очереди длинные он хранить эффективно не умеет и гибких инструментов по анализу и модификации очередей не предоставляет вообще.

shahid ★★★★★ ()
Ответ на: комментарий от shahid

Ключи всех элементов очередей храняться в RAM для быстродействия. Если очередь станет большой, то приехали.

или там хранить указатели на очереди ))

Согласен - юзать как брокер. Он собственно так и позиционируется.

остаются свои велосипеды писать или шуструю базу задействовать + с имитацией очередей.

swwwfactory ★★ ()
Ответ на: комментарий от I-Love-Microsoft

пока я не базировал свой проект на ZeroMQ... имеет ли смысл попробовать RabbitMQ?

Гхм, это какбы совершенно разные весовые категории. Что за проект (хотя сама постановка вопроса, мягко говоря, настораживает :))?

anonymous ()
Ответ на: комментарий от swwwfactory

Вообще не характерно для эрланга, с его иммутабельностью и легковесными процессами

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

anonymous ()
Ответ на: комментарий от swwwfactory

Кролик юзает мнезию :(

Но проблем с производительностью у него я не замечал. За выжиманием памяти тоже вроде замечен не был. Хотя длинных очередей (по 100к элементов) у меня не собирается

boombick ★★★★★ ()
Ответ на: комментарий от anonymous

копию данных на каждый чих

Да, это бесспорный оверхед. Но это нормально для ФП-языков и так даже удобнее в некоторых случаях (не во всех конечно) программировать. Еще приходится из-за этого таскать везде с собой кучу параметров. Если хочется ООП - есть молодой exlixir полностью ооп на базе ерланга с его плюшками. Считается, что благодаря иммутабельности проблемы утечки памяти сведены к минимуму, но самом деле это не совсем так.

«легковесными» их назвали, чтобы усыпить вашу бдительность.

Там все есть процесс, так что без легковесности сложно что-либо сделать. Процессы сабжа реально дешевые и let it crash.

чтобы усыпить вашу бдительность.

т.е. они на самом деле не легкие, а тяжелые?

swwwfactory ★★ ()
Ответ на: комментарий от boombick

Кролик юзает мнезию :(

Кролик, ёж.. )) да, с ней не соскучишься. На сайте кролика насчет мнезии как-то уклончиво упоминается. Если это возможно, то лучше в этом случае использовать т.н. без-дисковые схемы и только RAM-nodes (в терминах мнезии)

Но проблем с производительностью у него я не замечал. За выжиманием памяти тоже вроде замечен не был. Хотя длинных очередей (по 100к элементов) у меня не собирается

Это хорошо. Кому как повезет с нагрузкой проекта ))

swwwfactory ★★ ()
Ответ на: комментарий от Bioreactor

И чем это лучше JMS?

Протокол AMQP проще JMS и кроме того он кросс-платформенный. Помню года 4 назад пробовал играться с ним, когда затра...ся с кривой кластеризацией ActiveMQ. Но потом меня сократили и с тех пор я с мессанджингом особо не работал. RabitMQ более подходит для High Speed Messaging and Low Latency чем JMS

Extremal ()
Ответ на: комментарий от shahid

почему дисковые очереди у сабжа так сильно жрут RAM.

О, ты с имел опыт его использования. Не подскажешь, насколько «сильно жрут» память и диск? Прямо сейчас перевожу свой проект на RabbitMQ с хранимыми очередями и «ручным» подтверждением (с собственного костыля поверх MongoDB), инетерсно узнать про косяки.

theos ★★★ ()
Ответ на: комментарий от theos

Я его использую. Сомневаюсь, что это правильный подход, но у меня прижился. Очередь в 2.5 Млн сообщений быстро создается (где-то 600Мб занимает) и потом разгребается пачкой воркеров в течение 5-6 часов. Очередь персистентная, в первую очередь для защиты от сбоев. Как персистентность влияет на потребление памяти я не помню.

Когда кролик начинает занимать что-то около 50% памяти он принудительно ограничивает скорость паблишинга сообщений через TCP backpressure, чтобы не уходить в swap.

seriyPS ()
Ответ на: комментарий от swwwfactory

Насчет копии данных на каждый чих не совсем верно.

Если меняешь кортеж, то «копируется» только сам кортеж (не рекурсивно). Если меняешь значение в кортеже/рекорде, то «копируется» только это значение и сам контейнер. При добавлении элементов к связному списку (и к строке, соответственно) вообще НИЧЕГО не копируется. За счет поддержки IO листов склейка строк происходит крайне эффективно и тоже без копирований. Большие бинарные блобы хранятся в отдельной куче и не копируются при передаче сообщений.

Насчет персистентного хранилища кролика завтра посмотрю.

seriyPS ()
Ответ на: комментарий от anonymous

Процессы легкие. При старте занимает ~309 машинных слов. Стек динамический, так что, в случае чего, stack overflow не словишь пока в своп не уйдёшь.

seriyPS ()
Ответ на: комментарий от seriyPS

Имеешь в виду функцию BIF erlang:setelement ?

это в общем плане и теории считается, что создается копия - конечно, все это оптимизируется. Например при работе с dict - постоянно происходит перечитывание при вызове API этого модуля - сначала это удивляет, потом не обращаешь внимание уже )) При изменения словаря, создается фактически новая (измененная) копия словаря, хотя внутренняя структура словаря - кортеж. Или когда работает gen_fsm, gen_server - его state постоянно «крутится», изменяясь практически полностью при запросах handle_call, но это уже зависит от логики сервера. Если тем более case может вернуть все что угодно в handle_call при обновлении state. Кортэжи считаются более компактными по потреблению памяти, чем списки.

При добавлении элементов к связному списку

В эрланге вообще-то связанных списков нет в классическом толковании с указателями - или ты говоришь про внутреннюю реализацию или про какие связанные списки идет речь?

swwwfactory ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.