Ответ (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: Средняя. Если Лидер упал сразу после ответа продюсеру, но до того, как Фолловеры успели скопировать данные — они будут потеряны.
• 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]]