Пропускная способность производителя при варьировании acks = 0,1, -1

Я проводил несколько тестов производительности с кластером kafka для своего проекта. У меня вопрос относительно функции send call и свойства производителя «acks». Я видел ниже номера с приведенным ниже вызовом отправки вызова. Это простой вызов "выстрелил и забыл".

producer.send(record); // fire and forget call

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

acks             Replication factor=1              Replication factor=3
0                  1330k msgs/sec                    1260k msgs/sec
1                  1220k msgs/sec                    1200k msgs/sec
-1(all)            1220k msgs/sec                    325k msgs/sec

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

Мы будем очень благодарны за любое понимание того, как acks и отправка вызова производителя работают внутри Kakfa.

P.S. Я спросил об этом в списке рассылки пользователей kafka, но не получил ответа, поэтому спросил об этом в SO.


java apache-kafka kafka-producer-api
person xabhi    schedule 19.11.2018    source источник

Ответы (3)


arrow_upward
2
arrow_downward

Тот факт, что у вас нет обратного вызова в методе send, не означает, что он запускается и забывается на базовом уровне. Вы настроили производителя с 3 различными уровнями подтверждения, которые определяют статус «запустил и забыл» или нет. Если acks = 0, это означает, что производитель отправляет сообщение, но не ждет каких-либо подтверждений от брокера; это настоящий «выстрелил и забыл». Как видите, он обеспечивает более высокую пропускную способность. При acks = 1 производитель ожидает подтверждения. Это подтверждение отправляется брокером (к которому подключен производитель и на котором размещена реплика лидера). Конечно, это не «выстрелил и забыл». При acks = -1 производитель ожидает подтверждения. Это подтверждение отправляется брокером, как указано выше, но только после того, как сообщения реплицируются всем последователям реплик на других брокерах. Конечно, в этом случае пропускная способность уменьшается, если вы увеличиваете коэффициент репликации, потому что сообщение должно быть скопировано большим количеством брокеров (min.insync.replicas), прежде чем «ведущий» брокер вернет подтверждение подтверждения производителю. Обратите внимание, что с коэффициентом репликации = 1, ack = 1 и ack = -1 имеют одинаковую пропускную способность, потому что существует только одна реплика (лидер), поэтому нет необходимости копировать для последователей.

person ppatierno    schedule 19.11.2018
comment
Я тоже не понимаю. Метод send javadocs говорит: «Асинхронно отправить запись в тему ...», как он ожидает внутри для поддержки гарантии acks = all? - person freakman; 20.11.2018
comment
Производитель в качестве внутреннего буфера, потому что отправка сообщений работает в пакетном режиме. Пакет с дополнительными сообщениями отправляется по истечении определенного времени (linger.ms) или достижении определенного размера (batch.size). С точки зрения клиента всегда асинхронный, потому что сообщение попадает только в буфер производителя, который отправляет сообщение. - person ppatierno; 20.11.2018
comment
@ppatierno Я думаю, что ваш ответ неверен, потому что вопрос касается пропускной способности, а НЕ задержки, см. мой ответ - person Youssef; 18.07.2021

arrow_upward
0
arrow_downward

Это что-то о том, как кафка обрабатывает запрос на производство. Во-первых, KafkaProducer.send по умолчанию является асинхронным. KafkaProducer взял на себя тяжелую работу по пакетной обработке вашего запроса на продукцию и отправке ее брокеру. Брокер отправит ответ, который, в свою очередь, должен будет дождаться min.insync.replicas от удаленных последователей. Вот в чем причина.

person Terence Yi ZX    schedule 19.11.2018
comment
Если вызов send является асинхронным и немедленно возвращается, то как на него влияют подтверждения? А если производитель ждет ответа, то как это асинхронно? - person xabhi; 19.11.2018

arrow_upward
0
arrow_downward

Я думаю, что принятый ответ неверен, потому что вопрос касается пропускной способности, а НЕ задержки, и согласно объединенной книге Kafka: подробное руководство:

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

Таким образом, если асинхронный производитель с acks=1,all, то пропускная способность зависит от max.in.flight.requests.per.connection: максимального количества неподтвержденных запросов, которые клиент отправит в одном соединении перед блокировкой.

person Youssef    schedule 18.07.2021