Недавно мы столкнулись с проблемой производительности в сети, которая чуть не привела к сбою в сети. Позже, всего лишь изменив одну строку кода, производительность улучшилась в десятки раз. Строка кода работает в десятки раз быстрее.Данные звучат преувеличенно, но это реальные данные.Неправильная онлайн-конфигурация действительно может привести к разнице в производительности на порядок.Вы поймете, когда я закончу говорить о нашей проблеме с производительностью.
Мы подключены к онлайн-платформе IOT Tencent Cloud. События загрузки любого устройства IoT передаются нам через ckafka Tencent Cloud. По мере увеличения количества устройств и данных о событиях у нас возникает проблема с производительностью при использовании ckafka Tencent Cloud. быть перегрузка данных в периоды пиковой нагрузки, что приведет к проблемам в бизнесе из-за задержек в обработке данных. Самое простое решение - расширить разделы и потребители. Собственно, мы так и сделали, когда полгода назад возникли проблемы с производительностью. Удвоение разделов увеличило производительность вдвое. Однако через полгода мы снова уперлись в узкое место.
После расследования мы обнаружили, что обработка одного сообщения Kafka занимает 6 мс. После разделения всей логики выполнения мы обнаружили, что задержка в 6 мс в основном приходится на отправку подтверждения в Tencent Cloud. Происходит RTT из нашего компьютерного зала в Tencent Cloud. быть около 6мс, поэтому почти все события тратятся на передачу сообщений по сети. Однако это ограничение ограничено физическим расстоянием и не может быть уменьшено. Позже мы случайно обнаружили, что мы использовали MANUAL_IMMEDIATE в AckMode Spring-Kafka в коде. В этом режиме потребитель Kafka будет вручную подтверждать каждое сообщение на сервер. Позже мы скорректировали эту конфигурацию на AckMode.MANUAL для обработки одного сообщения. продолжительность сокращена с первоначальных 6 мс до менее 0,2 мс, что является увеличением более чем в 30 раз.Теперь, даже если мы не будем расширять нашу избыточность производительности, ее будет достаточно, чтобы поддерживать ее в течение многих лет. Почему простое изменение конфигурации может привести к такому улучшению? Существуют ли другие типы конфигурации?
Фактически, Spring-kafka предоставляет не только два режима подтверждения, MANUAL и MANUAL_IMMEDIATE, но и следующие семь, каждый из которых имеет различные функции и подходящие сценарии.
- ЗАПИСЬ : Подтверждайте сразу после обработки каждой записи.
- BATCH : после каждого вызова метода poll() подтверждается только последняя возвращенная запись.
- ВРЕМЯ : каждый раз, когда проходит установленный интервал времени, подтверждайте последнюю запись, обработанную в течение этого периода.
- COUNT : После обработки заданного количества записей подтвердите последнюю обработанную запись.
- COUNT_TIME : объединяет TIME и COUNT, то есть при выполнении любого условия подтверждается последняя обработанная запись.
- ВРУЧНУЮ : пользователям необходимо вручную вызывать метод подтверждения.acknowledge() в пакетном режиме для подтверждения сообщений.
- MANUAL_IMMEDIATE : пользователям необходимо вручную вызвать acknowledgment.acknowledge() для подтверждения сообщения. Каждое сообщение будет подтверждено один раз.
Если классифицировать вышеуказанные 7 режимов, их можно разделить на 2: ручное подтверждение и автоматическое подтверждение, из которых MANUAL и MANUAL_IMMEDIATE являются ручными подтверждениями, а остальные — автоматическими подтверждениями. Основное различие между подтверждением вручную и автоматическим определением заключается в том, нужно ли вам явно вызывать Acknowledgment.acknowledge() в коде. Давайте рассмотрим это по одному.
Ручное подтверждение
РУКОВОДСТВО:
В этом режиме потребителю необходимо вручную вызвать метод Acknowledgment.acknowledge() для подтверждения сообщения после его обработки. Операция подтверждения будет выполняться пакетно , то есть операция подтверждения будет отложена до тех пор, пока не будет обработан пакет сообщений перед отправкой в Kafka. Преимущество этой модели в том, что она может повысить эффективность, поскольку сокращается количество взаимодействий с сервером Kafka. Но недостатком является то, что если половина пакета сообщений потребляется, потребитель внезапно аварийно завершает работу. .
MANUAL_IMMEDIATE:
В этом режиме потребителю необходимо вручную вызвать метод Acknowledgment.acknowledge() для подтверждения сообщения после его обработки. Однако, в отличие от режима MANUAL, после вызова метода подтверждения() информация о подтверждении будет отправлена в Kafka немедленно, вместо ожидания обработки пакета сообщений перед отправкой. Этот режим может увеличить количество взаимодействий с сервером Kafka и вызвать значительные узкие места в потреблении производительности при большой задержке в сети. Однако информация о подтверждении может быть отправлена в Kafka как можно скорее. Даже если потребитель аварийно отключен, это приведет только к многократному использованию одного сообщения.
Преимущество ручного подтверждения заключается в том, что потребитель может оценить, были ли данные успешно использованы в логике кода. Неподтвержденные данные не будут подтверждены. Это может гарантировать, что данные не будут потеряны. Ручной режим может гарантировать целостность данных. , что и требуется в распределенной системе данных. Сказано хотя бы один раз . Основное различие между этими двумя режимами — однократное подтверждение и пакетное подтверждение. Пакетный метод может значительно улучшить производительность. В прошлом месяце я подробно представил три метода повышения производительности служб с интенсивным вводом-выводом в своем блоге. Если вам интересно, вы можете прочитать это ... _
автоматическое подтверждение
RECORD, BATCH, TIME, COUNT и TIME_COUNT являются автоматическими подтверждениями, то есть вам не нужно явно вызывать их в коде. Пока потребитель извлекает сообщение, оно будет автоматически подтверждено, независимо от того, было ли Acknowledgment.acknowledge()потребление на самом деле успешно, поэтому автоматическое подтверждение. Этот режим может привести к потере данных, но следует отметить, что по сравнению с подтверждением вручную автоматическое подтверждение может привести к потере или дублированию данных, поэтому это не самое большее один семантический уровень. Хотя оба режима являются автоматическими подтверждениями, на самом деле эти пять режимов имеют свои различия.
ЗАПИСЬ И ПАРТИЯ
Во-первых, давайте посмотрим на RECORD и BATCH.Эти два режима на самом деле являются автоматическими версиями, соответствующими MANUAL и MANUAL_IMMEDIATE, упомянутым выше. ЗАПИСЬ подтверждается один раз, также могут возникнуть проблемы с производительностью, если задержка в сети велика. BATCH — это пакетное подтверждение. Этот пакет сообщений будет подтверждаться после каждого опроса(). Аналогичным образом, если потребитель выходит из строя, сообщение не будет успешно подтверждено, что приведет к повторному извлечению сообщения. Конечно, если потребителю не удастся обработать данные по другим причинам, но данные подтвердятся нормально, сообщение в этом случае будет потеряно.
ВРЕМЯ
Режим TIME - это подтверждение по времени. Например, если вы установите интервал подтверждения на 5 секунд, потребитель будет каждые 5 секунд подтверждать Kafka сообщения, полученные в течение 5 секунд. Здесь есть проблема. Если это высокочастотный поток данных и время установлен большой интервал. Это может привести к накоплению большого количества неподтвержденных сообщений, а затем к многократному извлечению этих сообщений после ненормального простоя. Режим COUNT, о котором мы поговорим дальше, может избежать этой ситуации.
СЧИТАТЬ
Время подтверждения в режиме COUNT запускается по количеству потребленных данных, например, оно подтверждается один раз на каждые 100 потребленных товаров, что прекрасно позволяет избежать накопления большого количества неподтвержденных данных. Однако, если это чрезвычайно низкочастотный поток данных, например, один фрагмент данных занимает всего несколько минут, а для накопления 100 фрагментов потребуется несколько часов, данные не будут подтверждены в течение длительного времени после потребления. и это может даже заставить Kafka подумать, что время приема данных истекло, что приведет к повторному использованию данных.
TIME_COUNT
Учитывая преимущества и недостатки TIME и COUNT, TIME_COUNT сочетает в себе характеристики обоих. Пока временной интервал или количество сообщений соответствует одному из них, это будет подтверждено. Оно имеет более сильную адаптируемость, поэтому, когда вы хотите выберите из TIME, COUT и TIME_COUNT. Если вы выберете один из них, я лично думаю, что вы можете слепо выбрать TIME_COUNT, если только вы не особенно четко представляете характеристики своих данных и не знаете, какой из них больше подходит.
Подведем итог
Кратко суммируя вышеперечисленные режимы, если вы не можете мириться с потерей данных, вы должны выбрать ручной режим. Если сетевая задержка относительно высока, вы можете выбрать РУЧНОЙ режим (пакетная обработка), но учтите, что даже ручной режим не может гарантировать данные. Без дублирования Если вы хотите быть полностью идемпотентным, вам придется полагаться на другие методы, такие как транзакции базы данных. Если вы можете принять частичную потерю данных (например, данных мониторинга), вы можете рассмотреть автоматический режим, но лично я не рекомендую режим ЗАПИСИ, поскольку этот режим вызовет серьезные проблемы с производительностью в случае высокой задержки в сети. Остальные режимы могут выбираться в соответствии с вашим собственным объемом данных и условиями сети.Использование разных режимов в разных ситуациях может привести к значительным различиям в производительности.