Ответ 1

Update

Есть ли сценарии, в которых мне нужен RabbitMQ для веб-приложений, где Socket.io не хватает? Пользователи браузера должны иметь возможность общаться друг с другом через сервер node.js. Один пользователя записывает сообщение, и все остальные пользователи получат его.

Если у вас есть только эти простые требования, кроме того, что будет достаточно только socket.io.. Вам нужно только сообщение queue, когда вы хотите обрабатывать свои задания (тяжелые) автономно и контролируемым образом.

http://en.wikipedia.org/wiki/Message_queue:

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

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

Это делает очередь Данные First-In-First-Out (FIFO) структура.

Это я считаю важным свойством очереди. Свойство First-In-First-Out, хотя с расширенной очередью сообщений, например beanstalkd, вы можете указать приоритеты заданий.

Я надеюсь, что это имеет смысл вообще;)

Я делаю онлайн-приложение в реальном времени развитие.

Не могли бы вы объяснить немного лучше, чтобы мы могли дать вам лучший ответ?

Я не совсем понимаю, как работает RabbitMQ. Но из быстрого чтения кажется, что он обрабатывает публикацию/подписку сообщения.

См. цитату о очереди сообщений ниже. Пусть он погрузится на некоторое время. Вы также можете прочитать WIKI о очередях сообщений.

Пользователь (в браузере) публикует что-то и подписчиков (в других браузеры) получают это сообщение. Разве это не так что Socket.io делает с WebSockets?

Socket.io поддерживает множество разных транспортов (также веб-порты), и это должно быть связано с тем, что большинство браузеров не поддерживаются веб-сайтами. Но, к примеру, Google Chrome уже поддерживает websockets. Я считаю, что websockets - это перенос будущего (но еще не!). Когда вы смотрите страницу поддержки браузера Socket.io, вы заметите, что Socket.io поддерживает все основные браузеры (некоторые даже древние). Самое приятное, что он обертывает это вокруг хорошего API.

Каковы преимущества/недостатки для каждого из них?

Вы сравниваете яблоки с апельсинами, поэтому сравниваете это странно.

RabbitMQ

http://www.rabbitmq.com/tutorials/tutorial-one-python.html:

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

Преимущества

• Это довольно хорошая очередь сообщений. Лично я использовал бы redis или beanstalkd.

Недостатки:

• На самом деле не для "браузеров".

Socket.io

http://socket.io/:

Socket.IO нацелен на создание приложений в реальном времени возможно в каждом браузере и мобильное устройство, размытие различия между различными транспортных механизмов.

Преимущества

• Это для браузера

Недостатки

• Это не очередь сообщений.

Может ли Socket.io заменить RabbitMQ?

Нет, вы не можете, потому что это две совершенно разные вещи. Вы сравниваете яблоки с апельсинами. Вы должны попытаться понять оба описания с сайтов, которые я цитировал.

Ответ 2

RabbitMQ используется для передачи сообщений через приложения, а не для пользователей в браузере. Затем вы могли бы реализовать клиента RabbitMQ в node.js, который подталкивает полученные сообщения к браузеру.

См. http://www.rabbitmq.com/blog/2010/11/12/rabbitmq-nodejs-rabbitjs/ для примера.

Ответ 3

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

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

btw: Erlang используется Facebook и Twitter для их за кулисами.

Теперь, RabbitMQ больше, чем просто тип сетевых сокетов... он основан на "гарантированной доставке". Эта особенность важна для корпоративных ситуаций. RabbitMQ, альтернативно, можно использовать для масштабирования... на самом деле, там больше, чем это... Я не делаю это справедливо.

Я не могу комментировать node.js, поскольку у меня еще не было возможности поиграть с ним. Я доволен RabbitMQ.

re: socket.io(говорим ли мы о websockets?) - если это для браузера (как говорится выше в сообщении), вы могли бы перевести это в RabbitMQ. т.е. RabbitMQ является гибким.