Apache Kafka: что это такое и как работает

23.03.2026

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

Последнее обновление: март 2026

Apache Kafka — брокер сообщений для распределённых систем
Apache Kafka: архитектура брокера сообщений

Что такое брокер сообщений и зачем он нужен?

Брокер сообщений — это промежуточный слой, который принимает данные от одних сервисов (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 — pipeline событий
Kafka: потоковая передача событий в реальном времени

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.