Яких питань про Kafka чекати на співбесіді?

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

• Теми та партиції. Тема поділяється на партиції, кожна з яких є упорядкованим журналом лише для дописування. Додаткове питання: чому Kafka масштабує запис додаванням партицій, а не прискоренням одного журналу?
• Зміщення. Позиція споживача в партиції. Додаткове питання: хто зберігає зафіксовані зміщення та що станеться, якщо споживач аварійно завершить роботу до фіксації?
• Групи споживачів. Споживачі в групі розподіляють між собою партиції теми, причому в певний момент кожну партицію може обслуговувати щонайбільше один споживач із групи. Додаткове питання: що станеться з пропускною здатністю, якщо в групі більше споживачів, ніж партицій?
• Брокери та контролер. Брокери зберігають партиції, а контролер керує вибором лідера й метаданими. Додаткове питання: що змінилося після перенесення метаданих Kafka із ZooKeeper до KRaft?
• Виробники та ключі. Повідомлення з ключем потрапляє до партиції, вибраної хешуванням ключа; повідомлення без ключа розподіляються між партиціями. Додаткове питання: який із цих двох варіантів зберігає порядок подій одного клієнта?

Пояснюйте механізм, а не повторюйте гасло. Сказати, що партиції забезпечують паралелізм, — лише базова вимога; пояснення, що порядок існує тільки всередині партиції, а отже ключ визначає область упорядкування, — це відповідь, яка проведе вас до наступного етапу.

Саме на цьому рівні більшість кандидатів втрачає бали, адже терміни прості, а компроміси — ні. Очікуйте, що інтерв’юер назве гарантію та попросить вас реалізувати її за допомогою налаштувань.

• Щонайбільше один раз і щонайменше один раз. Зафіксуйте зміщення до обробки — і можете втратити повідомлення; спочатку обробіть, а потім зафіксуйте — і можете обробити його двічі. Поясніть, які збої допускає кожен порядок і якому віддає перевагу ваша система.
• Ідемпотентні виробники та обробка рівно один раз. Ідемпотентний виробник усуває дублікати повторних спроб у межах партиції; транзакції поширюють це на кілька партицій і на зміщення споживачів у циклі «спожити — перетворити — створити». Будьте готові пояснити, чого обробка рівно один раз не охоплює: запис у нижчестоящу базу даних поза транзакцією все одно залишається вашою проблемою.
• acks, коефіцієнт реплікації та синхронізовані репліки. acks=all очікує на набір синхронізованих реплік; min.insync.replicas визначає, до якого мінімального розміру цей набір може скоротитися, перш ніж записи буде відхилено. Інтерв’юери часто запитують, чим ви жертвуєте заради надійності: затримкою та доступністю під час втрати брокера.
• Зберігання та ущільнення. Зберігання на основі часу або розміру видаляє старі сегменти; ущільнення журналу залишає найновіший запис для кожного ключа. Додаткове питання: який варіант підтримує журнал змін для сховища «ключ — значення» та чому?
• Перебалансування. Коли споживач приєднується або виходить, партиції перепризначаються. Додаткове питання: як тривале перебалансування впливає на чутливий до затримок сервіс і як кооперативне перебалансування та статичне членство зменшують проблему?

Корисна звичка: для кожного названого налаштування пояснюйте, якому збою воно запобігає та яку ціну додає. Така структура дає відповідь і на основне, і на додаткове питання одним реченням.

На співбесідах для досвідчених фахівців визначення замінюють сценарієм і спостерігають за вашими міркуваннями. Типове завдання: бекенд-інженера, який проходить співбесіду на платформну роль у платіжній компанії, просять спроєктувати конвеєр подій, де всі транзакції одного рахунку мають оброблятися по порядку, пропускна здатність повинна зростати разом із трафіком, а збій брокера не повинен спричиняти втрату даних. Сильна відповідь передбачає ключування повідомлень за ідентифікатором рахунку, щоб події одного рахунку потрапляли до спільної партиції, визначення кількості партицій відповідно до очікуваного пікового навантаження із запасом для зростання, налаштування реплікації та acks=all для надійності, а також пояснення того, як споживачі фіксують зміщення, щоб після збою повідомлення відтворювалися, а не пропускалися.

Інші поширені сценарії: споживач відстає — як виявити затримку та наздогнати потік; ви шкодуєте про кількість партицій теми — чому повторне розподілення порушує порядок за ключем; проблемне повідомлення спричиняє збій споживача — як шаблон черги недоставлених повідомлень ізолює його; схеми змінюються в різних виробників і споживачів — що дає реєстр схем. Інтерв’юер не шукає єдину правильну архітектуру. Він хоче, щоб ви назвали обмеження, вибрали механізм і вголос пояснили компроміс.

Перед співбесідою практикуйте ці відповіді вголос, а не лише читайте їх. Режим практики на сторінці пробної співбесіди призначений для відпрацювання сценарних питань із ШІ-інтерв’юером, який ставить додаткові питання, а ширший набір банків за посадами й темами доступний у розділі питань для співбесід за посадами й темами.

Під час розмовної співбесіди — так, у межах чесного використання. Нативний застосунок SubcueAI для macOS і Windows захоплює звук інтерв’юера та вашого мікрофона й показує короткі підказки з відповідями в локальній накладці, тож, коли інтерв’юер запитує, від чого захищає min.insync.replicas, механізм з’являється на вашому екрані, поки ви пояснюєте його власними словами. Розширення браузера робить те саме для дзвінків у вкладці браузера, захоплюючи лише звук вкладки зустрічі. Жоден із варіантів не додає бота до дзвінка й нічого не вбудовує в сторінку зустрічі; покрокове налаштування наведено на сторінці посібника.

Обмеження важливіші за рекламні обіцянки. Контрольований тест із програмування, запис екрана чи керований компанією ноутбук виходять за межі застосування, а завдання з програмування наживо, де ви маєте реалізувати споживача під наглядом, є вашою самостійною роботою. Помічник найкраще підходить для наведених вище питань про термінологію та компроміси й найгірше — для будь-яких завдань, які потрібно вводити на платформі оцінювання. Перш ніж покладатися на нього, додайте своє резюме, щоб підказки враховували роботу з Kafka, яку ви справді виконували; цей профіль зберігається в конструкторі резюме.