Ответ
Kafka — это стандарт де-факто для построения асинхронного взаимодействия в микросервисах. Основные паттерны:
Издатель-подписчик (Pub/Sub)
- Описание: Базовый паттерн, где один сервис (издатель) публикует событие в топик Kafka, а один или несколько других сервисов (подписчики) его получают. Это обеспечивает слабую связанность (decoupling) между сервисами.
Consumer Groups (Группы потребителей)
- Описание: Ключевой механизм масштабирования в Kafka. Несколько экземпляров одного сервиса объединяются в группу с общим
group.id. Kafka гарантирует, что каждое сообщение из топика будет доставлено только одному потребителю внутри группы. Это позволяет параллельно обрабатывать сообщения и обеспечивает отказоустойчивость.
- Описание: Ключевой механизм масштабирования в Kafka. Несколько экземпляров одного сервиса объединяются в группу с общим
Saga (Хореографическая)
- Описание: Kafka идеально подходит для реализации хореографической саги. Каждый сервис выполняет свою часть бизнес-процесса, после чего публикует событие в Kafka. Другие сервисы подписываются на эти события и запускают свои локальные транзакции. Kafka выступает в роли надежного хореографа.
Outbox Pattern
- Проблема: Как атомарно обновить данные в базе и отправить событие в Kafka? Если сделать это двумя отдельными операциями, одна может завершиться успешно, а другая — нет, что приведет к рассинхронизации.
- Решение: Запись в базу и отправка события выполняются в рамках одной локальной транзакции. Событие сохраняется в специальную таблицу
outboxв той же БД. Отдельный процесс (например, Debezium через Change Data Capture) отслеживает изменения в этой таблице и надежно доставляет их в Kafka.
CQRS & Event Sourcing
- Описание: Kafka используется как event store (хранилище событий). Сервис команд (write-side) публикует все изменения состояния как события в Kafka. Сервисы запросов (read-side) подписываются на эти события и строят на их основе свои оптимизированные для чтения модели данных (материализованные представления).
Dead Letter Queue (DLQ)
- Проблема: Что делать с сообщением, которое потребитель не может обработать из-за ошибки (например, неверный формат)?
- Решение: После нескольких неудачных попыток обработки такое «отравленное» сообщение (poison pill) перенаправляется в специальный топик — DLQ. Это предотвращает блокировку обработки очереди и позволяет разработчикам позже проанализировать и исправить проблему.