Брокеры 📩 Допустим, вам срочно нужно организовать обмен данными между системами. Какой механизм передачи выберете, если вас разбудят среди ночи? Чтобы ответить на этот вопрос, разберёмся с основами.

Виды общения 💬 Общение — это фундамент любого взаимодействия, будь то между людьми или между системами. Самый привычный формат — диалог, когда один человек (N) передаёт информацию другому (Y) и ожидает ответ. Это классическая модель запроса и ответа.

Но бывают ситуации, когда N транслирует сообщение Y, не ожидая ответа. Например, рекламные рассылки или push-уведомления.

Существует также обмен через посредника. Представим, что N передаёт сообщение X, а тот, в свою очередь, распространяет его среди друзей C, D и E. Этот принцип реализован в мессенджерах и новостных рассылках.

Другой вариант — N записывает сообщение и оставляет его в специальном ящике. X может забрать его в удобное время. Здесь каждый получатель получает только одно сообщение.

Паттерны обмена 🔄 Сервисы и приложения взаимодействуют между собой, обмениваясь данными. Основные модели взаимодействия: – Request-Response (Запрос-Ответ) – примером является работа HTTP, когда клиент делает запрос на сервер и ждёт ответа. – One-Way (Односторонний обмен) или Fire and Forget (Отправил и забыл) – отправитель передаёт сообщение без ожидания ответа, как в случае с UDP-пакетами. – Publish-Subscribe (Публикация-Подписка, Pub-Sub) – отправитель публикует сообщение в канал, а подписчики его получают. – Point-to-Point (Точка-Точка) – каждое сообщение доставляется только одному получателю.

Когда приложения работают напрямую, они зависят от доступности друг друга. В случае с асинхронным взаимодействием через посредника эти ограничения снимаются. Роль брокеров 🏗 Брокер сообщений – это программный посредник, который реализует паттерны Pub-Sub и Point-to-Point. Его задача – упрощение маршрутизации, хранения и доставки сообщений. Использование брокера оправдано, если задачи требуют ресурсов, необходимо координировать много сервисов, требуется масштабируемость и отказоустойчивость.

Гарантия, очереди и топики 📜 При передаче данных возможны сбои, поэтому брокеры предлагают различные уровни гарантии доставки: – At most once (Не более одного раза) – сообщения могут теряться. – At least once (Хотя бы один раз) – возможна повторная отправка, чтобы гарантировать доставку. – Exactly once (Строго один раз) – сообщения не теряются и не дублируются.

Брокеры реализуют два механизма работы: – Очереди (Queue, Point-to-Point) – сообщение читается одним получателем и затем удаляется. – Топики (Topic, Pub-Sub) – сообщение доставляется сразу нескольким подписчикам.

Среди множества решений можно выделить наиболее популярные: RabbitMQ, Kafka, Datareon. А иногда вместо брокера можно использовать SQL-базу данных как очередь, но это менее гибко.

RabbitMQ: "умный брокер, тупой потребитель" 🐰 RabbitMQ – традиционный брокер с поддержкой Pub-Sub и Point-to-Point. Он активно управляет сообщениями: распределяет их по подписчикам, отслеживает их статус и удаляет после обработки. Он поддерживает At most once и At least once, а его настройка проще, чем у Kafka.

Принцип работы: 1. Отправитель (Publisher) передаёт сообщение в обменник (Exchange). 2. Сообщение попадает в одну или несколько очередей (Queue). 3. Подписчики (Consumers) забирают сообщения из очереди.

Kafka: "тупой брокер, умный потребитель" 🦄 Брокер для работы с большими объёмами данных. В отличие от RabbitMQ, он не удаляет сообщения после обработки. Они остаются в хранилище и могут быть прочитаны несколько раз. Kafka поддерживает Exactly once и обладает высокой отказоустойчивостью.

Принцип работы: 1. Продюсер (Producer) отправляет сообщение в топик. 2. Брокер записывает сообщение в журнал (лог) без удаления. 3. Подписчики (Consumers) сами запрашивают (pull) сообщения.

Kafka vs RabbitMQ ⚖️ Выбор зависит от контекста. Если требуется обработка событий с высокой пропускной способностью и хранение данных, лучше подойдёт Kafka. Если важно оперативное взаимодействие микросервисов с возможностью гибкой маршрутизации, RabbitMQ будет предпочтительнее.