Александр Шпагин пишет:

✉️ Пост 39. И снова про кафку. Гарантии доставки в Kafka для продюсера - что на самом деле происходит Очень частое заблуждение - «Kafka супер надежная, значит сообщение точно не потеряется» Нет. Kafka надежная ровно настолько, насколько ты ее настроил И главный параметр здесь - acks 🧠 Что вообще происходит при отправке сообщения Когда продюсер отправляет сообщение: 1️⃣ Он пишет его в лидера партиции 2️⃣ Лидер сохраняет сообщение в лог 3️⃣ Реплики копируют сообщение к себе 4️⃣ Продюсер получает подтверждение

Вопрос только один: когда считать сообщение успешно доставленным? И вот тут включается параметр acks (в простонародье - аки 😅)

⚙️ Что такое acks acks - это настройка продюсера, которая говорит: "Сколько подтверждений я хочу получить, прежде чем считать сообщение отправленным". Есть три основных режима.

🔹 acks = 0 Продюсер вообще не ждет подтверждения Он просто отправил сообщение и поехал дальше. Плюсы:

максимальная скорость
минимальная задержка Минусы:
сообщение может потеряться
если брокер упал - никто не будет в курсах

Это режим - живем быстро, умираем молодыми))

Подходит только там, где потеря допустима: всякие метрики, логи, телеметрия

🔹 acks = 1 Продюсер ждет подтверждения только от лидера партиции. Сценарий:

лидер записал сообщение - ответил продюсеру
реплики еще могут не успеть скопировать

Если лидер сразу после этого падает, а реплики не успели синхронизироваться - сообщение потеряется. Плюсы:

баланс скорости и надежности
чаще всего используется Минусы:
возможна потеря при падении лидера

Это режим - нормально, но не идеально

🔹 acks = all (или -1) Продюсер ждет подтверждения от всех синхронизированных реплик. Сценарий:

лидер записал
реплики записали
только после этого продюсер получает ack Это максимальная надежность.

Плюсы:

минимальный риск потери - прод-уровень Минусы:
выше задержка
ниже throughput Это режим спим спокойно, все четко, все под контролем

🧨 Но acks - это еще не все Acks = all не защищают от дублей, а дубли - еще одна проблема в кафке

Почему? Если продюсер отправил сообщение, не получил ответ (например, сеть лагнула) и решил повторить отправку, то Kafka может записать сообщение дважды. И вот тут появляется еще один параметр.

🚀 enable.idempotence = true (он включается на стороне продюсера) Если включить идемпотентного продюсера, Kafka будет:

отслеживать sequence
не записывать дубликаты
гарантировать exactly-once на уровне продюсера Без этого у тебя максимум at-least-once.

📦 Какие вообще бывают гарантии доставки В Kafka обычно говорят о трех уровнях: 🔹 At most once Сообщение может потеряться, но не задублируется. Это acks = 0. 🔹 At least once Сообщение точно будет доставлено, но возможны дубли. Это acks = 1 или acks = all без идемпотентности. 🔹 Exactly once Сообщение доставлено один раз без дублей. Нужно: