Каково влияние режимов подтверждения на асинхронную отправку в кафке?

Влияют ли режимы подтверждения («0», «1», «все»), когда мы отправляем сообщения с помощью асинхронного send() вызова?

Я попытался измерить задержку отправки вызова (то есть путем записи времени до и после вызова метода send()) и заметил, что как (асинхронная отправка, acks=1), так и (асинхронная отправка, acks=all) занимают одинаковое время.

Тем не менее, есть явная разница в показателях пропускной способности.

producer.send(record, new ProducerCallback(record));

Я думал, что вызов отправки будет заблокирован, когда мы используем acks=all даже в асинхронном режиме. Может ли кто-нибудь объяснить, как режимы подтверждения («0», «1», «все») работают в асинхронном режиме?

Построение конвейеров данных в реальном времени с Apache Kafka: Руководство по Python
Построение конвейеров данных в реальном времени с Apache Kafka: Руководство по Python
Apache Kafka - популярная платформа распределенной потоковой передачи данных, которую можно использовать для построения конвейеров данных в реальном...
3
0
3 935
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Согласно документы:

public Future send(ProducerRecord record, Callback callback)

Asynchronously send a record to a topic and invoke the provided callback when the send has been acknowledged. The send is asynchronous and this method will return immediately once the record has been stored in the buffer of records waiting to be sent. This allows sending many records in parallel without blocking to wait for the response after each one.

Итак, одно можно сказать наверняка, что асинхронная «отправка» на самом деле не заботится о том, что такое конфигурация «acks». Все, что он делает, это помещает сообщение в буфер. Как только этот буфер начинает обрабатываться (управляется свойствами linger.ms и batch.size), проверяется «acks».

Если acks=0 -> Просто выстрели и забудь. Продюсер не будет ждать подтверждения.

Если acks=1-> Подтверждение отправляется брокером, когда сообщение успешно записано на лидере.

Если acks=all -> Подтверждение отправляется брокером, когда сообщение успешно записано на все реплики.

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

Кроме того, вы должны настроить свойство «повторные попытки» в вашем асинхронном источнике, чтобы в случае сбоя подтверждения (по какой-либо причине, например, повреждение/потеря пакета) производитель знал, сколько раз он должен повторить попытку отправить сообщение (увеличьте гарантия доставки).

Наконец: «Однако существует явная разница в показателях пропускной способности». -- Это верно из-за задержки подтверждения от брокера к потоку производителя.

Надеюсь, это поможет! :)

«это становится блокирующим вызовом, поскольку производитель будет ждать подтверждения» --- Где это происходит? Есть ли способ проверить или понаблюдать за этим?

Markiv 23.05.2019 10:24

Где это происходит? - Это параллельная нить. Кроме того, вот руководство по метрикам (PurgatorySize): datadoghq.com/blog/monitoring-kafka-performance-metrics

Manoj Vadehra 23.05.2019 10:41

Значит, эта блокировка верна и для acks=1? И не может быть и речи о блокировке запросов производителя на acks=0

Markiv 23.05.2019 15:56

Точно! и acks=1, и acks=all блокируются, так как требуют, чтобы сообщение было успешно записано хотя бы в одну реплику.

Manoj Vadehra 23.05.2019 15:58

Другие вопросы по теме