Всем привет!

Я работаю Senior Java Developer в одном из банков, и за последние годы мне довелось пройти не один десяток собеседований, выслушать массу неожиданных вопросов и потратить немало времени на подготовку. И вот что я понял: Kafka - одна из самых любимых и в то же время самых коварных тем на технических интервью. Независимо от уровня кандидата, вопросы по Kafka появляются почти всегда - от базовой архитектуры до тонкостей гарантий доставки и работы consumer groups.

Сегодня я хочу помочь подготовиться к вопросам по Kafka, вопросы будут разной сложности, будет интересно. Поехали!

В профиле уже есть другие части для подготовки:

1. Многопоточность без боли

2. JVM + Память + GC без боли

3. Spring без боли

4. БД без боли

❗❗Дисклеймер❗❗

Эта статья не является учебником по технологиям. Здесь я не буду углубляться в то, как всё работает под капотом или почему это устроено именно так. Это сжатая методичка по вопросам на собеседованиях - только факты, без лишней воды!

Основные компоненты 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 удаляет сообщение после его обработки, а кафка продолжает его хранить, пока не наступит запланированное удаление.

Типы гарантий доставки сообщений

Идемпотентность в кафка

Идемпотентность в 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 есть классические проблемы, с которыми сталкивался почти каждый разработчик:

Kafka Streams

Спрашивают очень редко, но быть в курсе не помешает)

Kafka Streams позволяет работать с потоками данных из топиков Kafka в реальном времени, применять функции наподобие map, filter, reduce и агрегировать данные, без отдельного кластера. Отлично подходит для больших потоков событий, где нужны трансформации и агрегации “на лету”.

Итог

Сегодня мы рассмотрели ключевые аспекты и проблемы при работе с kafka. Все это часто спрашивают на собеседованиях. Список тем составлен на основе моего опыта и опыта коллег, проходивших собеседования на позиции от Junior до Senior.

В следующей статье разберем полное собеседование на Senior Java Developer!)

Всем спасибо за внимание, удачных собесов и хорошего дня!)