Основные компоненты Apache Kafka
- Broker - это узел, который отвечает за хранение и обработку сообщений. Он принимает сообщения от производителей, хранит их и передает потребителям
- Zookeeper - используется для управления и координации узлов брокера в кластере Kafka. Он отвечает за отслеживание состояния брокеров, управление разрешениями доступа и согласование лидеров разделов
- Начиная с Kafka 2.8.0, появился KIP-500 mode - режим работы без Zookeeper, а с Kafka 3.3+ этот режим стал стабильным и рекомендованным. В новых установках используют Kafka KRaft (Kafka Raft Metadata Mode) вместо Zookeeper
- Producer - приложение или процесс, который генерирует и отправляет сообщения в Kafka.
- Consumer - приложение или процесс, который получает и обрабатывает сообщения из Kafka.
- Topic - тема или категория, в которой хранятся сообщения. Producer отправляет сообщения в определенную тему, а Consumer читает сообщения из этой темы.
- Partition - Топик может состоять из нескольких партиций. Каждая партиция - это упорядоченный неизменяемый лог сообщений. Партиции позволяют Kafka горизонтально масштабировать запись и чтение.
- Consumer Group - это набор консьюмеров, которые вместе читают топик
Kafka vs Rabbit
У них разная модель доставки сообщения Kafka сама достает из топика нужное сообщение pull.
Rabbit – реализует модель проталкивания push, то есть сервер сам толкает сообщение.
Kafka добавляет сообщения в журнал, а консюмеры сами его читаю, в свою очередь
Rabbit удаляет сообщение после его обработки, а кафка продолжает его хранить, пока не наступит запланированное удаление.
Типы гарантий доставки сообщений
| Семантика | Что гарантирует | Особенности |
| At-most-once | 0 или 1 раз | Сообщение может быть потеряно, но дубликатов нет. |
| At-least-once | ≥1 раз | Сообщение гарантированно доставлено, но могут быть дубликаты. |
| Exactly-once | строго 1 раз | Kafka сама по себе не реализует полноценное Exactly-Once: чтобы достичь, нужен дополнительный механизм. Например: Outbox pattern + таблица на стороне консумера/сервиса, чтобы фильтровать уже обработанные ID сообщений. |
Идемпотентность в кафка
Идемпотентность в Apache Kafka - это функциональность, которая обеспечивает гарантию того, что сообщения не будут обработаны более одного раза. Это важно для обеспечения безопасной и надежной передачи данных между производителями и потребителями в системе Kafka.
Consumer Group Leader
В Apache Kafka лидером консюмеров является экземпляр консюмера, который отвечает за чтение данных из топика и координацию обработки сообщений другими консюмерами. Лидер консюмеров отслеживает прогресс чтения и распространяет информацию о смещениях (offset) между консюмерами в группе.
Как выбирается лидер?
- Когда консьюмер подключается к группе, Kafka Coordinator (специальный брокер для группы) уведомляет всех консьюмеров о составе группы.
- Один из консьюмеров выбирается лидером автоматически (обычно по алгоритму выбора - первым подключившимся или по консенсусу в группе).
- Лидер получает текущую информацию о партициях топиков, на которые подписана группа.
- Лидер составляет assignment - распределение партиций между консьюмерами.
Что делает лидер при ребалансировке?
- Получает от Kafka Coordinator событие ребалансировки(новый консьюмер входит в группу, консьюмер выходит/падает, меняются топики, на которые подписана группа).
- Вычисляет новое распределение партиций между консьюмерами (assignment).
- Отправляет каждому консьюмеру его список партиций.
- Все консьюмеры применяют новый assignment, продолжают читать с сохранённого оффсета.
Какие есть варианты сдвига offset
- Сообщение при отправке и принятие сдвигается автоматически
- Сдвиг происходит после обработки лидером консюмеров
- Сдвиг происходит после обработки всех консюмеров. Требует координации (кворума) между консьюмерами
commitSync() и commitAsync()
commitSync()
- Синхронный коммит. Консьюмер ждёт ответа от брокера, пока оффсет не будет подтверждён.
- Используется, если нужно гарантированно зафиксировать оффсет перед продолжением обработки.
- Обычно делают после обработки сообщения/батча, чтобы не потерять данные.
commitAsync()
- Асинхронный коммит. Консьюмер отправляет оффсет брокеру, но не ждёт подтверждения.
- Обычно делают после успешной обработки, но можно и после чтения - риск потерять последнее сообщение минимален.
Что будет, если партиций больше/меньше, чем консюмеров?
- Партиций больше, чем консьюмеров = некоторые консьюмеры читают несколько партиций.
- Партиций меньше, чем консьюмеров = лишние консьюмеры простаивают, т.к. одна партиция может принадлежать только одному консьюмеру в группе.
- Каждая партиция должна быть назначена ровно одному консьюмеру в группе.
Каким образом обеспечивается отказоустойчивость в Apache Kafka
- Репликация партиций - Каждая партиция имеет лидера и N реплик, копирующих данные
- Чтение и запись через реплики - Запись идёт на лидера, затем реплицируется на остальные. Чтение может обслуживаться с лидера или с реплик (в зависимости от настроек).
- Кворум (ack) - Операция записи считается успешной только после подтверждения от нужного числа реплик (
acks=all). Гарантирует согласованность данных. - Зеркалирование брокеров (MirrorMaker) - Позволяет иметь резервные кластеры и быстро восстанавливаться после сбоя.
- Мониторинг и авто-восстановление - Контроллер кворума отслеживает состояние брокеров, автоматически выбирает нового лидера при падении.
Schema Registry + Avro/Protobuf в Kafka
- Schema Registry - сервис, который хранит схемы сообщений и управляет их версионированием.
- Avro/Protobuf - форматы сериализации, которые используют схемы для структуры сообщений.
Классические проблемы
У kafka есть классические проблемы, с которыми сталкивался почти каждый разработчик:
| Проблема | Что происходит | Причины / Почему | Короткое решение |
|---|---|---|---|
| Message duplication | Сообщения могут приходить несколько раз | At-least-once, падение консьюмера | Idempotent producer, транзакции, фильтрация по ID |
| Consumer lag | Консьюмер отстаёт, backlog растёт | Медленная обработка, мало партиций | Добавить партиций, больше консьюмеров, оптимизация обработки |
| Stuck partitions | Консьюмер завис на партиции | Блокирующая обработка, долгий commit | Асинхронная обработка, таймауты сессии, отдельные потоки для тяжёлых задач |
| Hot partitions (skew) | Нагрузка распределена неравномерно | Несбалансированные ключи сообщений | Использовать равномерные ключи, больше партиций, custom partitioner |
| Rebalancing storm | Частые ребалансы группы | Частое подключение/отключение консьюмеров, короткий session.timeout.ms | Увеличить session.timeout.ms, стабильные consumer instances |
Kafka Streams
Спрашивают очень редко, но быть в курсе не помешает)
Kafka Streams позволяет работать с потоками данных из топиков Kafka в реальном времени, применять функции наподобие map, filter, reduce и агрегировать данные, без отдельного кластера. Отлично подходит для больших потоков событий, где нужны трансформации и агрегации “на лету”.
Итог
Сегодня мы рассмотрели ключевые аспекты и проблемы при работе с kafka. Все это часто спрашивают на собеседованиях. Список тем составлен на основе моего опыта и опыта коллег, проходивших собеседования на позиции от Junior до Senior.