#node.js #networking #apache-kafka #tcp #aiven
Вопрос:
У меня есть 2 услуги: производитель и потребитель.
Насколько я понимаю, message.ts это время, когда производитель создал сообщение (а не время, когда брокер кафки получил сообщение).
Вопросы
- Когда потребитель получает сообщение, как я могу узнать, сколько времени оно находилось внутри брокера кафки (без задержки в сети: от производителя до брокера кафки и от брокера кафки до потребителя)?
- Я сделал пинг от моей виртуальной машины-потребителя к брокеру кафки. результат пинга составил 0,7 мс (миллисекунда). Составляет ли сетевая задержка с каждой стороны до брокера кафки 0,3 мс? Я предполагаю, что транспорт кафки
TCPтаков, что для всего есть сообщение «ACK». И я предполагаю, что каждая сторона ничего не будет делать без «ACK», поэтому я прихожу к выводу, что задержка в сети для каждого размера такая же, как результат пинга: 0,7 мс (миллисекунда). Я прав?
Ответ №1:
Все немного сложнее, чем это. Многие переменные влияют на то, сколько времени требуется для обработки сообщения. Я предлагаю вам изучить Распределенную трассировку. Что-то вроде Zipkin работает как по волшебству и очень просто в настройке и использовании. Вот руководство по настройке трассировки Zipkin с помощью Spring Boot. Вы даже можете использовать его с Кафкой, подключитесь к перехватчику, вот тот, который я использую: храбрый-кафка-перехватчик.
Zipkin создает трассировку для каждого сообщения, включая всех производителей и потребителей, которые его обработали. Эти следы в конечном итоге выглядят примерно так:
Вы можете видеть, сколько времени потребовалось для обработки сообщения и сколько времени потребовалось, чтобы оно было израсходовано после создания, что именно то, что вы ищете.
Комментарии:
1. Я еще не распространил трассировку. это отличный инструмент, и я посмотрю на это. Но сейчас мне нужны ответы независимо от того, есть ли у меня распределенная трассировка.
Ответ №2:
Я проверил это вручную, создав и использовав одну и ту же виртуальную машину для кафки (которая находилась внутри моего кластера). Результат составил 1,3-1,5 мс.
Это означает, что время обработки в среднем составляло 0,1 мс.
- Я создавал новое сообщение каждые 1 секунду, чтобы избежать задержки при потреблении.
Это не лучшее решение, но его достаточно для моего исследования.