Відповідь (Senior+)

Producer Acknowledgment (acks) — це параметр конфігурації продюсера, який визначає, скільки підтверджень від реплік брокера має отримати продюсер, щоб вважати запис повідомлення успішним. Це головний важіль управління балансом між надійністю (Durability) і швидкістю (Latency).

1. Режими ACKS

acks = 0 (Fire and Forget)

Продюсер не чекає жодного підтвердження від брокера. Повідомлення вважається успішно відправленим, щойно воно потрапило в мережевий буфер.

• Latency: Мінімальна.
• Reliability: Нульова. Якщо брокер впав або в мережі стався збій — дані втрачені назавжди.
• Use Case: Збір логів або метрик, де втрата 1-2% даних допустима.

acks = 1 (Leader Only) — За замовчуванням до Kafka 3.0. Починаючи з Kafka 3.0 (KIP-316) дефолт змінено на acks=all.

Продюсер чекає підтвердження тільки від Лідера партиції. Лідер записує дані у свій локальний лог і одразу відповідає продюсеру.

• Latency: Середня.
• Reliability: Середня. Якщо Лідер впав одразу після відповіді продюсеру, але до того, як Follower’и встигли скопіювати дані — вони будуть втрачені.
• Use Case: Загальні бізнес-події, які не потребують екстремальної надійності.

acks = all (або -1) — За замовчуванням у нових версіях

Продюсер чекає підтвердження від Лідера і всіх синхронних реплік (ISR).

• Latency: Максимальна (обмежена найповільнішою реплікою в ISR).
• Reliability: Максимальна. Дані гарантовано збережені на кількох вузлах.
• Use Case: Фінансові транзакції, критичні дані.

2. Зв’язок з min.insync.replicas

Senior-інсайт: Параметр acks=all сам по собі не гарантує запис на кілька вузлів. Якщо в ISR залишився тільки один Лідер, acks=all перетвориться на acks=1. Щоб гарантувати реальну надлитковість, потрібно використовувати параметр min.insync.replicas на рівні брокера або топика (наприклад, встановити його в 2 при replication.factor=3).

3. Вплив на ретраї (Retries)

При використанні acks=1 або all продюсер може отримувати помилки (наприклад, NotLeaderForPartitionException). У цьому випадку він буде автоматично робити повторні спроби (retries), якщо це налаштовано. При acks=0 ретраї неможливі, оскільки продюсер не знає про помилку.

Резюме для Senior

• acks=0: Швидкість будь-якою ціною.
• acks=1: Баланс (небезпечно при падінні лідера).
• acks=all: максимальна надійність, але вища latency (очікування найповільнішої ISR репліки) і нижча доступність (при ISR < min.insync.replicas запис блокується).
• Завжди використовуйте acks=all разом з min.insync.replicas >= 2 для критичних даних.
• Пам’ятайте, що acks=all захищає від втрати даних, але не від дублікатів (для цього потрібна ідемпотентність).

---

🎯 Шпаргалка для інтерв’ю

Обов’язково знати:

• acks=0 — fire and forget, мінімальна latency, нульова reliability
• acks=1 — підтвердження від лідера, середня reliability; при падінні лідера дані втрачені
• acks=all — підтвердження від всіх ISR, максимальна reliability; вища latency
• acks=all без min.insync.replicas>=2 = acks=1 якщо ISR=1
• Дефолт змінився: до Kafka 3.0 — acks=1; з Kafka 3.0 (KIP-316) — acks=all
• Retries можливі при acks=1/all; при acks=0 продюсер не знає про помилку
• acks=all захищає від втрати, але не від дублікатів (потрібна ідемпотентність)

Часті уточнюючі запитання:

• Чому acks=all без min.insync.replicas недостатній? — Якщо ISR=1, acks=all = acks=1.
• Який дефолт в Kafka 3.0+? — acks=all (KIP-316), раніше був acks=1.
• Що буде при acks=all і ISR < min.insync.replicas? — NotEnoughReplicasException, запис відхиляється.
• acks=all сповільнює запис? — Так, latency обмежена найповільнішою ISR реплікою.

Червоні прапорці (НЕ говорити):

• «acks=0 для production даних» — нульова гарантія доставки
• «acks=all гарантує запис на кілька вузлів без min.insync.replicas» — якщо ISR=1, то на один
• «acks=0 підтримує retries» — продюсер не знає про помилку
• «acks=all захищає від дублікатів» — ні, потрібна ідемпотентність

Пов’язані теми:

• [[16. Що таке реплікація в Kafka]]
• [[18. Що таке ISR (In-Sync Replicas)]]
• [[9. Які гарантії доставки повідомлень надає Kafka]]
• [[23. Що таке idempotent producer]]