Нужно ли использовать как можно меньше очередей? И решения для обмена сообщениями в сети. - PullRequest
3 голосов
/ 12 августа 2011

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

Какой подход наиболее часто используется для обмена сообщениями в сети. Я вижу RabbitHUb и Rabbit WebHooks, но Webhooks, похоже, не является масштабируемым решением. я работаю с Rails и моим сервером AMQP, работающим как демон.

Ответы [ 2 ]

6 голосов
/ 12 августа 2011

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

Вышеуказанное относится только к одной машине. RabbitMQ поддерживает форму облегченной кластеризации . Когда вы объединяете несколько узлов Rabbit в кластер, каждый может видеть очереди и обмены на других узлах, но каждый запускает только свои собственные очереди. Таким образом, вы сможете иметь еще больше очередей! (до предела кластеров Erlang, который обычно составляет несколько сотен узлов). Таким образом, кластер образует логический брокер, распределенный по нескольким машинам; клиенты подключаются к нему и используют его прозрачно через любой из узлов.

Тем не менее, наличие одной длительной очереди для каждого пользователя кажется немного странным: в AMQP вы не можете просматривать сообщения, пока они находятся в очереди; Вы можете получать / использовать только те сообщения, которые удаляют их из очереди, и публиковать, которые добавляют в конец очереди. Таким образом, вы можете использовать AMQP в качестве маршрутизатора сообщений, но не можете использовать его в качестве базы данных сообщений.

0 голосов
/ 12 августа 2011

Вот нить, которая только что говорит об этом: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2009-February/003041.html

...