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

Гарантии доставки — это договорённость о том, что произойдёт с сообщением при сбоях (падение продюсера, брокера, сети, консьюмера). В Kafka нет «магической» гарантии по умолчанию: итоговое поведение получается из настроек продюсера, брокера и способа коммита offset у консьюмера.

Определение

Delivery guarantee — это правило, описывающее, может ли сообщение потеряться, может ли прийти несколько раз и в каком порядке оно будет обработано.

1. Основные режимы доставки

Kafka в типовых сценариях рассматривают в трёх режимах.

1.1. At most once (не более одного раза)

Сообщение может потеряться, но дубликатов быть не должно.

• Как обычно достигается:

  • консьюмер коммитит offset до обработки сообщения;

  • либо продюсер отправляет без подтверждений.

• Почему возможна потеря:

  • консьюмер «сказал» Kafka, что сообщение обработано, но реально ещё не обработал (и упал).

• Где применяют:

  • метрики, телеметрия, не критичные события, где потеря допустима ради простоты/скорости.

Идея «коммит до обработки»:

msg = poll()
commit_offset(msg)  # отметили как прочитанное
process(msg)        # если упадём здесь — сообщение потеряно для группы

1.2. At least once (как минимум один раз)

Сообщение не должно потеряться, но возможны дубликаты. Это самый популярный режим в продакшене.

• Как обычно достигается:

  • консьюмер обрабатывает сообщение;

  • затем коммитит offset после успешной обработки.

• Почему возможны дубликаты:

  • консьюмер обработал сообщение, но не успел закоммитить offset (упал, сеть, ребаланс).

  • после перезапуска он снова прочитает это сообщение и обработает повторно.

Идея «коммит после обработки»:

msg = poll()
process(msg)        # сделали бизнес-операцию
commit_offset(msg)  # если упадём до этого — обработаем ещё раз после рестарта

• Что важно:

  • при таком подходе бизнес-логика должна быть готова к повторной обработке (идемпотентность).

1.3. Exactly once (ровно один раз)

Это цель: сообщение влияет на результат ровно один раз даже при сбоях. В Kafka это возможно, но требует правильной связки механизмов.

• Как Kafka помогает:

  • идемпотентный продюсер снижает риск дублей при ретраях на стороне продюсера;

  • транзакции позволяют атомарно:

    • записать результат (часто в Kafka),

    • и зафиксировать прогресс чтения (offset).

• Где применяют:

  • потоковая обработка (stream processing), где результат пишется обратно в Kafka;

  • сценарии, где дубль «дорого стоит» (например, финансовые проводки), но там часто добавляют и бизнес-защиту.

Важно понимать ограничение: «exactly once» легче обеспечить, когда и вход, и выход — Kafka (например, Kafka Streams). Если выход — внешняя БД, то «ровно один раз» чаще превращается в «практически ровно один раз» за счёт идемпотентных операций и уникальных ключей.

2. Что именно гарантирует Kafka, а что — ваша логика

Kafka даёт инфраструктурные гарантии, но конечная гарантия — это система целиком.

2.1. Порядок сообщений

• Kafka гарантирует порядок внутри одной партиции.

• Между партициями глобального порядка нет.

• Вывод:

  • если вам нужен строгий порядок для конкретного order_id, кладите сообщения с одинаковым ключом в одну партицию.

2.2. Доставка и «потеря сообщений»

Потеря обычно появляется из-за:

• acks и подтверждений у продюсера;

• недостаточной репликации/настроек надёжности на брокере;

• некорректного коммита offset у консьюмера.

То есть «Kafka потеряла сообщение» часто на деле означает: «мы признали сообщение обработанным раньше времени» или «мы отправляли без нужного подтверждения».

3. Практический подход в продакшене

В большинстве backend-сервисов реальная рабочая схема такая:

3.1. Выбираем at least once

Потому что:

• потеря сообщений обычно хуже, чем дубликаты;

• дубликаты можно контролировать бизнес-логикой.

3.2. Делаем обработку идемпотентной

Простейшая и очень практичная стратегия — использовать уникальный идентификатор события.

Пример идеи (упрощённо):

• у события есть event_id;

• мы записываем event_id в БД как «обработано» (уникальный ключ);

• если пришёл дубль — просто пропускаем.

Мини-пример:

def handle(event):
    # если event_id уже есть — значит дубль
    if is_processed(event["event_id"]):
        return
    do_business_action(event)
    mark_processed(event["event_id"])

3.3. Контролируем коммит offset

• Автокоммит удобен, но часто приводит к неожиданным эффектам.

• В критичных обработчиках обычно делают явный коммит после успешной обработки.

4. Краткий вывод

Kafka позволяет построить разные гарантии доставки, но «по умолчанию» вы получаете только базовые механизмы, а итог зависит от настроек и кода. В большинстве backend-систем оптимальный баланс — at least once + идемпотентная обработка. Режим exactly once стоит рассматривать, когда вы строите потоковую обработку и можете контролировать транзакционность (особенно если выход тоже в Kafka).