Гарантии доставки в 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: обычно для всех бизнесовых событий, которые мы не должны терять.
Продолжение ⬇️
Продолжаем серию постов про 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: обычно для всех бизнесовых событий, которые мы не должны терять.
Продолжение ⬇️