Какие гарантии доставки сообщений предоставляет Kafka для продюсера

Что проверяют

Знаете ли вы уровни подтверждения и понимаете ли, что даёт идемпотентный продюсер.

Как отвечать

Базовая настройка это уровень подтверждения записи:

• acks=0: отправитель не ждёт подтверждения вовсе. Максимальная скорость и реальная возможность потерять сообщение, не заметив этого. Годится для метрик, где потеря части точек несущественна;
• acks=1: подтверждает только лидер партиции. Если лидер упадёт до того, как последователи скопируют запись, сообщение потеряется;
• acks=all: подтверждают все синхронные реплики. Работает только в паре с параметром минимального числа синхронных реплик: без него при выходе всех последователей из синхронизации остаётся один лидер, и гарантия вырождается в предыдущий уровень.

Дальше про дубли. Повтор при таймауте создаёт дубль: сообщение записалось, а подтверждение не дошло. Решает идемпотентный продюсер: брокер присваивает отправителю идентификатор и отслеживает порядковые номера, отбрасывая повторы. Начиная с версии 3.0 он включён по умолчанию. Он же чинит вторую проблему: без него несколько запросов в полёте вместе с повторами могли переставить сообщения местами.

Верхний уровень это транзакции: отправитель с транзакционным идентификатором записывает в несколько партиций и тем атомарно, а потребитель с соответствующим уровнем изоляции не видит неподтверждённого. Вместе с фиксацией смещений в той же транзакции это даёт схему «прочитал, обработал, записал» ровно один раз внутри Kafka.

Важная честная оговорка: ровно один раз это гарантия внутри Kafka, а не сквозная. Как только обработчик пишет во внешнюю базу, повторы снова возможны, и получатель обязан быть идемпотентным.

Где спотыкаются

Ставят acks=all и не задают минимальное число синхронных реплик.

Считают, что идемпотентность отправителя устраняет дубли во всей системе.

Отключают повторы, чтобы избежать дублей, и теряют сообщения.

Не знают, что порядок мог нарушаться при нескольких запросах в полёте.