Подготовка к интервью
Разбирайте реальные вопросы, сверяйтесь с подробными ответами и готовьтесь по технологиям и компаниям.
Проверьте, насколько резюме подходит выбранной позиции, и получите рекомендации по улучшению.
Каталог
Rebalance в Kafka — перераспределение partition между consumer одной группы при изменении состава, подписок или доступных partition. Его цель — назначить работу действующим участникам.
Читать ответRebalance меняет назначение partition участникам группы. Записи не перемещаются между partition, но новый владелец продолжает чтение с согласованной позиции, поэтому незакоммиченная обработка может повториться.
Читать ответОдин consumer может обрабатывать все пять partition. Для максимального параллелизма по partition в одной обычной группе достаточно до пяти consumer; шестой не получит работу из этого топика.
Читать ответОпишите реальный перенос и главное изменение контракта: синхронный ответ заменяется асинхронным процессом с состоянием, корреляцией и обработкой повторов. Это не просто замена HTTP-клиента producer-ом.
Читать ответСамописный брокер может быть оправдан узкой семантикой или историческими ограничениями, но требует самостоятельно обеспечивать надёжность и эксплуатацию. Конкретную причину выбора нужно подтвердить контекстом.
Читать ответВ classic protocol Range, RoundRobin и Sticky используют eager-перераспределение, а CooperativeSticky старается сохранить назначения и отзывать только перемещаемые partition. Это уменьшает остановку полезной обработки.
Читать ответНового лидера partition назначает контроллер из допустимых реплик; обычно это ISR, а при включённом ELR учитываются и eligible replicas. Кворум KRaft-контроллеров относится к метаданным, а не к каждой записи топика.
Читать ответREST-вызов внутри consumer связывает скорость Kafka-обработки с доступностью внешнего сервиса. Медленный вызов блокирует обработку partition, накапливает lag и может вызвать rebalance при превышении poll-интервала.
Читать ответРасскажите об объёме реальной работы: producer/consumer, схемы событий, группы, offsets, retries и наблюдаемость. Для идемпотентности объясните конкретный ключ операции и место атомарной проверки.
Читать ответKafka сохраняет порядок внутри partition, поэтому связанные события направляют по стабильному ключу и обрабатывают последовательно в этой partition. Общего порядка всего многопартиционного топика нет.
Читать ответЗащиту от дублей обычно строят на стабильном идентификаторе события и идемпотентной обработке. Факт обработки и бизнес-изменение сохраняют атомарно, а offset подтверждают после успешного результата.
Читать ответВ первые минуты проверяют бизнес-сценарии и SLO: ошибки, p95/p99 latency, throughput, ресурсы, БД и очереди. Для Kafka важны lag, его возраст, ошибки обработки и скорость накопления.
Читать ответ