Локальная очередь сообщений для обмена данными между двумя процессами

Question

У меня есть серверное приложение A, которое производит записи по мере поступления запросов. Я хочу, чтобы эти записи сохранялись в базе данных. Тем не менее, я не хочу, чтобы приложения A потоки тратили время на сохранение записей, напрямую связывая их с базой данных. Поэтому я подумал об использовании простой архитектуры производителей-потребителей, где приложения Thread производят записи, а другие потоки приложений B - это потребители, которые сохраняют записи в базе данных.

Я ищу «лучший» способ обмена этими записями между приложениями A и B. Важным требованием является то, что приложение. Нити всегда будут иметь возможность отправлять записи в систему IPC (например, очередь, но это может быть другое решение). Поэтому я считаю, что записи всегда должны храниться локально, чтобы потоки приложений A могли отправлять событие записи, если сеть не работает.

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

Спасибо, Микаэль

Answer 1

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

Поскольку вы уже на платформе Java, ActiveMQ может быть лучшим вариантом и способен производить высокую пропускную способность. С таким решением потребитель не должен постоянно быть в сети. Исходя из того, насколько важны ваши данные о событиях, вы также можете иметь постоянные очереди и сообщения, чтобы в случае сбоя брокер сообщения вы все равно можете восстановить важные сообщения о событиях, созданные вашим приложением A.

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

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

Есть и другие продукты, такие как HornetQ и Apache Qpid, которые также являются готовыми к производству решениям, но я не использовал их лично.

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