Разница между Kafka async и Kafka sync acks = 0?
Основываясь на моих чтениях, Kafka с acks = 0 в основном просто помещает сообщение в буфер производителя. Никаких подтверждений не ждет. При этом мне интересно, чем он отличается от производителя async? Как подтверждения влияют на производителя async?
1 ответ
В Kafka существует три типа производителей, которые в основном сгруппированы в Async и Sync.
- Подтверждения производителя синхронизации = 0 (активировать и забыть)
- Подтверждения производителя синхронизации = 1 или подтверждения = все
- Асинхронный продюсер
Подтверждения производителя синхронизации = 0 (активировать и забыть)
В сценарии «Пожар и забыл» мы не ждем ответа и не предпринимаем никаких повторных попыток. Итак, нет никакой гарантии, что сообщение доставлено или нет. Итак, в этом случае есть
- Возможная потеря сообщений
- Высокая пропускная способность
- Нет повторов
Подтверждения производителя синхронизации = 1 или подтверждения = все
Синхронно продюсер с
acks = 1, Производитель будет ждать ответа от лидера раздела. Так что есть гарантия только от брокера лидера раздела. Но есть вероятность потери сообщения, если лидер-брокер сломался, и для этого нет синхронизируемых реплик. Пропускная способность ниже, чем у Async и Fire и Forget. И повторные попытки указаны в конфигурации повторных попыток производителя.
Синхронно продюсер с
acks = all, Производитель будет ждать ответа от лидера раздела и всех синхронизированных реплик. Таким образом, есть гарантия от брокера лидера раздела и брокера синхронизированной реплики. Мы можем убедиться, что конфигурация In sync with Min In sync Replica. Пропускная способность самая низкая, а повторные попытки соответствуют конфигурации повторных попыток производителя.
Асинхронный продюсер
Async Producer почти такой же, как и производитель Fire and Forget, но с некоторыми отличиями. У него есть функция обратного вызова, чтобы получить ответ от брокера. Но продюсер не ждет такой реакции, это происходит на заднем плане. Таким образом, разница в том, что есть трассировка, если брокер отправляет некоторые ошибки производителя и есть повторные попытки. Из-за повторных попыток Async порядок сообщений не гарантируется.
И есть конфигурация под названием
max.in.flight.requests.per.connection. Количество асинхронных сообщений ограничено этим числом, если нет ответа от предыдущих сообщений. Поэтому, если он заполнен, снова производитель Async будет заблокирован до тех пор, пока этот ответ не придет к производителю.
Для получения дополнительной информации см.