Комментарии 15
Классная тема, но так мало написали :)
Спасибо :) ждем вторую часть
Интересно было бы услышать про возможность создания аналога Topic'а в JMS (когда каждое сообщение доставляется всем подписчикам). И еще плюсы/минусы этого способа по сравнению с обычным межпроцессным обменом сообщениями в Erlang.
А как нибудь можно это прикрутить чтобы центральный сервер например давал задачи удаленным bash скриптам, а после завершения работы эти скрипты давали обратно результаты (асинхронно). потому как центральный сервер не должен дожидаться ответа, а продолжать раздавать задачи и если ответ получит, то уже тогда выполнять какие-то действия.
Почему бы не рассматривать систему обмена сообщениями как SOAP сервера, один из которых выполняет функции центра обмена сообщений — то есть для пересылки сообщения от сервера A серверу Б мы посылаем сообщение серверу С с указанием адреса отправителя и получателя? Стандартный отлаженный протокол. Какой плюс в собственном протоколе?
AMQP более близок к транспортному уровню, поверх него можно и SOAP пустить. Изначальной задачей разработчиков протокола AMQP было получить высокоскоростную и отказоустойчивую среду передачи данных, что и было заложено в спецификации. И формат протокола бинарный именно из-за желания пропускать больше полезного трафика в единицу времени и быстрее обрабатывать служебные данные.
Вопросы (м.б. у кого-нибудь будут ответы?)
1. Удобно ли с помощью AMQP-брокеров реализовывать однопроцессные управляемые событиями приложения?
2. При (1) какие ограничения на архитектуру (объём памяти, конкуренция с другими процессами по ресурсам и т.п., для qpid/c — фрагментация выделения памяти на сообщения в очередях) актуальны?
3. Можно ли qpid/c прикрутить к одной из библиотек асинхронного ввода/вывода, что бы использовать существующие наработки?
1. Удобно ли с помощью AMQP-брокеров реализовывать однопроцессные управляемые событиями приложения?
2. При (1) какие ограничения на архитектуру (объём памяти, конкуренция с другими процессами по ресурсам и т.п., для qpid/c — фрагментация выделения памяти на сообщения в очередях) актуальны?
3. Можно ли qpid/c прикрутить к одной из библиотек асинхронного ввода/вывода, что бы использовать существующие наработки?
Маленькое дополнение, не знаю виноват ли протокол, или Эрланг, но очередь сообщений в Эрланге не имеет приоритетов, это немного расстраивает во время разработки. В протоколе есть понятие приоритета сообщений?
Ерланговая очередь сообщений действительно не имеет приоритета, но сообщения из неё можно вычитывать, используя сопоставление по шаблону, что может дать примерно тот же результат. В rabbitmq-erlang-client реализован gen_server2, который делает как раз то же самое, т.е. выбирает из мэйлбокса процесса данные с наибольшим приоритетом в первую очередь.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
RabbitMQ: Введение в AMQP