kafka

Ставим точку: остаёмся на RabbitMQ. Kafka по возможностям нам подходила, но её сопровождение и развертывание заметно тяжелее, а наши нагрузки и риски прерывания цепочек событий этих затрат не оправдывают. Появится задача на настоящий event streaming — вернёмся.

Apache Kafka - это распределённая платформа event streaming (в простонароде “distributed commit log”), она умеет

1. публиковать/подписываться на потоки событий
2. надёжно хранить их
3. обрабатывать потоки по мере поступления.

Ключевые сущности:

Брокеры → топики → партиции → оффсеты

• Кластер Kafka состоит из broker’ов (серверов).
• Данные пишутся в topics. Каждый топик — это партиционированный append-only лог (упорядоченная неизменяемая последовательность записей, куда постоянно дописывают в конец).
• Внутри партиции каждая запись получает offset — последовательный номер.
• Kafka хранит события по политике retention (время/размер): события могут оставаться доступными даже после чтения, что даёт replay и “прочитать заново”.

Consumer groups

Kafka “склеивает” очередь и pub/sub через consumer group:

• Внутри одной группы каждая партиция читается ровно одним consumer’ом (параллелизм = число партиций).
• Разные consumer groups могут читать один и тот же топик независимо (мультиподписка).
• Порядок гарантируется только внутри партиции, поэтому выбор ключа партиционирования критичен

После нескольких испытаниях на mvp наших первых сервисов вывод: Инструмент мощный и по всем параметрам нам подходит, но имеет ощутимые сложности в сопровождении и развертывании. Ключевое что у нас не очень высокие риски прерывания цепочек событий. Да и прогнозируемая нагрузка на нашу систему не так высока для того чтобы использовать kafka.