2016-12-01 2 views
1

Я использую NodeJS и amqplib для создания простой библиотеки очередей запросов (несколько похожей на Jackrabbit), которая будет использоваться в сервисе который должен анализировать довольно большие фиды, содержащие информацию о множестве разных событий.RabbitMQ & NodeJS: Следующее «1 подключение на одно приложение, 1 канал на поток, 1 потребитель на канал».

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

Вопрос: как я следую за «1 соединением для каждого приложения, 1 канал на поток, 1 потребитель на канал» в этом случае? Это заставило бы тысячи процессов быть порожденными, тратя огромные объемы памяти и ресурсов.

Примечания: Количество сообщений в каждом из очередей не очень высоко: около 1-2 тзда/сек не более

+0

Рекомендации, о которых я говорю, упоминаются в этом посте: http://stackoverflow.com/questions/10407760/is-there-a-performance-difference-between-pooling-connections-or-channels-in- Rab – Towerman

ответ

4

Я предполагаю, что вы знаете, что NodeJS является однопоточным при выполнении кода, где ваш вопрос исходит из ...

В языках, основанных на потоках, правило «1 канал на поток» важно, потому что язык блокирует поток, на котором сидит канал/потребитель. Вы получите какой-то вызов consume, и поток будет заблокирован, ожидая появления сообщения.

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

В NodeJS, однако, вызов абонента, который потребляет сообщения, не блокирует.

Это означает, что вы можете смело выбрасывать концепцию 1 channel per thread.

В моем собственном коде NodeJS и RabbitMQ часто будут открыты сотни каналов в одном экземпляре моего приложения.

Каналы дешевы и легко открываются. Создание поставщика сообщений или потребителя также дешево. Реальная стоимость: 1) в соединении и 2) выполнение фактической работы после получения сообщения.

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


Несколько дополнительных примечаний:

Я настоятельно рекомендую использовать https://github.com/arobson/rabbot для ваших NodeJS/потребностей RabbitMQ. Я работал с множеством «простых» NodeJS-библиотек для RabbitMQ, и у них у всех есть ограничения, которые я считаю неприемлемыми. Rabbot имеет улучшенный слой абстракции, чтобы упростить работу с RabbitMQ, при этом предоставляя вам всю необходимую гибкость.

Вы также можете проверить мои курсы RabbitMQ и NodeJS, здесь: https://sub.watchmecode.net/guides/microservices-with-rabbitmq/ - скринкасты, электронные книги и интервью с отраслевыми экспертами, которые помогут вам быстро ускорить работу с RabbitMQ и NodeJS. Заметьте, однако: screecasts используют Wascally в качестве основной библиотеки, которая является предшественницей Rabbot (она была переименована в Rabbot, когда они внесли некоторые большие изменения в ее внутренние элементы).

Смежные вопросы