Из каких модулей состоит Kafka

Архитектура Apache Kafka: Ключевые модули

Apache Kafka — это распределенная система потоковой передачи событий, построенная по модульному принципу. Ее архитектура состоит из нескольких ключевых модулей (компонентов), которые работают согласованно для обеспечения высокой пропускной способности, отказоустойчивости и горизонтальной масштабируемости. Ниже представлены основные модули, составляющие ядро Kafka.

Основные компоненты (модули) Kafka

1. Producer (Продюсер)

Producer — это клиентское приложение или библиотека, отвечающая за публикацию (запись) данных в Kafka. Продюсеры отправляют сообщения в определенные топики (topics). Ключевые особенности:

• Поддерживают асинхронную и синхронную отправку.
• Могут использовать партиционирование (partitioning) для определения, в какую партицию топика отправить сообщение (на основе ключа или рандомно).
• Обеспечивают гарантии доставки (acks=0, 1, all).
• Имеют встроенные механизмы повторной отправки при ошибках.

Пример простого продюсера на Java:

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");

Producer<String, String> producer = new KafkaProducer<>(props);
ProducerRecord<String, String> record = new ProducerRecord<>("my-topic", "key", "value");
producer.send(record);
producer.close();

2. Consumer (Консьюмер)

Consumer — клиент, который читает (потребляет) данные из топиков Kafka. Консьюмеры работают в рамках консьюмер-групп (consumer groups), что позволяет масштабировать обработку и обеспечивать отказоустойчивость.

• Каждое сообщение в партиии считывается только одним консьюмером в рамках группы.
• Автоматически или вручную управляют смещениями (offsets) — указателями на последнее прочитанное сообщение.
• Поддерживают различные модели доставки: "at-most-once", "at-least-once", "exactly-once".

Пример консьюмера:

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("group.id", "test-group");
props.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
props.put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");

KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props);
consumer.subscribe(Arrays.asList("my-topic"));
while (true) {
    ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));
    for (ConsumerRecord<String, String> record : records) {
        System.out.printf("offset = %d, key = %s, value = %s%n", record.offset(), record.key(), record.value());
    }
}

3. Broker (Брокер)

Broker — это сервер (нода) в кластере Kafka. Кластер состоит из одного или нескольких брокеров, образующих распределенную систему. Каждый брокер:

• Хранит партиции (partitions) топиков, которые ему назначены.
• Обрабатывает запросы на чтение и запись от продюсеров и консьюмеров.
• Участвует в репликации данных между брокерами для обеспечения отказоустойчивости.
• Координируется с другими брокерами через контроллер (один из брокеров, избранный лидером для управления метаданными).

4. Topic (Топик) и Partition (Партиция)

Это не модули в смысле процессов, но фундаментальные логические и физические единицы организации данных.

• Topic — именованная категория или лог событий, в которые публикуются сообщения. Это логическая группа сообщений.
• Partition — физическое разделение топика. Каждый топик делится на одну или несколько партиций, которые распределяются по брокерам кластера. Партиции обеспечивают параллелизм (как в записи, так и в чтении) и масштабируемость. Сообщения в партиции упорядочены и имеют уникальный offset.

5. ZooKeeper (вплоть до версии 2.8) / Контроллер и Raft-протокол (Kafka Raft Metadata mode, KRaft, начиная с 2.8+)

Этот модуль отвечает за координацию и управление метаданными кластера.

• В традиционной архитектуре (до версии 2.8) Kafka использовала Apache ZooKeeper как внешнюю систему для:

    *   Выбора **контроллера** брокера (лидера, управляющего метаданными).
    *   Хранения конфигурации топиков, списка брокеров, ACL.
    *   Отслеживания жизненного цикла брокеров и консьюмер-групп.

• В современной архитектуре (Kafka 3.0+ с режимом KRaft) Kafka избавилась от зависимости от ZooKeeper. Функции координации перешли в сам кластер Kafka:

    *   Метаданными управляет **контроллер-квиорум** брокеров, использующий **Raft-консенсус** протокол.
    *   Это упрощает развертывание, повышает производительность и отказоустойчивость.

6. Connector и Streams (Модули для интеграции и обработки)

• Kafka Connect — это отдельный фреймворк и набор инструментов для масштабируемого и надежного подключения Kafka к внешним системам (базы данных, хранилища, облачные сервисы). Состоит из:

    *   **Source Connectors** (импорт данных в Kafka).
    *   **Sink Connectors** (экспорт данных из Kafka).

• Kafka Streams — это библиотека для потоковой обработки данных непосредственно внутри приложений Java/Scala. Позволяет строить сложные топологии обработки с операциями фильтрации, агрегации, соединения потоков и т.д.

Взаимодействие модулей: краткое резюме

1. Продюсеры публикуют потоки сообщений в топики, которые физически разделены на партиции, распределенные по брокерам кластера.
2. Консьюмеры (объединенные в группы) читают сообщения из этих партиций, отслеживая свою позицию через offset.
3. Брокеры хранят данные, обрабатывают запросы и реплицируют партиции для надежности.
4. Координационный слой (ZooKeeper или KRaft-квиорум) обеспечивает целостность метаданных и отказоустойчивость кластера.
5. Connect и Streams расширяют экосистему, обеспечивая интеграцию и сложную обработку данных поверх ядра Kafka.

Такая модульная архитектура делает Kafka чрезвычайно гибкой, позволяя независимо масштабировать каждый слой (хранение, обработку, интеграцию) и адаптировать систему под самые разные сценарии — от простого логгирования до сложных event-driven архитектур и потоковой аналитики в реальном времени.