Что такое Apache Kafka
Apache Kafka — это не message broker. Это утверждение звучит парадоксально, если вы впервые слышите о Kafka. Большинство разработчиков впервые встречают её как «очередь для микросервисов». Но такое понимание ограничено и не объясняет, почему Kafka стала центральной инфраструктурой в Netflix, Uber, LinkedIn и тысячах других компаний.
Kafka — это распределённый commit log и платформа потоковой обработки событий (event streaming platform). Разница с привычными брокерами сообщений фундаментальная.
Kafka — не message broker
Традиционный message broker (RabbitMQ, ActiveMQ, IBM MQ) реализует паттерн point-to-point queue: сообщение отправлено — один потребитель его забрал — сообщение удалено. Брокер — это промежуточный посредник, который держит сообщение ровно до момента доставки.
Kafka работает принципиально иначе. В её основе лежит append-only log — неизменяемая последовательность записей, в которую данные добавляются только в конец. Это та же структура данных, что и:
- WAL (Write-Ahead Log) в PostgreSQL и MySQL
- Raft log в распределённых системах на основе консенсуса
- Binlog в MySQL репликации
- Журнал транзакций в системах event sourcing
Ключевое следствие из append-only природы: сообщения не удаляются после прочтения. Они хранятся на диске согласно настройке retention.ms (по умолчанию 7 дней) или retention.bytes. Потребитель не «забирает» сообщение — он читает его, продвигая свой offset (порядковый номер в log).
Offset — это просто целое число. Partition содержит записи с offset 0, 1, 2, 3… Каждый consumer group хранит свой offset независимо от других. Это единственное, что Kafka помнит о потребителе.
Что это означает на практике
Если у вас три consumer group читают один и тот же топик, каждая из них ведёт свой offset. Consumer group A на offset 1000, consumer group B — на offset 500, consumer group C — на offset 2000. Они не мешают друг другу. Consumer group A не удаляет сообщения, которые ещё не прочла group B.
Это невозможно в RabbitMQ или ActiveMQ — там сообщение удаляется после первого successful acknowledgement.
Kafka vs традиционные очереди
Понять Kafka проще всего через сравнение с системами, которые разработчики уже знают.
| Свойство | RabbitMQ | ActiveMQ (JMS) | Apache Kafka |
|---|---|---|---|
| Модель доставки | Push (broker → consumer) | Push (JMS MessageListener) | Pull (consumer сам читает) |
| Удаление после чтения | Да | Да | Нет (TTL-based retention) |
| Replay прошлых событий | Нет | Нет | Да (rewind offset) |
| Несколько consumer groups | Нет (fan-out через exchange) | Нет (topic duplicates) | Да, нативно |
| Пропускная способность | Сотни тысяч msg/s | Десятки тысяч msg/s | Миллионы msg/s |
| Гарантии порядка | Per-queue | Per-queue | Per-partition |
| Персистентность | Опциональная | Опциональная | По умолчанию |
| Горизонтальное масштабирование | Ограниченное | Ограниченное | Нативное (партиции) |
RabbitMQ отлично подходит для task queues, где важна сложная маршрутизация через exchanges и bindings. Если вы хотите point-to-point delivery с гибкой топологией маршрутов — RabbitMQ уместен.
ActiveMQ реализует JMS-спецификацию и хорошо интегрируется с Java EE экосистемой. Паттерн request-reply с correlation ID — его forte.
Kafka выигрывает там, где важны: высокая пропускная способность, долгосрочное хранение событий, replay, независимые consumer groups и масштабирование до миллионов событий в секунду.
Kafka — неправильный выбор для request-reply паттернов (RPC через сообщения), low-latency одиночных задач (менее 10 мс latency), и сложной маршрутизации на уровне брокера. Для этого RabbitMQ и ActiveMQ подходят лучше.
Экосистема Apache Kafka
Kafka — это не один инструмент, а целая экосистема. Понимание её компонентов критически важно для архитектурных решений.
Producers
Producers: приложения, сервисы, микросервисы, которые публикуют события в Kafka. Используют KafkaProducer API. Отправляют ProducerRecord с topic, key, value.Connect Source
Kafka Connect Source: коннекторы для чтения из внешних систем (PostgreSQL CDC, MySQL binlog, S3, Elasticsearch) без написания кода продюсера.Streams Output
Kafka Streams (as producer): обработанные потоки, записанные обратно в Kafka. Результат stream processing — новый топик.Kafka Broker Cluster (KRaft)
Kafka Broker Cluster: группа брокеров (серверов), которые совместно хранят топики. Kafka 4.0 использует KRaft — встроенный Raft-протокол без ZooKeeper. Брокеры хранят партиции как append-only log-файлы на диске.Schema Registry
Schema Registry: централизованное хранилище Avro/Protobuf/JSON Schema схем. Producers регистрируют схему, consumers получают её по ID. Обеспечивает schema evolution — backward/forward compatibility.Consumer Groups
Consumer Groups: группа потребителей с общим group.id. Партиции топика равномерно распределяются между членами группы. Каждая группа ведёт свой offset — несколько групп читают независимо.Connect Sink
Kafka Connect Sink: коннекторы для записи из Kafka во внешние системы (S3, Snowflake, Elasticsearch, PostgreSQL). Connector framework управляет offset, retry, exactly-once.Kafka Streams
Kafka Streams: библиотека потоковой обработки на JVM. Stateful операции (windowing, joins, aggregations) с state stores (RocksDB). Топология = граф обработки из Source → Processor → Sink.ksqlDB
ksqlDB: SQL-интерфейс поверх Kafka Streams. Позволяет писать потоковые запросы на SQL: CREATE STREAM, CREATE TABLE, SELECT с windowing. Персистирует состояние в Kafka топиках.Ключевые компоненты экосистемы:
Kafka Broker Cluster — ядро системы. Хранит данные, управляет репликацией, обслуживает producers и consumers. Kafka 4.0 использует KRaft-протокол (Raft-based координация) без внешнего ZooKeeper.
Schema Registry — централизованный реестр схем данных. Критически важен в production: без него изменение формата сообщений может сломать потребителей. Поддерживает Avro, Protobuf, JSON Schema.
Kafka Connect — фреймворк для интеграции с внешними системами без написания кода. Source connectors (читают данные в Kafka), Sink connectors (пишут из Kafka в хранилища). Сотни готовых коннекторов в экосистеме.
Kafka Streams — библиотека потоковой обработки. Stateful операции, windowing, joins между топиками. Работает как обычная Java-библиотека — не требует отдельного кластера.
ksqlDB — SQL-интерфейс для потоковой обработки. Хорошо подходит для аналитических команд, которые знают SQL, но не хотят писать Kafka Streams-код.
Место Kafka в современной архитектуре
Kafka стала центральной инфраструктурой в event-driven системах. Понимание её роли важно для принятия архитектурных решений.
Event-Driven Architecture (EDA)
В традиционной микросервисной архитектуре сервисы общаются напрямую: Order Service вызывает Payment Service по REST/gRPC. Это создаёт temporal coupling (оба сервиса должны быть доступны в момент запроса) и tight coupling (Order Service знает о Payment Service).
Event-driven архитектура решает это через события: Order Service публикует событие OrderCreated в Kafka. Payment Service, Notification Service, Inventory Service подписываются на этот топик и реагируют независимо, асинхронно, каждый в своём темпе.
CQRS и Event Sourcing
Kafka идеально сочетается с CQRS (Command Query Responsibility Segregation) и Event Sourcing. В event sourcing состояние системы — это не строки в базе данных, а последовательность событий в append-only log. Kafka и является этим log. Текущее состояние восстанавливается воспроизведением (replay) событий с начала или со snapshot.
Kafka как «центральная нервная система»
LinkedIn, создавшая Kafka, описывает её роль так: Kafka — это центральная нервная система data infrastructure. Все системы (OLTP базы, аналитические хранилища, ML-пайплайны, мониторинг) подключены к Kafka. Данные текут через брокеры, преобразуются в Kafka Streams или ksqlDB, материализуются в конечных хранилищах через Connect.
Признак того, что Kafka нужна вашей системе: у вас более двух сервисов, которые должны реагировать на одно и то же событие, или вы хотите сохранить возможность replay исторических данных для новых потребителей.
Ключевые выводы
- Kafka — распределённый commit log, не message broker. Данные не удаляются после чтения.
- Consumer groups читают независимо — каждая группа ведёт свой offset.
- Replay — уникальная возможность Kafka: новый потребитель может прочитать события с самого начала.
- Kafka 4.0 работает без ZooKeeper — KRaft-протокол встроен в брокеры.
- Экосистема включает Connect, Streams, ksqlDB, Schema Registry — полный набор для event-driven архитектуры.
Как создавался курс
Курс создан при участии Claude (Anthropic) как соавтора: ИИ помогал писать материалы, структурировать темы, генерировать примеры кода и диаграммы. Каждая глава проходила ручную сверку с первоисточниками — спецификациями, документацией, исходным кодом рассматриваемых систем — но гарантировать 100% точность невозможно.
Если вы заметили неточность, опечатку или хотите предложить улучшение — напишите в Telegram-группу курса. Это самый ценный вклад в курс, который вы можете сделать.
Углублённое изучение с Claude
Курс рассчитан на самостоятельное изучение, но любая теория быстрее ложится, если задавать вопросы. Рекомендую держать рядом браузерное расширение Claude (claude.com/download) — оно работает с контентом открытой страницы: выделяете кусок урока и спрашиваете напрямую.
Сценарии, которые особенно хорошо работают для углублённого погружения:
- «Объясни проще» / «дай ещё один пример» — когда формулировка из урока не дошла с первого раза.
- «Покажи, как это устроено на уровне кода / железа» — когда хочется спуститься на слой ниже того, что даёт урок.
- «Как это связано с [другая тема курса]» — когда нужно увязать концепцию с тем, что было раньше.
- «У меня в проекте стек X — как применить?» — когда хочется примерить материал на свой реальный кейс.
Это не замена курсу, а способ ускорить интеграцию материала в вашу картину мира. Если что-то из ответов Claude расходится с уроком — присылайте в Telegram-группу, курс будет уточнён.
Нашли ошибку?
Если заметили неточность, опечатку или хотите предложить улучшение:
Telegram-канал
Подписывайтесь, чтобы узнавать об обновлениях и новых курсах: