Вопросы и ответы для собеседования по Kafka: 22 вопроса о партициях, потребителях и доставке

Собеседования по Kafka проверяют, понимаете ли вы, как данные движутся через лог: как топики делятся на партиции, на какой порядок можно полагаться, как консьюмеры распределяют работу между собой и что происходит при сбое. Вопросы-сценарии про лаг, дубликаты и потерю данных встречаются постоянно, потому что именно с этими проблемами люди сталкиваются в продакшене.

Ниже — 22 вопроса с ответами. Такие детали, как значения по умолчанию, различаются между версиями Kafka, поэтому упоминайте, что вы бы уточнили используемую версию.

Основные концепции

1. Что такое Kafka и для чего её используют?

Kafka — это распределённый реплицируемый лог коммитов. Продюсеры добавляют записи в топики, а консьюмеры читают их в своём темпе. Её применяют для потоковой передачи событий, пайплайнов логов и метрик, развязки сервисов, передачи данных в аналитические системы и потоковой обработки.

2. Что такое топики, партиции и офсеты?

Топик — это именованный поток записей. Каждый топик разбит на партиции, и каждая партиция представляет собой упорядоченный лог, в который можно только добавлять записи. У каждой записи в партиции есть офсет — последовательный номер, определяющий её позицию. Офсеты уникальны только в пределах партиции.

3. Как партиции влияют на порядок?

Kafka гарантирует порядок только в пределах партиции. Записи с одинаковым ключом по умолчанию попадают в одну и ту же партицию, поэтому сохраняют порядок относительно друг друга. Между партициями порядка нет. Если вам нужны все события по одному клиенту в правильном порядке, используйте в качестве ключа ID клиента.

4. Что такое брокер и чем занимается контроллер?

Брокер — это сервер Kafka, который хранит партиции и обслуживает клиентов. В кластере несколько брокеров. Один из них выполняет роль контроллера, который управляет метаданными кластера и лидерством партиций. В более новых версиях Kafka для этих метаданных вместо ZooKeeper используется KRaft — встроенный механизм консенсуса.

5. Как работает репликация?

У каждой партиции есть фактор репликации. Одна реплика является лидером, который обрабатывает чтение и запись, а остальные — фолловерами, которые её копируют. Синхронные реплики (ISR) — это те, что успевают за лидером. Если лидер выходит из строя, новый лидер выбирается из ISR.

Продюсеры

6. Что означают настройки acks?

Для надёжной записи используйте acks=all с min.insync.replicas не меньше 2 и фактором репликации 3.

7. Как избежать дубликатов сообщений от продюсера?

Включите идемпотентный продюсер (enable.idempotence=true) — это позволяет брокеру отбрасывать дубликаты, возникшие из-за повторных попыток в пределах партиции. Для записей, которые должны атомарно охватывать несколько партиций или топиков, используйте транзакции.

8. Как продюсер выбирает партицию?

Если вы задаёте ключ, стандартный партиционер хеширует его, чтобы выбрать партицию. Без ключа продюсер распределяет записи по партициям (в последних версиях применяется «липкий» подход для эффективного заполнения батчей). Можно также написать собственный партиционер.

9. Что влияет на пропускную способность продюсера?

Батчинг (batch.size, linger.ms), сжатие (например, lz4 или zstd), количество партиций и acks. Более крупные батчи и сжатие обычно повышают пропускную способность ценой небольшого роста задержки.

Потребители

10. Что такое группа потребителей?

Это набор потребителей, которые совместно читают топик. Каждая партиция в каждый момент времени назначается одному потребителю в группе. Поэтому число полезных потребителей в группе ограничено числом партиций, а лишние потребители простаивают.

11. Что происходит во время ребалансировки?

Когда потребитель присоединяется или покидает группу, либо меняются партиции, группа перераспределяет партиции. При классической ребалансировке потребление приостанавливается на время этого процесса. Кооперативная ребалансировка и статическое членство уменьшают disruption. Частые ребалансировки часто возникают из-за потребителей, которые слишком долго обрабатывают (max.poll.interval.ms) или пропускают heartbeats.

12. Как коммитятся offset'ы?

Потребители коммитят offset следующей записи для чтения, который хранится во внутреннем топике. Автокоммит прост, но может закоммитить до завершения обработки. Ручные коммиты после обработки дают вам контроль над тем, что считается «готово».

13. Что означают at-most-once, at-least-once и exactly-once?

• At-most-once: коммит offset'а до обработки. При сбое записи могут быть потеряны.
• At-least-once: сначала обработка, потом коммит. При сбое возможна повторная обработка, поэтому дубликаты возможны.
• Exactly-once: эффект происходит один раз. В Kafka это возможно внутри Kafka с помощью идемпотентных продюсеров, транзакций и потребителей с read_committed. При записи во внешнюю систему обычно нужны идемпотентные записи или дедупликация по ключу.

Хороший ответ говорит, что «exactly once» зависит от того, где находятся побочные эффекты.

14. Как бы вы обработали poison message, которая всегда падает?

Поймать ошибку, повторить ограниченное число раз, затем отправить запись в dead-letter топик с деталями, закоммитить offset и продолжить. Настроить алерт на dead-letter топик, чтобы кто-то разобрался.

Операции и сценарии

15. Consumer lag растёт. Как вы будете диагностировать?

1. Проверить, на каких партициях есть lag. Одна горячая партиция указывает на перекошенный ключ. Lag везде указывает на медленную обработку или слишком мало потребителей.
2. Проверить время обработки на запись и вызовы downstream, например к базе данных.
3. Проверить наличие частых ребалансировок.
4. Проверить, не выросла ли скорость продюсера.
5. Исправить с помощью большего числа потребителей (до количества партиций), более быстрой обработки, пакетной обработки или большего числа партиций.

16. Когда следует увеличивать число партиций?

Когда вам нужно больше параллелизма, чем могут обеспечить текущие потребители, или пропускная способность на партицию является ограничением. Будьте осторожны: добавление партиций меняет маппинг ключа на партицию для новых записей, поэтому порядок для ключа может нарушиться при изменении. Планируйте число партиций заранее, когда порядок важен.

17. Как хранятся данные и что такое log compaction?

По умолчанию Kafka удаляет старые сегменты по времени или размеру (retention.ms, retention.bytes). При log compaction Kafka сохраняет как минимум последнее значение для каждого ключа, что подходит для changelog или топика, похожего на таблицу. Нулевое значение (tombstone) помечает ключ для удаления.

18. Что произойдёт, если брокер упадёт?

Партиции, лидируемые этим брокером, выбирают новых лидеров из ISR. Клиенты обновляют метаданные и продолжают работу. Если нет доступной синхронизированной реплики, партиция недоступна, если только вы не разрешите unclean leader election, что рискует потерей данных.

19. Как защитить кластер Kafka?

TLS для шифрования при передаче, SASL (например, SCRAM или OAuth) или mutual TLS для аутентификации, ACL для авторизации на топики и группы, а также сетевые контроли. При необходимости шифруйте чувствительные поля на уровне приложения.

20. Как мониторить Kafka?

Ключевые сигналы — consumer lag, under-replicated партиции, offline партиции, задержка запросов, использование диска, а также скорости сжатия и расширения ISR, собираемые через JMX-метрики и инструменты вроде Prometheus и Grafana.

Вопросы по проектированию

21. Когда вы выберете Kafka вместо очереди сообщений, такой как RabbitMQ или SQS?

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

22. Спроектируйте пайплайн событий заказов.

«Заказы идут в топик orders с ключом по ID заказа, чтобы события для заказа сохраняли порядок. Я бы использовал три или более брокеров, replication factor 3, acks=all и идемпотентных продюсеров. Потребители для биллинга, инвентаря и аналитики используют каждый свою группу. Записи биллинга идемпотентны по ID заказа, неудачные записи идут в dead-letter топик, и я бы мониторил lag по каждой группе. Число партиций я бы выбрал исходя из пиковой пропускной способности и ожидаемого числа потребителей, с запасом на рост.»

Как подготовиться

Если есть возможность, запустите Kafka локально, напишите продюсера и группу потребителей, остановите одного потребителя и понаблюдайте за ребалансировкой. Сломайте что-нибудь намеренно — например, сделайте потребителя медленным — и посмотрите, как растёт лаг. Подготовьте одну реальную историю о проблеме в пайплайне данных, которую вы решили. По смежным темам смотрите наши руководства по вопросам на собеседовании по Databricks и интервью по системному дизайну.

Потренируйтесь объяснять гарантии доставки вслух — именно здесь ответы обычно становятся расплывчатыми. Мок-интервью и расшифровка записи покажут, где именно. Соблюдайте правила работодателя насчёт AI-инструментов на любом живом интервью.