Параметр acks у Kafka producer определяет, сколько брокеров (реплик) должны подтвердить запись сообщения, чтобы отправка считалась успешной. Он настраивает баланс между задержкой и производительностью, с одной стороны, и надёжностью доставки — с другой. Основные значения: 0, 1 и all (или -1).
В Kafka параметр acks управляет тем, какое количество подтверждений от брокера(ов) должен получить producer, прежде чем считать сообщение успешно записанным. По сути, это настройка уровня гарантии доставки: чем больше подтверждений требуется, тем выше надёжность, но тем выше и задержка, и нагрузка.
Основные варианты значения acks:
acks=0 — fire-and-forget: producer не ждёт ответа от брокера. Максимальная скорость, минимальная задержка, но сообщения могут потеряться (брокер мог не принять или упасть, а producer об этом не узнает).acks=1 — успешной считается запись, подтверждённая лидирующей репликой партиции. Это разумный баланс для многих систем: сообщение может потеряться, если лидер упадёт до репликации на фолловеров, но в целом надёжность выше, чем при 0, при умеренной задержке.acks=all (или -1) — producer ждёт подтверждения от всех реплик в наборе ISR (in-sync replicas). Это наиболее надёжный режим: сообщение считается доставленным только после записи на все синхронные реплики, но задержка выше, и чувствительность к временным проблемам с репликацией тоже выше.На практике acks важно рассматривать вместе с настройками retries, delivery.timeout.ms и, при необходимости, enable.idempotence. Например, для критичных данных обычно используют acks=all и включают идемпотентный producer, чтобы добиться как минимум at-least-once, а иногда и effectively once доставки. Для менее критичных потоков, где важнее пропускная способность, часто оставляют acks=1, а acks=0 используют крайне осторожно, понимая риск потери сообщений.
Отметьте свой прогресс