Apache Kafka 4.2: Share Groups, DLQ і Kafka Streams

Apache Kafka 4.2 робить Kafka Queues на основі Share Groups придатними для production, додає dead-letter queue та розвиває server-side rebalance у Kafka Streams. Реліз розширює Kafka за межі класичної моделі, але нові можливості не слід змішувати зі звичайними consumer groups без аналізу семантики доставки.

Share Groups реалізують queue-подібну модель

У класичній consumer group partition у певний момент призначається одному consumer-у групи, а порядок тісно пов’язаний із partition. Share Groups дозволяють кільком consumers спільно обробляти records із гнучкішим розподілом і підтвердженням. Це корисно для task processing, де важливі масштабування workers і повторна доставка окремої роботи.

Kafka Queue не є повною копією іншого message broker

Модель зберігає властивості Kafka, її log і operational ecosystem. Перед міграцією черги визначте ordering, retries, visibility/lock timeout, duplicate handling, retention і backpressure. Якщо бізнес-операція не ідемпотентна, повторна доставка може створити подвійний платіж або повторний зовнішній виклик.

Для порівняння broker-ів прочитайте наш огляд RabbitMQ 4.3, а спостережуваність конвеєра можна пов’язати з міграцією на Prometheus 3.

Dead-letter queue потребує політики, а не лише topic

DLQ допомагає відокремити records, які не вдалося обробити після заданої кількості спроб. Але topic без owner, alert і процедури replay перетворюється на архів невидимих втрат. Зберігайте причину, кількість спроб, оригінальні metadata та correlation ID, водночас не дублюючи секрети або персональні дані.

Retry має бути обмеженим

Різниця між transient і permanent failure повинна бути формалізована. Миттєвий нескінченний retry створює hot loop і навантажує downstream. Використовуйте backoff, ліміт спроб і окремі метрики віку повідомлення. Replay із DLQ запускайте контрольованою швидкістю.

Kafka Streams переходить до server-side rebalance

У 4.2 розвивається новий protocol ребалансування Kafka Streams із server-side assignment. Він має зменшити складність client coordination і зробити зміни складу group передбачуванішими. Перевірте підтримку конкретного клієнта, режим увімкнення та обмеження релізу, перш ніж застосовувати до stateful topology.

State stores роблять ребалансування дорогим

Для Kafka Streams важливі не лише секунди координації, а й відновлення local state з changelog topics. Порівнюйте rebalance duration, restore rate, disk I/O і end-to-end lag. Неправильно підібраний persistent volume або повільний network storage може нівелювати покращення protocol.

Java 25 не означає обов’язковий runtime для всіх клієнтів

Kafka 4.2 розвиває підтримку сучасної Java, але broker, Connect, Streams і сторонні клієнти можуть мати різні матриці. Перевірте JVM, GC, TLS providers, monitoring agents і plugins. Не оновлюйте Java та Kafka одним кроком у всьому кластері без окремих baseline.

Observability повинна бачити нову семантику

Звичайного consumer lag недостатньо для Share Groups. Потрібні метрики delivery attempts, acknowledged/rejected records, lock timeout, DLQ rate, processing age і worker saturation. Для Streams додайте rebalance та state restore. Alert має описувати вплив на бізнес-процес, а не лише технічний threshold.

План впровадження

1. оновіть non-critical dev cluster та клієнтські libraries;
2. перевірте broker format і rolling-upgrade procedure;
3. створіть окремий пілотний workload для Share Groups;
4. реалізуйте idempotency і контрольований retry;
5. налаштуйте DLQ ownership, dashboards і replay runbook;
6. виміряйте rebalance та state recovery;
7. проведіть broker failure і network partition tests;
8. лише після цього переносьте критичний трафік.

Типові помилки з DLQ

Не переносіть до dead-letter topic повідомлення без опису помилки та версії consumer. Не дозволяйте безконтрольний replay у той самий несправний handler. Дані в DLQ підпадають під ті самі privacy та retention rules, що й основний topic. Якщо schema змінюється, інструмент replay має розуміти старі versions або виконувати явну трансформацію.

Критерії production-ready черги

Пілот повинен довести bounded retries, ідемпотентність, відновлення worker після crash і контрольовану поведінку під час broker failure. Dashboard має показувати processing age, attempts, rejects і DLQ growth. Команда повинна вміти знайти конкретну роботу за correlation ID, пояснити її статус і безпечно повторити обробку без дублювання бізнес-ефекту.

Першоджерело: офіційне оголошення Apache Kafka 4.2.