Kafka: что это, зачем нужна и чем отличается от очереди

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

Обычная очередь чаще отдаёт задачу одному исполнителю и удаляет её после обработки. Kafka хранит событие в журнале заданное время. Один и тот же topic могут читать разные consumer group, каждая со своим темпом и своим offset.

Topic — это поток событий под одним именем. Partition делит его на части и даёт параллелизм, при этом порядок сохраняется внутри самой partition. Consumer group — группа читателей, которые делят между собой работу по этим partition. Именно так поток масштабируют без потери общей схемы.

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

Часто ломают не брокеры, а плохие решения вокруг события. Например, неудачный key, слишком короткий retention, невнятная схема, медленный consumer или отсутствие идемпотентности. Из-за этого lag растёт, порядок плывёт, а повторная обработка становится болезненной. И сбой начинает расходиться дальше по цепочке.

Дальше обычно разбирают consumer group, rebalance, гарантии доставки, Schema Registry, Kafka Connect и мониторинг потока. Потом уже стоит идти в эксплуатацию кластера и проектирование событий. Рост здесь идёт от понимания системы целиком, а не от одной клиентской библиотеки.

Представьте почту: продюсеры сдают письма, Kafka сортирует их по темам и хранит, а потребители забирают в удобном темпе. Отличие от обычной очереди в том, что письмо остаётся в журнале и его можно перечитать заново.

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

Топик — именованный канал, куда пишутся события одного типа: «заказы», «клики», «платежи». Внутри он разбит на партиции и хранится как последовательный лог. Продюсер пишет в топик, потребитель на него подписывается.

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

Producer — сервис, который пишет события в топик. Consumer — сервис, который их читает и обрабатывает. Один продюсер может кормить множество потребителей, и они не знают друг о друге.

Consumer group — набор потребителей, которые делят между собой партиции одного топика и читают параллельно. Kafka сам распределяет партиции по участникам и перераспределяет их при сбое или добавлении нового инстанса. Две разные группы читают один топик независимо, каждая со своим прогрессом.

Kafka развязывает сервисы: продюсер не ждёт потребителя, а пишет событие в поток и идёт дальше. На ней строят обмен между микросервисами, сбор логов и метрик, потоковую аналитику. В московском IT-срезе навык на 10-м месте из 344 и растёт — net +38 за восемь недель.

Нет. Kafka хранит поток событий, а не таблицы для произвольных запросов: читают его последовательно по offset, а не по SQL. Хранение ограничено retention, хотя топик можно настроить и на бессрочное. Для аналитических запросов рядом обычно ставят PostgreSQL или ClickHouse.

Брокер — узел Kafka, который принимает записи от продюсеров, хранит партиции на диске и отдаёт их потребителям. Кластер собирают из нескольких брокеров ради отказоустойчивости и масштаба. Упал один — его партиции подхватывают реплики на других.

Аналитику Kafka нужна на уровне понимания: как событие идёт через поток, что такое топик, offset и lag. В московском срезе сектор Аналитики даёт заметную долю спроса на навык, рядом стабильно SQL и PostgreSQL. Писать сложных консьюмеров чаще не требуется — важнее читать схему потока.

Offset — порядковый номер записи внутри партиции, метка «до какого места дочитано». Потребитель периодически коммитит offset, чтобы после перезапуска продолжить с той же точки. Именно offset позволяет перечитать поток заново или отмотать назад.

Kafka — частый транспорт между микросервисами: сервис публикует событие, остальные реагируют, не вызывая друг друга напрямую. Это снимает жёсткую связанность и сглаживает пики нагрузки. В московских вакансиях Microservices идут рядом с Kafka в 43% случаев.

Да, но семантику выбираете вы. At-least-once доставит сообщение хотя бы раз, допуская дубли; exactly-once исключает и потери, и дубли, но требует транзакций и стоит дороже по производительности. Продакшн чаще живёт на at-least-once с идемпотентной обработкой на стороне потребителя.

ZooKeeper — внешний сервис, который раньше хранил метаданные кластера и координировал брокеров. С версии 4.0 Kafka работает без него в режиме KRaft, где координацию ведёт встроенный Raft-протокол. Для клиента ничего не меняется, но администрировать кластер стало проще.

Kafka — сам брокер и транспорт событий. Kafka Streams — библиотека поверх него для обработки потоков: агрегации, джойны, окна прямо на лету. Streams не отдельный кластер, а код внутри вашего приложения, читающий и пишущий в топики.

Зарплату определяют роль и грейд, а не сама Kafka, но медиана по вакансиям с ней — одна из самых высоких на рынке. Kafka почти не продаётся в одиночку: связки с Airflow и ClickHouse поднимают вилку ещё выше. Рынок senior-heavy, поэтому цифры смещены вверх — актуальные данные в рыночном блоке этой страницы.

Как первый навык — нет: junior-вакансий с Kafka всего 5.8%, рынок сильно смещён к senior (59.8%). Вход идёт через смежный стек — SQL, REST API, PostgreSQL, Docker, — а Kafka добавляется поверх. Джуну хватит понимать продюсера, консьюмера и зачем нужны партиции.

Системный аналитик — главная роль со скиллом Kafka: 1099 упоминаний, больше, чем у Java-разработчиков. Аналитику Kafka нужна, чтобы проектировать контракты событий, описывать поток между сервисами и понимать, где рвётся доставка. Код писать не обязательно — важнее схема топиков и семантика доставки.

Event streaming — обработка данных как непрерывного потока событий, а не разовых запросов. Каждое действие (заказ, клик, платёж) становится событием в топике, которое читают в реальном времени. Kafka — самый распространённый движок для такой модели.