RabbitMQ Высокая скорость передачи данных с ошибками

Question

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

Является ли RabbitMq достаточно быстрым для мягкой доставки сообщений в реальном времени? Есть ли тесты? Это хорошая идея использовать его вместо TIBCO Rendezvous? Есть ли другие альтернативные варианты обмена сообщениями с открытым исходным кодом?

Спасибо.

Answer 1

(Я разработчик RabbitMQ.)

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

Что касается тестов, одной из самых больших проблем здесь является определение того, что важно для вашего приложения. Существуют некоторые тривиально простые примеры измерения «точка-точка» и «pub-sub latency-and-throughput», включенные в Java-клиент; спросите в списке rabbitmq-discuss, если у вас есть проблемы с ними! Они не измеряют значительную значимость для приложений реального мира, но могут помочь устранить любые проблемы, которые вы испытываете в отношении микропредприятий задержки или пропускной способности.

Наконец, в наши дни доступно много, много хороших систем обмена сообщениями с открытым исходным кодом и сообщений. В мире AMQP, помимо RabbitMQ, есть также Qpid и OpenAMQ. Есть также хорошие JMS-серверы с открытым исходным кодом, если вы можете ограничить себя Java (у многих людей есть успех с ActiveMQ). Для систем Ruby и Python возникают многочисленные легкие системы; эти системы стремятся сосредоточиться только на очереди и, как правило, не имеют гибкой возможности маршрутизации, предлагаемой AMQP.

Answer 2

Вы должны иметь возможность получать много десятков тысяч сообщений в секунду на каждый процессор. Например, один из наших стандартных тестов подталкивает 25 000 сообщений в секунду от клиента Java к серверу, работающему на четырехъядерном ящике COTS debian, и обратно к клиенту. Клиент и сервер работают в одном и том же поле, так что 50 тыс. Сообщений обрабатываются в секунду на сервере плюс 50 тыс. Сообщений, обрабатываемых в секунду на клиенте. Вы можете получить более высокие тарифы, запустив сервер в выделенной области с большим количеством ядер. Для ставок, основанных на байтах/секунду, пожалуйста, задайте список рассылки rabbitmq-discuss.

Alexis

Answer 3

Лучшее решение, которое я могу думать о вашей системе ZeroMQ.

У этого нет уверенности, что вы сказали, что вам не нужны, и это ОЧЕНЬ быстро и просто в использовании.

Это не AMQP реализации (что, кажется, вам не нужно тоже), но, как он говорит на this guide:

ØMQ (ZeroMQ, 0MQ, zmq) выглядит как встраиваемая библиотека сети, но действует как рамки параллелизма. Он предоставляет вам сокеты, которые содержат целые сообщения в различных транспорте, например, в процессе, между процессами, TCP и многоадресной рассылкой. Вы можете подключать сокеты N-to-N с такими шаблонами, как разветвление, pub-sub, распределение задач и запрос-ответ.Это достаточно быстро, чтобы быть материалом для кластеризованных продуктов. Его асинхронная модель ввода-вывода дает вам масштабируемые многоядерные приложения, созданные как асинхронные задачи обработки сообщений. Он имеет множество API-интерфейсов языка и работает на большинстве операционных систем.