Кто занимался администрированием Kafka

Что проверяют

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

Как отвечать

Сразу обозначьте границу. Например: «Кластер держала платформенная команда, мы заказывали топики и отвечали за свои консьюмеры». Затем покажите, что понимаете ту часть, которая касается разработчика:

• топики: число партиций задаёт предел параллелизма консьюмер-группы, уменьшить его нельзя, а увеличение ломает порядок по ключу;
• надёжность: replication.factor=3, min.insync.replicas=2 и acks=all у продюсера вместе дают запись без потерь при падении одного брокера;
• продюсер: идемпотентность enable.idempotence включена по умолчанию начиная с Kafka 3.0;
• хранение: на уровне топика это retention.ms и cleanup.policy, например compact для топиков с последним состоянием по ключу;
• диагностика: kafka-consumer-groups.sh --describe --group показывает лаг по партициям, в интерфейсе то же дают Kafka UI или AKHQ;
• ребалансы: частые ребалансы из-за долгой обработки лечатся настройкой max.poll.interval.ms и max.poll.records.

Если администрировали сами, говорите про KRaft (в Kafka 4.0 ZooKeeper удалён полностью), про перенос партиций через kafka-reassign-partitions.sh или Cruise Control, про оператор Strimzi в Kubernetes.

Где спотыкаются

Называют администрированием работу через Spring Kafka. Первый же вопрос про перераспределение партиций или обновление брокеров это вскрывает.

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

Приводят цифры вроде «ускорил кластер на 30%» без условий замера. Лучше рассказать конкретный случай: лаг рос, причина была в медленной обработке, что поменяли и как проверили.