Как устроено журналирование в Kafka?

Механизм журналирования (Logging) в Apache Kafka

В Apache Kafka под журналированием понимается не стандартное логирование приложений, а механизм хранения сообщений в виде упорядоченной, неизменяемой последовательности записей (Log), который является фундаментальной архитектурной концепцией системы. Это ядро, обеспечивающее надежность, производительность и отказоустойчивость Kafka.

Основные принципы устройства Log в Kafka

Топик (Topic) логически представляет собой именованный поток сообщений, а физически он разделен на партиции (partitions). Каждая партиция — это независимый, упорядоченный журнал (Log) сообщений.

Топик "orders" (Логическое представление)
    |
    ├── Партиция 0 (Физический журнал-файл на диске)
    ├── Партиция 1 (Физический журнал-файл на диске)
    └── Партиция 2 (Физический журнал-файл на диске)

Структура и физическое хранение Log-файлов

На диске каждая партиция представлена набором сегментов (segments). По умолчанию это файлы с расширениями .log и .index.

# Пример файлов партиции в директории брокера
/home/kafka/data/topic-orders-0/
├── 00000000000000000000.index   # Файл индекса смещений
├── 00000000000000000000.log     # Сегмент журнала с сообщениями
├── 00000000000000000000.timeindex # Индекс по времени
├── 00000000000000005368.index
└── 00000000000000005368.log

• .log файлы: содержат непосредственно сообщения (ключ, значение, метаданные, заголовки).
• .index файлы: позволяют быстро найти позицию сообщения в .log файле по его смещению (offset) без полного сканирования.
• .timeindex файлы: индексация по временным меткам для поиска по времени.

Ключевые характеристики механизма журналирования

1. Неизменяемость (Immutability): Сообщения, однажды записанные в Log, не могут быть изменены или удалены (в пределах политики удержания). Это упрощает модель, обеспечивает консистентность и позволяет эффективно кэшировать данные в памяти.

2. Последовательный доступ (Sequential Access): Запись происходит только в конец активного сегмента (append-only), что дает максимальную производительность на современных дисках, даже на HDD.

3. Сегментирование (Segmentation):

    *   Log делится на сегменты для управления размером.
    *   Активен всегда **только последний сегмент** для записи.
    *   Старые сегменты доступны только для чтения.
    *   Сегменты **ротируются** при достижении лимита размера (по умолчанию 1 ГБ) или времени.

1. Управление хранением и удаление:

    *   **На основе времени**: сообщения удаляются после истечения `retention.ms` (например, 7 дней).
    *   **На основе размера**: удаление при превышении общего размера Log `retention.bytes`.
    *   **Compaction (уплотнение)**: специальный режим для топиков с ключами, где сохраняется только последнее сообщение для каждого ключа. Критично для хранения состояния (`__consumer_offsets`).

// Пример конфигурации топика с выставленными политиками удержания
Properties topicConfig = new Properties();
topicConfig.put("retention.ms", "604800000"); // 7 дней в миллисекундах
topicConfig.put("retention.bytes", "1073741824"); // 1 Гигабайт
topicConfig.put("cleanup.policy", "delete"); // Или "compact"

adminClient.createTopics(Collections.singleton(
    new NewTopic("my-topic", numPartitions, replicationFactor)
        .configs(topicConfig)
));

Как работает запись и чтение

• Запись (Producer): Производитель отправляет сообщение в топик. Брокер определяет партицию (на основе ключа или round-robin) и добавляет (append) сообщение в конец Log этой партиции, присваивая ему последовательный offset. Запись синхронизируется на диск в зависимости от настроек acks и flush.

• Чтение (Consumer): Потребитель читает сообщения, указывая топик, партицию и offset, с которого начать. Брокер использует индексные файлы для быстрого позиционирования в нужном месте .log файла и потоковой передачи данных. Потребитель самостоятельно управляет своим смещением.

Важность для гарантий доставки

Механизм Log — основа высокой доступности и восстановления после сбоев:

• Репликация: каждая партиция имеет несколько реплик на разных брокерах. Одна — лидер (для записи/чтения), остальные — последователи, которые непрерывно копируют Log лидера.
• При падении лидера один из последователей с наиболее актуальным Log становится новым лидером (ISR, In-Sync Replicas).

Отличия от классического логирования

Важно не путать этот механизм хранения данных с логированием работы брокеров Kafka (для отладки и мониторинга), которое настраивается через log4j или logback и пишется в отдельные файлы (например, server.log, controller.log).

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