Log-based- и Queue-based-брокеры сообщений

Несколько раз сталкивался с тем, что отсутствие подобной терминологии создает неудобство при обсуждении технологического стека проекта. Помимо этого хотелось бы добавить ясности в понимании этих терминов для тех, кто не знаком с одним или другим видом брокеров.

Имеют постоянно пополняемый лог сообщений, хранимый на диске. Именованный лог называется топиком (topic) и обычно хранит сообщения с одинаковой структурой данных (одного типа). Источник отправляет сообщения, записывая их в топик; приемник, называемый потребителем (consumer), получает сообщения, читая и обрабатывая их последовательно. При успешной обработке потребитель сдвигает указатель (offset) к следующему сообщению. Положение указателя также хранится на диске и ассоциировано с потребителем. У каждого топика может быть только один потребитель, относящийся к одной группе (consumer group). Чаще всего группа ассоциируется с каким-то одним приложением (например, микросервисом).

В целях масштабирования и увеличения пропускной способности топик можно разбить на части - партиции (partitions), каждая из которых может быть размещена на различных узлах кластера. В какую партицию будет направлено сообщение решает источник; какую партицию будет обрабатывать потребитель решает брокер. Брокер отслеживает жизненный цикл каждого потребителя и производит процедуру балансировки - перераспределения топиков между активными потребителями. При этом важно то, что одну партицию может обслуживать только один потребитель. Так гарантируется порядок обработки сообщений в рамках одной партиции.

Самые главные преимущества Log-based-брокеров - это лог, хранимый на диске; возможность перемещать указатель (offset) в любое положение; высокие гарантии соблюдения строгого порядка обработки. Таким образом, есть история возникновения событий и возможность ее многократной обработки.

Типичные представители: Apache Kafka, Redpanda.

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

За маршрутизацию сообщений отвечает брокер. Одну и ту же очередь может обслуживать любое количество обработчиков. Как только обработчик заканчивает обработку очередного сообщения, брокер передает ему новое. В общем случае порядок обработки не гарантируется, т.к. основная задача - побыстрей обработать очередь.

Самые главные преимущества Queue-based-брокеров - это простота и гибкость обмена сообщениями; адаптивность к вариативной вычислительной сложности обработки; отсутствие простоев обработчиков.

Типичные представители: AMQP/JMS-based - RabbitMQ, Apache ActiveMQ; MQTT-based - Eclipse Mosquitto, HiveMQ.

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

P.s. Если вам интересна данная тематика, присоединяйтесь к моей новостной ленте в Telegram. Буду рад поделиться опытом. ;-)