Apache Kafka традиційно сприймається як платформа для стримінгу подій, а не як класична система черг. Але з виходом Apache Kafka 4.2 у проєкті з’явилася можливість, яка суттєво наближає Kafka до повноцінної моделі черг — без введення нового примітиву «queue». Про те, як до цього прийшли й що саме змінилося, розповів Andrew Schofield, principal engineer у Confluent та коммітер/PMC-учасник Apache Kafka, у розмові на подкасті Confluent Developer.
Коли Kafka намагалися використовувати як чергу — і чому це боліло
Ще до появи формальної ініціативи Queues for Kafka багато користувачів намагалися застосовувати брокер подій як класичну чергу повідомлень. Це особливо проявилося, коли почали переносити на Kafka наявні чергові застосунки.
Andrew згадує, що під час перших проєктів із замовниками стало видно типову проблему: люди «портували» старі системи, не змінюючи модель мислення. Вони просто очікували від Kafka поведінки черги, а не логів подій. У результаті виникали архітектури з «тисячами партицій без жодної притомної причини» і загальною плутаниною в експлуатації.
Коренева різниця — у самому підході до обробки. Для подієвого стримінгу Kafka надає модель consumer group, де кожен консюмер у групі отримує цілу партицію, повинен «встигати» за своїм потоком і обробляти всі повідомлення в ній. Це логічно для стримінгу подій, але незручно, коли застосунок мислить атомарними завданнями — типовими «jobs» у стилі черги, де кожен запис обробляється незалежно від попередніх.
За таких сценаріїв розробникам доводилося будувати обхідні рішення поверх Kafka, щоб наблизити її до поведінки черги. Andrew прямо говорить про «імпедансний дисбаланс», який компенсувався додатковим кодом на боці застосунків: штучне керування ack’ами, власні механізми повторних спроб, внутрішні мапінги станів. Це ускладнювало життєвий цикл системи: треба було вирішувати, хто цим керує, як це розгортається, як підтримується.
Тобто потреба в «черговій» поведінці була справжньою. Проблемою була відсутність рідної підтримки такого патерну в самій Kafka.
Чому рішенням став не новий тип «queue», а новий тип групи
Поворотним моментом у роботі Andrew над Queues for Kafka став концептуальний вибір: не винаходити у Kafka новий об’єкт «черга».
Розглядався різний досвід і різні API, зокрема традиційні JMS-підходи, проводилися експерименти. Зрештою висновок був радикально простим: усе має лишитися навколо тем. Дані вже організовані в topics, саме на них спираються схеми, Kafka Connect та інші інструменти. Ламати цю парадигму заради окремого примітиву «queue» означало б ламати екосистему.
Замість цього було обрано шлях створення нового типу групи споживачів — так званих shared groups. Логіка проста: усі як і раніше пишуть у topics, але консюмери можуть споживати ці ж теми «в іншому режимі», який поводиться як черга.
Центральне запитання, яке довелося собі поставити: «Що є сутністю черги, якщо не оголошувати її окремим типом об’єкта?» Відповідь сформувалася навколо двох ключових вимог до API.
По-перше, потрібна поведінка «record-at-a-time», тобто сталі, чіткі операції над окремими записами. Пакетна обробка не заборонена, але система зобов’язана дозволяти консюмеру мислити окремими повідомленнями, а не лише послідовністю офсетів.
По-друге, кожне повідомлення повинне мати «disposition» — зафіксований результат його обробки. Потрібен спосіб дати системі «думку» щодо кожного запису: чи був він успішно оброблений, не оброблений, виявився «поганим» тощо. Фактично це означає стан-машину на рівні окремого повідомлення, яку координує сама Kafka, а не обхідні бібліотеки.
Саме тут проявляється фундаментальна проблема старої моделі consumer group у ролі черги. Традиційно консюмер «комітить офсет» — фіксує позицію, з якої він продовжить читання. Якщо намагатися перетворити цей механізм на аналог per-message ack, доводиться комітити для кожного окремого запису. Andrew підкреслює: це не те, заради чого спочатку проєктували consumer groups, і в режимі черги це відчувається як незручність та обмеження.
Shared groups і Queues for Kafka якраз і задумувалися для того, щоб зняти цю напругу: залишити дані в topics, але дати консюмерам можливість сприймати їх як «чергові» одиниці роботи з явною фіксацією результату обробки кожного запису.
Три етапи запуску: від early access до GA в AK 4.2
Щоб таке глибоке перетворення моделі споживання не зламало екосистему, Kafka-спільнота пішла на поетапну поставку. Andrew описує Queues for Kafka як «трьохетапну доставку».
Перший етап — early access у версії 4.0. Це був старт для найперших користувачів та розробників, які могли спробувати новий тип групи, відчути семантику роботи «як черга» та дати зворотний зв’язок ще до формалізації інтерфейсу.
Другий етап — preview у Kafka 4.1. На цьому рівні функціональність стала доступною ширшому колу користувачів, але ще не декларувалася як повністю завершена. Це дозволило вже випробовувати feature на реальніших навантаженнях і сценаріях, приходити з практичними кейсами, ловити крайові випадки в API та поведінці.
Третій етап — general availability (GA) у Apache Kafka 4.2. Саме із цієї версії Queues for Kafka офіційно вважаються загальнодоступними: AK 4.2 «has GA of queues». На цей момент основні прогалини в поведінці були закриті, а архітектурні рішення усталені, зокрема й завдяки кільком додатковим KIP-ам, що виплили вже з досвіду реалізації первісної специфікації KIP‑932.
Цей багаторелізний підхід не був випадковим. Для таких функцій, які зачіпають базові моделі споживання та семантику доставки, важливо дати спільноті час перевірити ідею в бою, перш ніж закріпити її як стабільну частину продукту.
Dead-letter черги: відповідь на «отруйні» повідомлення в 4.4
Однак навіть із GA-підтримкою черг у 4.2 залишилася проблема, яку користувачі називали однією з головних: що робити з повідомленнями, які не вдається обробити?
У початковій специфікації Queues for Kafka була закладена ідея обмеженої кількості повторних спроб. Якщо запис кілька разів «ламає» консюмера, система в якийсь момент перестає його подавати, щоб не блокувати рух черги. Це принципово відрізняється від класичної моделі Kafka, де «отруйне повідомлення» може довго блокувати споживання, якщо застосунок не вміє коректно з ним поводитися.
Рішення «забрати» проблемний запис із шляху споживача знімає блокування, але відкриває інше питання: як його потім знайти і розібратися, що пішло не так? Саме тут з’являється наступний великий крок у розвитку черг — dead-letter queues.
Andrew описує це як наступну важливу фічу, яку планують доставити в Kafka 4.4. Над нею уже ведеться інженерна робота, є затверджений KIP, але в реліз 4.3 вона не встигає.
Dead-letter queues запропонують відповідь на запит «чорної скриньки» для помилкових повідомлень. Механіка, яку окреслює Andrew, проста: якщо повідомлення не вдалося доставити успішно, воно копіюється в окрему тему — dead letter queue topic. Цю тему можна розглядати як журнал усіх невдач, куди оператор або інший сервіс може заглянути, щоб дослідити проблеми, перезапустити обробку чи зробити додаткові перетворення.
Таким чином, AK 4.2 розв’язує базову задачу «чергового» споживання з явною долею кожного запису, а AK 4.4 має принести повноцінну модель роботи з помилками, якої користувачі очікували з самого початку.
Що означає нова модель для розробників Kafka-застосунків
Queues for Kafka змінюють не тільки можливості самої платформи, а й роль розробників, які будували «чергову» поведінку самотужки. Там, де раніше доводилося конструювати складні надбудови поверх стандартних consumer groups — перехоплювати винятки, крутити власні лічильники повторних спроб, організовувати обхід «отруйних» повідомлень, — тепер більша частина логіки переходить у Kafka.
Shared groups і новий API дають змогу мислити кожним записом окремо, не спираючись на грубий механізм offset commit як універсальний важіль керування. Система сама координує state-machine для кожного повідомлення, знімаючи з розробників частину відповідальності за «ручне» моделювання черги.
Поетапне введення можливостей — від early access у 4.0 до GA в 4.2 і dead-letter черг у 4.4 — показує також, як у Kafka намагаються балансувати між еволюцією та сумісністю. Черги тут не як окремий світ, а як ще один спосіб працювати з уже знайомими topics. У цьому й полягає сутність обраного підходу: замість ламати базові примітиви, проєкт додає новий режим їх використання.
Висновок
Queues for Kafka роблять Apache Kafka ближчою до класичних систем повідомлень, але без відмови від її логової природи. Новий тип групи споживачів, можливість задавати долю кожного запису і плановані dead-letter черги у версії 4.4 поступово закривають прогалини, через які раніше доводилося будувати складні власні рішення поверх брокера.
AK 4.2 уже приносить GA-підтримку черг, а наступні релізи мають добудувати навколо неї повноцінну екосистему інструментів для роботи з помилками і складними сценаріями обробки. Для Kafka це не просто ще одна фіча, а новий спосіб думати про те, які саме задачі платформа може брати на себе «рідним» способом.
Джерело
155 Contributors Later: Where Kafka Is Headed ft. Andrew Schofield | Confluent Developer