Гарантии доставки в Kafka

Продолжаем серию постов про Kafka.

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

В Кафке существуют три вида гарантий доставки:

🟣 at most once — cообщение может быть потеряно, но не будет дубликатов

🟣 at least once — cообщение не потеряется, но возможны дубликаты

🟣 exactly once — ровно один раз, ни потерь, ни дубликатов (работает только для определенных случаев)

Чтобы понять, как реализуются гарантии, давайте посмотрим на две стороны взаимодействия: продюсеров и консьюмеров.

✉️ At most once

Для такого режима у продюсера нужно настроить отправку без ожидания подтверждения (aks = 0). Но если брокер упадёт до того, как подтвердит запись, а продюсер не делает retry, то сообщение потеряется.

Со стороны консьюмера at most once получится, если коммитить оффсет после прочтения, но до обработки сообщения. В таком случае, если консьюмер закоммитит оффсет, а потом упадет до окончания обработки сообщения, то сообщение для этой консьюмер-группы будет потеряно. Так как Kafka пометит себе его как прочитанное, а мы его недообработали.

➕В чем вообще плюс этого режима? В скорости.
➖ Минус в возможной потере сообщений.

❓ Где используется at most once: там, где важна очень высокая пропускная способность и не страшно потерять сообщение-другое. Например, сбор каких-то метрик: кликов, данных о движении автомобиля и др.

💌 At least once

На уровне кластера Кафки необходимо обеспечить репликацию на несколько брокеров. Иначе, если у нас есть только один брокер с этой партицией, то в случае его отказа, мы можем потерять все данные.

У продюсера нужно настроить подтверждение получения сообщения брокером:
acks = 1 — лидер уведомит, что записал сообщение либо пришлет сообщение об ошибке. Возможна потеря сообщения, если лидер отвалится сразу после этого.
acks = all — лидер дождется уведомления от синхронизированных реплик, что они сохранили сообщение себе и только тогда уведомит продюсер, что все ок.

Но если ответ брокера не дошел, продюсер отправит сообщение заново, и появится дубликат.

Со стороны консьюмера для обеспечения at least once необходимо коммитить оффсет после обработки сообщения.

📌 Здесь есть опасный момент, который обсуждали прошлый раз: слишком долгая обработка может привести к тому, что консьюмер вообще отлетит из консьюмер-группы. Например, точно опасно ходить во время обработки в другой сервис по REST.

At least once у консьюмера может привести к повторной вычитке. Да и продюсер при этом подходе может задублировать сообщение. Поэтому консьюмеры должны уметь работь с дубликатами.

➕ В чем плюс этого режима? В надежности.
➖ Возможны дубликаты

❓ Где используетcя at least once: обычно для всех бизнесовых событий, которые мы не должны терять.

Продолжение ⬇️