Apache Kafka: что это такое и как работает
Apache Kafka — это распределённая платформа потоковой передачи событий, разработанная в LinkedIn в 2011 году и переданная в Apache Software Foundation. Kafka обрабатывает миллионы сообщений в секунду при задержке менее 10 мс и горизонтально масштабируется на тысячи узлов. Используется в микросервисной архитектуре, IoT-системах, аналитике в реальном времени и надёжной интеграции между сервисами.
Последнее обновление: март 2026

Что такое брокер сообщений и зачем он нужен?
Брокер сообщений — это промежуточный слой, который принимает данные от одних сервисов (producers) и доставляет их другим (consumers), не требуя прямой связи между ними. Без брокера каждый сервис должен знать адрес каждого получателя: при 10 сервисах это уже 90 двусторонних соединений.
Типичная ситуация без брокера сообщений: сервис оплаты напрямую вызывает сервис уведомлений, сервис аналитики и сервис склада. Если хотя бы один из них недоступен — транзакция зависает. В нагруженные дни (Black Friday) прямые вызовы роняют половину системы за первые 20 минут.
Kafka решает это иначе: сервис оплаты публикует событие «payment.completed» в топик и забывает о нём. Уведомления, аналитика и склад читают топик независимо, в своём темпе. Падение сервиса уведомлений не мешает обработке платежей — Kafka хранит сообщения на диске до 7 дней (настраивается) и отдаст их, когда сервис поднимется.
Чем отличается Apache Kafka от классических очередей вроде RabbitMQ: Kafka хранит сообщения как журнал (log), а не удаляет их после доставки. Это позволяет перечитывать историю событий, строить Event Sourcing архитектуры и отлаживать систему ретроспективно.
Архитектура Apache Kafka: топики, партиции, консьюмеры
Kafka состоит из нескольких ключевых компонентов. Разберём каждый на конкретном примере.
Топик (Topic) — это именованный канал для сообщений, аналог таблицы в базе данных. Пример: топик gps.location.updates содержит координаты всех GPS-трекеров. В одной Kafka-кластере может быть тысячи топиков.
Партиция (Partition) — раздел топика. Топик gps.location.updates делится на 12 партиций: трекеры с ID 0–999 пишут в партицию 0, трекеры 1000–1999 — в партицию 1 и так далее. Это обеспечивает параллельную запись: 12 партиций обрабатывают 12 потоков одновременно. На практике 1 Kafka-сервер с 12 партициями пишет 500 000 сообщений/сек против 40 000/сек у однопоточной очереди.
Producer — клиент, который пишет в топик. Может указывать ключ сообщения (например, ID устройства), и Kafka гарантирует, что все сообщения с одним ключом попадут в одну партицию — это важно для сохранения порядка событий одного устройства.
Consumer и Consumer Group — клиенты, читающие топик. Несколько consumer-ов объединяются в группу: каждая партиция обслуживается ровно одним consumer-ом в группе. 12 партиций + 12 consumer-ов = линейное масштабирование чтения. Добавить 12-й consumer занимает 30 секунд — Kafka перераспределяет партиции автоматически (rebalance).
Offset — порядковый номер сообщения в партиции. Каждый consumer помнит свой offset: именно это позволяет читать историю с любой точки, а не только «новые» сообщения.
Broker — сервер Kafka. Кластер из 3 брокеров выдерживает падение 1 брокера без потери данных: репликация (replication factor) копирует каждую партицию на N брокеров. Стандартный production-setup: 3 брокера, replication factor 3, min.insync.replicas 2.
ZooKeeper / KRaft — до версии 2.8 Kafka использовала ZooKeeper для хранения метаданных. С версии 3.x рекомендован встроенный KRaft-режим: меньше зависимостей, быстрее старт, проще операционное обслуживание.

Apache Kafka vs RabbitMQ: что выбрать?
Оба — брокеры сообщений, но с разными сильными сторонами. Выбор зависит от задачи.
| Критерий | Apache Kafka | RabbitMQ |
|---|---|---|
| Производительность | 1–2 млн сообщ./сек | 20–50 тыс. сообщ./сек |
| Хранение сообщений | На диске (дни/недели) | Только до доставки |
| Порядок сообщений | Гарантирован в партиции | Гарантирован в очереди |
| Повторное чтение | Да, в любой момент | Нет (после ACK удаляется) |
| Маршрутизация | Простая (по топику/ключу) | Гибкая (exchange, routing key) |
| Сложность настройки | Выше | Ниже |
| Идеально для | Потоки событий, аналитика, IoT | Задачи/воркеры, RPC, сложная маршрутизация |
Практическое правило: если нужно обработать 100 000+ событий/сек, хранить историю или строить event-driven архитектуру — берите Kafka. Если у вас 10 микросервисов с несложной очередью задач — RabbitMQ проще в старте и обслуживании.
В проектах devrum.ru мы используем Kafka для GPS-телематики: 50 000+ устройств отправляют локацию каждые 30 секунд — это 1 700 сообщений/сек в пике. RabbitMQ здесь бы не справился без серьёзного шардирования.
Как запустить Apache Kafka с Docker за 5 минут
Самый быстрый способ попробовать Kafka локально — Docker Compose. С версии Kafka 3.7 ZooKeeper не нужен: используем встроенный KRaft.
# docker-compose.yml
version: '3.8'
services:
kafka:
image: apache/kafka:3.7.0
container_name: kafka
environment:
KAFKA_NODE_ID: 1
KAFKA_PROCESS_ROLES: broker,controller
KAFKA_LISTENERS: PLAINTEXT://0.0.0.0:9092,CONTROLLER://0.0.0.0:9093
KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://localhost:9092
KAFKA_CONTROLLER_QUORUM_VOTERS: 1@localhost:9093
KAFKA_CONTROLLER_LISTENER_NAMES: CONTROLLER
ports:
- "9092:9092"
Запускаем:
docker compose up -d
# Создаём топик
docker exec kafka /opt/kafka/bin/kafka-topics.sh \
--create --topic test-topic --partitions 3 \
--replication-factor 1 --bootstrap-server localhost:9092
# Публикуем сообщение
echo 'Hello Kafka' | docker exec -i kafka \
/opt/kafka/bin/kafka-console-producer.sh \
--topic test-topic --bootstrap-server localhost:9092
# Читаем
docker exec kafka /opt/kafka/bin/kafka-console-consumer.sh \
--topic test-topic --from-beginning --bootstrap-server localhost:9092
Весь стек поднимается за 15–20 секунд. Для разработки и тестирования этого достаточно. Production-кластер из 3 брокеров поднимается по аналогии — добавляем ещё 2 сервиса в compose-файл с разными KAFKA_NODE_ID.
Spring Boot + Apache Kafka: producer и consumer на Java
Интеграция Kafka в Spring Boot занимает около 30 минут. Добавляем зависимость в pom.xml:
<dependency>
<groupId>org.springframework.kafka</groupId>
<artifactId>spring-kafka</artifactId>
</dependency>
Конфигурация в application.yml:
spring:
kafka:
bootstrap-servers: localhost:9092
producer:
key-serializer: org.apache.kafka.common.serialization.StringSerializer
value-serializer: org.springframework.kafka.support.serializer.JsonSerializer
consumer:
group-id: my-service
key-deserializer: org.apache.kafka.common.serialization.StringDeserializer
value-deserializer: org.springframework.kafka.support.serializer.JsonDeserializer
properties:
spring.json.trusted.packages: "com.example.dto"
Producer — публикует события:
@Service
@RequiredArgsConstructor
public class LocationProducer {
private final KafkaTemplate<String, LocationEvent> kafkaTemplate;
public void send(LocationEvent event) {
kafkaTemplate.send("gps.location.updates", event.getDeviceId(), event);
}
}
Consumer — читает события:
@Component
public class LocationConsumer {
@KafkaListener(topics = "gps.location.updates", groupId = "analytics-service")
public void handle(LocationEvent event) {
// обработка координат, запись в ClickHouse
analyticsService.process(event);
}
}
Аннотация @KafkaListener — это всё, что нужно для запуска consumer-а. Spring Boot сам управляет пулом потоков, offset commit и обработкой ошибок. При необходимости добавляем @RetryableTopic для автоматических повторных попыток с dead letter topic.
В наших проектах на JMIX + Spring Boot мы разрабатываем мобильные приложения, которые через Kafka передают телеметрию на сервер в реальном времени. Задержка от устройства до базы данных — менее 200 мс при 50 000 одновременных соединений.
Kafka UI: мониторинг топиков в браузере
Kafka UI — open-source веб-интерфейс для управления кластером Kafka. Позволяет просматривать топики, сообщения, consumer groups и lag (отставание consumer-а от producer-а) без командной строки.
Добавляем в docker-compose.yml:
kafka-ui:
image: provectuslabs/kafka-ui:latest
container_name: kafka-ui
ports:
- "8080:8080"
environment:
KAFKA_CLUSTERS_0_NAME: local
KAFKA_CLUSTERS_0_BOOTSTRAPSERVERS: kafka:9092
depends_on:
- kafka
После запуска открываем http://localhost:8080. Видим все топики, количество сообщений в каждой партиции, offset текущих consumer groups и метрики broker-а. Consumer lag больше нуля сигнализирует: consumer не успевает за producer-ом, нужно масштабировать — добавляем инстансы сервиса, и Kafka автоматически перераспределяет партиции.
Это особенно важно в IoT-системах, где пики нагрузки (утренний запуск автопарка, смена смены на заводе) дают 10-кратный рост трафика за 2–3 минуты.
Когда использовать Apache Kafka?
Kafka оправдана, если хотя бы одно из условий выполняется:
- Объём > 10 000 сообщений/сек — Kafka держит нагрузку без деградации. RabbitMQ начнёт требовать шардирования уже при 50 000/сек.
- Нужна история событий — Event Sourcing, ретроспективная аналитика, аудит изменений. Kafka хранит данные неделями, а не секундами.
- Несколько независимых потребителей одного события — оплата публикует одно событие, его читают: аналитика, CRM, склад, уведомления. Добавить нового потребителя без изменения producer-а — это ключевое преимущество Kafka.
- Микросервисная архитектура — слабое связывание через топики вместо синхронных HTTP-вызовов. Каждый сервис независимо масштабируется и деплоится.
- Потоковая обработка — совместно с Kafka Streams или Apache Flink можно агрегировать, фильтровать и трансформировать данные прямо в потоке, не дожидаясь батчевой загрузки.
Kafka избыточна для простых задач: очередь email-рассылки на 100 писем/час, простая асинхронная обработка заявок на сайте с трафиком 500 человек/день. Здесь достаточно RabbitMQ или даже Redis Streams.
Если вы строите микросервисную архитектуру и выбираете инструменты, посмотрите наш разбор микросервисы против монолита — там же описываем, когда оба подхода сочетаются с Kafka.
Часто задаваемые вопросы об Apache Kafka
Что такое kafka простыми словами?
Kafka — это почтовый ящик для программ. Одна программа кладёт письмо (сообщение) в ящик, другие — забирают его в своё время. Ящик не теряет письма и может хранить их неделями. Разница с обычной почтой: тысячи программ могут читать одно и то же письмо независимо.
Сколько сообщений в секунду обрабатывает Kafka?
Один сервер Kafka на обычном железе (8 CPU, 32 GB RAM, SSD) обрабатывает 500 000–1 000 000 сообщений/сек при размере сообщения 1 KB. Кластер из 3 серверов — 2–3 млн/сек. Это на порядок больше, чем RabbitMQ или ActiveMQ на том же железе.
Kafka это база данных?
Kafka — не база данных в классическом смысле, но хранит данные на диске. Нельзя делать SQL-запросы или искать по произвольному ключу. Kafka хранит данные как последовательный журнал (append-only log) и оптимизирована для последовательного чтения/записи. Для аналитики поверх Kafka-данных используют ClickHouse, Apache Druid или BigQuery.
Можно ли использовать Kafka без ZooKeeper?
Да, начиная с Apache Kafka 3.3 режим KRaft (Kafka Raft Metadata) достиг production-ready статуса. Kafka 4.0 полностью отказалась от ZooKeeper. KRaft упрощает кластер: меньше процессов, быстрее старт, меньше операционных проблем. Для новых проектов рекомендуем сразу использовать KRaft.