Apache Kafka стал первым выбором многих программистов при создании высокопроизводительных и надежных систем обмена сообщениями. В этой статье представлен углубленный анализ внутреннего механизма Kafka, от макроархитектуры до деталей потока сообщений, показывающий, как Kafka достигает асинхронной обработки сообщений и управления трафиком с помощью тщательно разработанных системных компонентов и стратегий. В этой статье вы познакомитесь со стратегией подтверждения Kafka, технологией сохранения данных и ключевыми разработками для повышения производительности системы, включая пакетную обработку, сжатие, PageCache и технологии нулевого копирования. В то же время в статье также рассматриваются балансировка нагрузки и управление кластерами, что дает вам полное представление о том, как Kafka соответствует строгим требованиям к очередям сообщений в крупномасштабных распределенных системах.

01. Введение

изучить основные знания Kafka раньше,Давайте сначала подумаем над вопросом：Какой сценарий побудит нас использовать Kafka? Скажи приезжать сюда,в наших умахилимногоили Меньше шансов выскочитьАсинхронная развязкаисглаживание пиков и заполнение впадини другие слова,даиз,Это Kafka Самая важная сцена приземления.

• Асинхронная развязка：Преобразование синхронных вызовов в асинхронные уведомления о сообщениях,Реализуйте разделение производителя и потребителя. представьте себе сцену,существуют При торговле товарами,существовать После создания заказа,Необходимо запустить ряд других операций,Например, ведение статистики заказов пользователей, отправка текстовых сообщений пользователям, отправка электронных писем пользователям и т. д. если все операции выполняются синхронно,Серьезно повлияет на производительность системы. Для этого сценария,Мы можем использовать промежуточное программное обеспечение для сообщений, чтобы отделить операцию создания заказа от других последующих строк.
• сглаживание пиков и заполнение впадин：использовать broker Буферизируйте мгновенный пакетный трафик вышестоящих производителей, чтобы сгладить общее потребление потребительского трафика. Для вышестоящих систем с мощными возможностями отправки и без защиты промежуточного программного обеспечения сообщений нижестоящая система может быть напрямую перегружена, что приведет к лавине полноканальных сервисов. Представьте себе бизнес-сценарий мгновенной продажи. Вышестоящий бизнес инициирует запрос заказа, а нижестоящий бизнес выполняет мгновенную продажу (проверка запасов, замораживание запасов, замораживание баланса, формирование заказа и т. д.). Логика обработки нижестоящего бизнеса довольно сложна. и пропускная способность параллелизма ограничена. Если служба не ограничивает текущий поток, нисходящие службы могут быть перегружены в одно мгновение. Для этого сценария мы можем использовать MQ Приди и сделай этосглаживание пиков и заполнение впадин,Пусть пиковый трафик заполнит простаивающие ресурсы в низких долинах,Разумно используйте системные ресурсы.

Приведенный выше пример можно найти в транзакции、Часто требуется в таких сценариях, как оплатаАсинхронная развязкаисглаживание пиков и заполнение впадинОсобенности решения проблем,Такие сценарии, как транзакции и платежи, предъявляют особенно высокие требования к производительности и надежности. Так,Наша статьяизглавный герой Kafka Может ли он соответствовать соответствующим требованиям? Давайте обсудим это ниже.

02. Макропознание Кафки

исследование Kafka Прежде чем добиться высокой производительности и высокой надежности, давайте посмотрим на это с макроэкономической точки зрения. Kafka системная архитектура.

Как показано на рисунке выше, Kafka состоит из Producer, Broker, Consumer и ZooKeeper, который отвечает за управление кластером. Функции каждой части следующие:

• Producer：продюсер,Отвечает за создание и маршрутизацию сообщений и маршрутизацию сообщений Брокеру;
• Broker：Экземпляр службы,Отвечает за сохранение, передачу и другие функции сообщений;
• Consumer：потребитель,Ответственныйот Broker Получить подписку из новости и потреблять,Обычно много потребителей образуют группу,Сообщения могут быть использованы только одним потребителем в одной группе;
• ZooKeeper：Ответственный broker、consumer Управление элементами кластера и т.д.;

В показанном выше процессе потока сообщений есть несколько особенно важных понятий: тема, раздел, сегмент и смещение.

• topic：Тема сообщения。Kafka в соответствии с topic Для классификации сообщений нам нужно лишь указать время отправки и получения сообщений. topic。
• partition：Раздел。дляподъемная системаиз Колебание,один topic Обычно их несколько partition,partition распределенныйсуществоватьдругойиз Broker включено, для хранения topic из новостей, что делает Kafka существующего может обрабатывать и хранить сообщения на нескольких машинах, давая kafka Он обеспечивает возможности параллельной обработки сообщений и возможности горизонтального расширения. Кроме того, для повышения надежности системы разделите Обычно делятся на группы, и каждая группа имеет основную partition、многоиндивидуальныйкопировать раздел, и распределение существует по-другому из broker начальство,отростприезжатьАварийное восстановлениеизэффект。
• segment：сегментация。Макросначальствосмотреть,один partition Соответствует журналу (Log). потому что чтопродюсер Производствоиз новостейвстреча Нет断追加приезжать log конец файла,для предотвращает слишком большой размер файлов журналов, что приводит к неэффективному извлечению данных,Kafka Механизм сегментации и индексирования используется для объединения каждого partition разделен на формного сегменте, это также облегчает обслуживание и очистку сообщений.Каждыйиндивидуальный segment содержит .log Файлы журналов, два индексных файла (.index, timeindex) и, возможно, другие файлы. каждый Segment изданные файлы с наименьшим размером в этом разделе offset для имени файла, при поиске offset из Message время, используйте бинарный поиск, чтобы быстро найти место проживания Message Расположен в Segment середина.
• offset：информациясуществовать В журналеиз Расположение,информациясуществоватьбыть добавленприезжать Разделфайл журналаизвсе времявстречараспространятьодинидентификацияизкомпенсировать。offset Это уникальный идентификатор из в разделе сообщения, который представляет собой монотонно возрастающее и неизменное значение из. Кафка используйте его, чтобы обеспечить порядок существования сообщений внутри раздела, однако offset и Не пересекай Раздел,То есть,Kafka Убедитесь, что из упорядочено по разделам, а не по темам.

После краткого понимания общей структуры системы Kafka и связанных с ней концепций давайте продолжим изучение принципов реализации высокой надежности и высокой производительности.

Tips：Самодельный Kafka Кластеры могут столкнуться с рядом проблем, включая построение кластера, настройку узлов, управление разделами и копиями, безопасность и мониторинг и т. д. Выберите очередь сообщений Tencent Cloud CKafka Версия (TDMQ for CKafka）,100% Совместимость с открытым исходным кодом Kafka API 2.4、2.8、3.2 Версия, обладая при этом преимуществами высокой доступности, сжатия данных и поддержки обработки данных как в автономном режиме, так и в реальном времени, устраняя различные проблемы, такие как самостоятельное управление.

Для получения подробной информации посетите адрес：https://cloud.tencent.com/product/ckafka

03. Исследование высокой надежности Kafka

Основой высокой надежности Kafka является гарантия того, что сообщения не будут потеряны во время доставки, что включает в себя следующие основные ссылки:

• Сообщения от производителей надежно отправляются на Broker；-- Сетевые и локальные потерянные данные.
• отправить в Broker из Надежное сохранение сообщений;-- PageCache Кэш-диск、единственная точка коллапса、Мастер от синхронизации по сети.
• Потребитель от Broker Потребляйте сообщение, и лучше всего использовать его только один раз. -- Передача сообщений по сетям.

3.1 Сообщения надежно отправляются от производителя брокеру

Чтобы гарантировать надежную отправку сообщений от производителя брокеру, нам необходимо обеспечить две вещи:

1. Producer После отправки сообщения вы можете отправить сообщение с Broker из Сообщение сохранитьуспех ack；
2. После того как производитель отправляет сообщение, он может перехватывать ненормальные подтверждения, такие как таймауты и неудачные подтверждения, и обрабатывать их;

3.1.1 стратегия подтверждения

Для вопроса 1 Кафка предлагает нам три стратегии подтверждения:

• Request.required.acks = 0: запрос считается успешным при его отправке, и не имеет значения, успешна запись или нет. Он часто используется в сценариях анализа журналов.
• Request.required.acks = 1: когда раздел-лидер после записи успешен,успех просто напиши,Потерянныйданныеизвозможный。
• Request.required.acks= -1: после того, как все копии записаны в список ISR.,Вот этотинформацияуспех просто напиши,Высокая надежность гарантирована.

Для достижения прочного и надежного kafka систему, нам нужно установить Request.required.acks= -1, а также устанавливает реплики в кластере, находящиеся в состоянии нормальной синхронизации. follower количество min.insync.replicas>2,кроме того,настраивать unclean.leader.election.enable=false Создать кластер ISR из follower Только тогда мы сможем стать новым человеком лидер, чтобы избежать усечения сообщения в особых обстоятельствах.

3.1.2 Стратегия отправки сообщений

Что касается вопроса 2, kafka предоставляет два типа методов отправки сообщений: синхронную (синхронную) отправку и асинхронную (асинхронную) отправку. Соответствующие параметры плагина kafka в платформе trpc-go следующие:

(Рекомендуется нажать на изображение, чтобы увеличить его)

trpc-kafka Нижний уровень основан на открытом исходном коде. sarama Реализация, существование Сообщение отправляется из процесса, независимо от того, отправлено ли оно Отправить синхронновозвращатьсяда Отправить асинхронно будет задействовано две сопрограммы - ответственная за отправку сообщений из основной сопрограммы и ответственная за распространение сообщений из dispatcher Корутины.

Отправить асинхронно

для Отправить асинхронно(ack != 0 Сцена, когда равна 0, писать не важно kafka В результате (подробно объяснено позже) процесс выглядит примерно следующим образом:

1. существовать Вызывается в основной сопрограмме Отправить асинхронно kafka Суть отправки сообщения заключается в помещении тела сообщения в input из канал, просто введите channel В случае успеха эта функция возвращает результат напрямую, без каких-либо блокировок. Напротив, если вы введете channel В случае неудачи будет возвращено сообщение об ошибке. Так позвони async появляетсяиз сообщение об ошибке при записи из channel из Сообщение об ошибке, что касается конкретного финального сообщения, есть ли сообщение Отправить в kafka из брокер, мы не можем знать стоимость отвозвращаться.
2. когда приходит сообщение input из channel Позже будет еще один dispatcher изкорутина отвечает за перемещение ввод, чтобы на самом деле отправить сообщение приезжать конкретно Broker начальствоизхозяин Partition начальство. Отправьте результат в асинхронную сопрограмму для мониторинга и обработки цикла. err channel и success канал, появился error Просто ведите журнал. Поэтому при асинхронной записи сцены напишите kafka Из информации об ошибках на данный момент мы можем использовать этот журнал ошибок только для того, чтобы узнать, какая конкретная ошибка произошла, и наши собственные функции не поддерживаются для скрытой обработки. Это существует. trpc-go из Чиновник также был признан приезжающим.

Отправить синхронно

Отправить синхронно(ack != 0 сцена)дасуществовать Отправить асинхронноиз реализуется на основе условных ограничений. Отправлять синхронные сообщения существуют newSyncProducerFromAsyncProducer Откройте две асинхронные сопрограммы для обработки сообщений об успехе с ошибкой из-за «обратного вызова» и используйте их. waitGroup Подождите, пока асинхронная операция будет преобразована в синхронную. Процесс примерно следующий (см. [sarama Kafka Сортировка клиентов-производителей и потребителей]

Благодаря приведенному выше анализу можно обнаружить, что Кафка Отправка сообщений по сути асинхронна, но Отправить синхроннопроходить waitGroup Преобразование асинхронных операций вдля Синхронная работа。Отправить в определенной степени гарантирует, что мы существуем в сети К Broker При передаче сообщения сообщение должно быть надежно передано Broker。потому чтодлясуществовать Отправить синхронно, мы можем четко определить, отправлено ли сообщение Broker,Если сообщение не удалось отправить из-за дрожания сети, простоя компьютера и т. д., результат неизвестен.,Можетпроходить Повторите попытку и другие средства для обеспеченияинформацияк На одного меньше Второсортный（at least once） отправить в Маклер. Кроме того, Kafka (после версии 0.11.0.0) также Producer Два типамеханизм来实现精确一Второсортный（exactly once） Отправка сообщения: идемпотентность и транзакция.

(Рекомендуется нажать на изображение, чтобы увеличить его)

3.1.3 Резюме

проходить ack Стратегия Конфигурация、Отправить синхронно, возможности комбинирования сообщений о транзакциях, мы можем достичь ровно один раз семантикаПо сетям К Broker Передавать сообщения. Однако продюсер получать Broker изуспех ак, а сообщение не потеряется? Чтобы понять эту проблему, мы должны сначала понять Broker Что же делали существа после получения сообщения от получать.

3.2 отправить в Broker из новостей Может Зависит от Выносливость

Чтобы обеспечить Producer получать Broker изуспех ack Наконец, сообщения не должно быть там Broker Если ссылка потеряна, следует сосредоточиться на следующих моментах:

• Когда Брокер возвращает успешное подтверждение от Производителя, было ли сообщение размещено;
• Broker Приведет ли простой к потере данных,Аварийное Каков механизм восстановления;
• Replica Как решить проблему согласованности синхронизации между данными, вызванную механизмом копирования;

3.2.1 Брокерный асинхронный дисковый щеточный механизм

kafka Чтобы получить более высокую пропускную способность, брокер После получения сообщения просто напишите данные PageCache Тогда считается, что сообщение написано успешно,и PageCache серединаизданныепроходить linux из flusher Программа выполняет асинхронную чистку диска (триггерная панель очистки диска: активный вызов sync или fsync Функция: доступная память ниже порога, загрязнена data время достигает порога), данные записываются на диск последовательно. Схема обработки сообщений выглядит следующим образом:

Поскольку сообщение написано PageCache , автономный сценарий, если вы еще не обновили диск Broker Тогда все кончено Producer Часть данных, которые производятся, может быть потеряна. для Для решения проблем, которые может вызвать одиночный сбой машины, изпотеря данныхвопрос,Kafka Введен механизм реплик для разделов.

3.2.2 Механизм копирования реплик

Kafka Каждая группа разделов обычно имеет много копий, и одна и та же группа разделов из разных дистрибутивов копирования существует в разных вариантах. Broker вкл. сохраняется одно и то же сообщение (может быть с задержкой). Отношения между копировать - это «один хозяин многоот», при котором leader Реплика отвечает за обработку запросов на чтение и запись, ведомый Копия отвечает за начало с leader Извлекайте сообщения для синхронизации. Раздел из всех копировать коллективно для AR（Assigned Реплики), все из которых связаны с leader копировать сохранять определенную синхронизацию изкопировать (в том числе leader копия включена) для формирования ISR (In-Sync Реплики), с leader Синхронная задержка состоит из многоизкопировать OSR（Out-of-Sync Реплики), видно, что AR=ISR+OSR. последователь Синхронизировано ли копирование с лидером критериев оценки, зависит от Broker параметры терминала реплика.лаг.время.макс.мс (по умолчанию 10 секунд), ведомый По умолчанию каждые 500ms К leader fetch Данные одновременно, только один Follower Копировать сзади Leader копирование длится не более 10 секунд, затем Kafka Просто подумай, что Follower копировать с помощью leader Это синхронизировано. существуют в норме все из follower Копии должны совпадать с leader копировать поддерживать определенную степень синхронизации, т.е. AR=ISR,OSR Коллекция пуста.

когда leader скопировать местоположение Broker Во время простоя Кафка буду использовать ZK от follower копировать выборы новыйиз leader Продолжайте предоставлять услуги внешнему миру, реализуйте автоматическую передачу неисправностей и гарантируйте доступность услуг. для сделал выборы из новых leader японский и старый leader данныевыхлопвозможныйпоследовательный,когда leader При сбое реплики по умолчанию только ISR Только те, кто находится в коллекции, имеют право быть избранными в качестве кандидата. лидер, находясь в OSR Набор изкопировать не имеет никаких шансов (можно изменить, введя настройку unclean.leader.election.enable).

когда Kafka Когда механизм применениямногокопирования решает проблему сбоя одной машины, он также вызывает проблему согласованности синхронизации между многокопированием. Кафка использовать механизм возобновления высокого уровня воды, копировать механизм синхронизации, Leader Epoch Для решения проблемы согласованности синхронизации данных между несколькими копиями были приняты различные меры. Давайте по очереди рассмотрим эти основные меры.

HW и ЛЕО

Во-первых, давайте рассмотрим две важные концепции, связанные с журналами в Kafka HW и LEO:

• HW: High Водяной знак, высокий уровень воды, указывает на то, что было отправлено максимальное смещение журнала (фиксация), Kafka Определенный логин в «Отправлено» означает ISR Все узлы включают этот журнал, и потребители могут использовать только HW Доизданные；
• LEO: Log End Смещение означает, когда фронт log Следующее сообщение, которое будет записано в файл из offset；

Как показано на картинке выше,он представляет собой файл журнала,В этом файле журнала 8 сообщений.,0к5междуиз новостейдля Поданныйинформация,5к7из новостейдля Не отправленоинформация。файл журналаиз HW для5, что указывает на то, что потребители могут получать сообщения только до прибытия5, и offset для5из сообщения невидимы для потребителей. Файл журнала из LEO равно 8, следующее сообщение будет написано здесь.

ПРИМЕЧАНИЕ: Все копировать имеют соответствующее HW и Лео, просто Leader Копия особенная, Кафка использовать Leader копировать уровень паводка для определения всех существовавших зональностей по уровню паводка. Другими словами, высокий уровень воды в зоне является ее Leader копироватьизвысокий уровень воды。Leader копироватьи Follower копироватьиз HW Он имеет следующие характеристики:

• Leader HW：min（всекопировать ЛЕО), для чего Leader копировать не только спасти себя из HW и ЛЕО, тоже надо сохранить follower копироватьиз HW и ЛЕО,и follower копировать Просто спасайся из HW и ЛЕО；
• Follower HW：min(follower сам LEO,leader HW)。

Примечание. Для удобства описания ниже ведущий HW обозначается сокращенно HW L, ведомый HW сокращенно HW F, ведущий LEO сокращенно LEO L, а ведомый LEO сокращенно LEO F.

Ниже мы демонстрируем Второсортный полный процесс обновления HW/LEO:

1. исходное состояние ГВ L =0, ЛЕО L =0, ГВ F=0, ЛЕО F=0.

1. Follower Первый Второсортный fetch

• Leader получать Producer Отправьте сообщение для завершения хранения, возобновлять LEO L =1;
• FollowerотLeader fetchданные, Лидер получает запрос, записывает подписчиковизLEO F =0,ипытатьсявозобновлять HW L =мин(все копии LEO)=0；
• leade возвращаться HW L=0и LEO L=1 дать Follower,Follower Сохранять сообщения и возобновлятьLEOF =1, HW=min(LEO F ,HW L )=0。

1. Follower второй Второсортныйfetch:

• Follower Снова Второсортныйот Leader fetch данные, Leader получить запрос, записать follower из LEO F =1,ипытатьсявозобновлять HW L =мин(все копии LEO)=1；
• leade возвращаться HW L =1и LEO L =1Дать Follower,Leader получатьпросить,возобновлятьсебя из HW=min(LEO F ,HW L )=1。

Во время вышеуказанного процесса обновления Follower и Leader из HW Время обновления ЗАЗОР. если Leader Если в течение этого периода узел выйдет из строя, то Follower из HW и Leader из HW может находиться в противоречивом состоянии, если Followe выбран какновыйиз Leader сам из HW Если для предоставляет услуги внешним сторонам, это может привести к потерям. данныхили Путаница данныхвопрос。

KIP-101 Вопрос: потеря данных&Путаница данных

потеря данных

Шаг 1:

1. копировать B как leader получать producer из m2 Сообщение и запись в локальный файл, подождите копировать A Тянуть.
2. копировать A Инициируйте запрос на извлечение сообщения, и запрос содержит свое собственное последнее смещение журнала (LEO = 1), B получатьназадвозобновлятьсебя из HW равен 1, и будет HW=1из Информация и новости m2 возвращаться Давать A。
3. A получить результаты извлечения после возобновления локального из HW равен 1, и будет m2 Запись в локальный файл. Инициировать новый раунд запросов на включение (LEO=2), Bполучить запрос на включение после возобновления себя из HW для2, только новые данные не будут HW=2 изинформациявозвращаться Давать А, и отвечаю на producer Напишите успех Здесь из государства – это первый шаг из состояния на картинке.

Шаг 2:

В настоящее время, если не будет исключения, А. встречаполучать B из Ответить и узнать о текущей ситуации из HW для2,Ранназадвозобновлятьсамиз HW это 2. Но на шаге 2 A Перезапустил, не поздно получить B из ответа, в это время B все еще leader。A После перезапуска будет HW для стандарта обрезается журнал, потому что для A как follower Я не знаю, было ли отправлено много из журнала, чтобы предотвратить несогласованность данных и усечение многих оставшихся из данных, и попробуйте отослать их. leader Пересинхронизируйтесь там.

Шаг 3:

B Разбился, мин.isr Настройка из равна 1, поэтому zookeeper встречаот ISR Выбрать другой как лидер, то есть А, но A изданные - это не полное из, но потеря данных Феномен。вопроссуществоватьгде？существовать В A После перезапуска с HW Стандарт for усекает большое количество журналов. Можно ли не обрезать? Нет, потому что журнал для мог не быть отправлен (т. е. не был отправлен). ISR Все узлы в файле записаны), и сохранение приведет к путанице в журнале.

Путаница данных

Прежде чем анализировать проблему путаницы в журналах, нам необходимо понять, куда приезжать. kafka ископировать Гарантия надежности имеет предпосылку:существовать ISR В . есть хотя бы один узел. В случае выхода из строя всех узлов надежность не гарантируется. Такая ситуация произойдет. данных,потеря данные приемлемы. Здесь мы анализируем проблему из-за потери данные еще хуже,Это приведет к путанице в журналах или даже к ненормальной работе всей системы.,А это недопустимо из.

Шаг 1:

1. A и B Все ISR серединаизузел。копировать A как leader,получать producer из новостей м2из запрос напиши после PageCache И какое-то время существовать, обновлять приезжающий локальный диск.
2. копировать B тянутьприезжать m2 напиши после PageCage Позже (диск еще не обновился) перейдите во Второсортный. A Получайте новые сообщения и уведомляйте A себя из LEO=2,Aполучатьвозобновлятьсебя из HW как 1 и ответить на producer успех.
3. в это время A и B Время простоя при этом, Б из m2 потому что еще не обновил диск, так что m2 Сообщение потеряно. в это Времяиз государства – это первый шаг из государства.

Шаг 2:

потому что A и B все вниз,и min.isr=1 и unclean.leader.election.enable=true（закрытие unclean стратегия выбора), поэтому Kafka буду ждать первого ISR Средний узел восстанавливается и восстанавливается как Лидер, к сожалению вот B выбран как лидер, а также принять получать producer Отправить новое сообщение от из м3. Обратите внимание, что это отсутствует m2 Сообщение приемлемое, ведь все узлы не работают.

Шаг 3:

A После восстановления и перезапуска я обнаружил, что я последователь, и HW для2, и нет много изданных, которые нужно обрезать, так что начнем B Выполните новый раунд синхронизации. Но это время A и B Никто из них не осознавал, что компенсация для1из новостейнепоследовательный。

Вопрос Где? существуют Запись журнала асинхронна, как упоминалось выше. Kafka изкопировать Стратегия. Один из вариантов заключается в том, что обмен сообщениями из-за постоянства является асинхронным, что приведет к тому, что будет выбран сценарий 2. leader Он не обязательно содержит все файлы, что может привести к путанице и проблемам в журнале.

Leader Epoch

Чтобы устранить вышеуказанные недостатки, Кафка представил Leader Epoch из концепции. лидер epoch и raft Понятие термина «число» очень похоже. При каждом переизбрании лидера используется строго монотонно возрастающее число. id Поставляется с логотипом, который позволяет всем follower понимать leader обмен. и follower больше никогда HW Как правило, нужно после каждого краша заходить и перезагружаться. leader Загляни туда раньше, когда leader из журнала, от которого offset Начало из. Посмотрите ниже Leader Epoch Как решить две вышеуказанные проблемы из.

потеря данныхрешать

здесьиз Ключевые моментысуществовать Вкопировать A После перезапуска как последователь, не занятой HW для Квази-усечениесебя избревно,ида Начать сначала LeaderEpochRequest Попросите копию B Последнее поколение 0 из смещения намного меньше, копировать B встречавозвращатьсясебя из LEO Дайте копию на 2 A,A теперь буду знать новости m2 нельзя сократить, поэтому m2 Получил возможность приезжать зарезервировано. когда A выбран как leader На тот момент все представленные журналы были сохранены, и проблему потери журналов пришлось решать путем выезда. если инициировано LeaderEpochRequest Что мне делать, если он уже мертв? В этом случае потери журнала не будет, поскольку копировать A выбран как leader назад Нетвстреча Усечьсебя избревно,Усечение журнала будет происходить только для тела последователя.

Путаница данныхрешать

Ключевым моментом здесь по-прежнему является шаг 3, копировать A Перезагрузить как follower из Первый шаг еще предстоит сделать LeaderEpochRequest просить leader когда назад 0-е поколение последнего смещения было намного меньше, потому что чтокопировать B Он был заменен, поэтому он даст A начальное смещение первого поколения (то есть 1). После того, как A обнаружит конфликт, он урежет свое собственное смещение для журнала 1iz и начнет заново. leader синхронный. копировать A икопировать B Журналы согласованы, и путаница в журналах устранена.

3.2.3 Резюме

Broker После получения сообщения просто напишите данные PageCache Впоследствии признается, что сообщение для успеха было написано, однако механизм проведения копировать сочетается с ACK Стратегия позволяет избежать последствий простоя одной машины с высокой вероятностью изпотеря. данныхвопрос,ипроходить HW, механизм синхронизации реплик, Leader Epoch и другие меры по решению проблемы согласованности синхронизации данных между несколькими копиями и, наконец, реализованы Broker данныеиз Надежное сохранение.

3.3 Потребитель от Broker Потребляйте сообщение, и лучше всего использовать его только один раз.

Consumer существуют Необходим в процессе потребления сообщений из Kafka отчетсебя из Смещениеданные,толькокогда Consumer К Kafka Только после того, как будет сообщено о смещении сообщения, оно будет Broker Считается, что он был израсходован. Следовательно, Потребитель Терминальное сообщение «Надежность — главное» и offset Связанный с методом подачи, Кафка Потребитель предоставляет два метода отправки сообщения:

(Рекомендуется нажать на изображение, чтобы увеличить его)

Поскольку для имеет возможность повторного потребления, в нормальных обстоятельствах нам обычно требуется идемпотентный контроль для повторного потребления.

04. Исследование высокой производительности Kafka

Kafka высокая Основой производительности является обеспечение того, чтобы система обрабатывала сообщения с низкой задержкой и высокой пропускной способностью, для этого Kafka Принятие многих изысканных дизайнов:

• Отправить асинхронно。
• Отправляйте оптом.
• сжатиетехнология.
• PageCache механизм&Добавляйте заказы последовательно。
• нолькопия.
• Разреженный индекс.
• broker & раздел данных。
• много reactor многопоточная сетевая модель.

4.1 Отправить асинхронно

Как уже говорилось выше, Кафка Предусмотрены два метода отправки сообщений: асинхронный и синхронный. существовать Отредактировать В асинхронном режиме весь процесс асинхронен. Позвонить Отправить асинхронно, сообщение будет записано канал, а затем немедленно возвращает успех. Диспетчер Программная встреча channel опросинформация,поставь этоотправить в Брокер, за обработку будет отвечать еще одна асинхронная сопрограмма Broker возвращатьсяизрезультат。Отправить По сути, это слишком асинхронно, но когда существование синхронно обрабатывает результат, Отправить синхроннопроходить waitGroup Преобразуйте асинхронные операции в синхронные. использовать Отредактировать асинхронно может максимизировать пропускную способность отправки сообщений.

4.2 Пакетная отправка

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

1. batch.size：контроль Отправить оптом Размер сообщения, значение по умолчанию — 16 КБ, может быть увеличено соответствующим образом. batch.size Повышение значения параметра Колебание.но,Следует отметить, что из,если Отправить оптомиз установлен слишком большой размер,Может привести к увеличению задержки отправки сообщений.,Поэтому его необходимо корректировать в соответствии с реальной ситуацией.
2. linger.ms：контрольинформациясуществовать Отправить оптомиз времени ожидания, значение по умолчанию — 0. когда linger.ms Если значение больше 0, то при отправке сообщения Kafka Будет ждать указанное время, время ожидания достигнет приезда или размер партии достигнет приезда patch.size, сообщение будет упаковано во Второсортный пакет для отправки. Адаптируется при увеличении linger.ms Значение параметра повышает пропускную способность, например с 10 до 100.

существовать Kafka В клиенте-производителе, когда отправляется сообщение, если включено Отправить оптом,Kafka встреча Воляинформациякэшприезжатьбуферсередина.когдабуферсерединаиз новостей Большой и маленькийприезжать batch.size или Время ожидания до linger.ms Когда, Кафка встреча Волябуферсерединаиз новостейупакованный водинпартия Второсортный Отправлять。еслисуществовать Время ожидания не наступилоприезжать batch.size,Kafka такжевстреча Волябуферсерединаиз новости Отправить,от и избежать задержки сообщений.

4.3 Технология сжатия

Kafka поддерживатьтехнология сжатие, сжимает сообщение перед его передачей, тем самым уменьшая накладные расходы на передачу по сети (процесс сжатия и распаковки будет потреблять определенную сумму денег) CPU ресурс,Поэтому его необходимо корректировать в соответствии с реальной ситуацией. ),Повышение эффективности и пропускной способности сети.

Kafka Поддержка многоалгоритмов сжатия, передача параметров конфигурации. Compression.type (значение по умолчанию: none, что указывает на отсутствие сжатия). существовать Kafka До версии 2.1.0 поддерживалось только GZIP,Snappy и LZ4, все еще поддерживается после версии 2.1.0. Zstandard Алгоритмы (Фейсбук Открытый исходный код, способный обеспечить сверхвысокую степень сжатия). Сравнение производительности этих алгоритмов сжатия (чем выше, тем лучше по обоим показателям) следующее:

• Колебаниеколичество：LZ4>Snappy>zstd и GZIP
• сжатие Сравнивать：zstd>LZ4>GZIP>Snappy。

существовать Kafka из клиента-производителя, при отправке сообщения, если включена технология сжатия,Kafka Перед отправкой сообщение будет сжато. существовать потребительский клиент, если сообщения сжаты, Kafka Будет распаковывать сообщение при его потреблении. Примечание: Брокер Если установлен алгоритм сжатия, несовместимый с производителем. После получения сообщения оно будет распаковано, повторно сжато и сохранено. Маклер если существует совместимость версии сообщения, также будет запущена распаковка, а затем сжатие.

4.4 PageCache механизм&Добавляйте заказы последовательно

kafka Чтобы улучшить пропускную способность системы и уменьшить задержку, Broker После получения сообщения просто напишите данные PageCache Тогда считается, что сообщение написано успешно, и PageCache серединаизданныепроходить linux из flusher Программа выполняет асинхронную прошивку диска (избегая огромных накладных расходов системы, связанных с синхронной прошивкой диска).,Воляданныепоследовательное добавление записиприезжатьдискфайл журналасередина.потому что PageCache Он кэшируется в памяти, поэтому скорость чтения и записи очень высокая, что может значительно повысить эффективность чтения и записи. одновременное добавление записи Получите максимум от заказа I/O Операции записи избегают медленных и случайных I/O операция, которая может эффективно улучшить Kafka Колебание.

Как показано на картинке выше,Сообщения последовательно добавляются в конец файла журнала каждого раздела.

4.5 Нулевая копия

Kafka серединажитьсуществовать Многоизсетьданные Выносливостьприезжатьдиск（Producer приезжать Брокер) и дисковый файл осуществляют сетевую отправку (Брокер приезжать Потребитель) из процесса, этот процесс производительности напрямую влияет Kafka из Общая пропускная способность. Традиция IO Операция экономит копирование и переключение контекста, а производительность относительно низкая. Кафка использоватьнулевая Технология копирования повышает производительность вышеуказанного процесса. Среди них постоянный диск сетевых данных в основном использует технологию mmap, а канал передачи сетевых данных в основном использует использование. sendfile технология.

4.5.1 Индексное ускорение mmap

В устаревшем режиме для передачи файлов по сети данных требуется 4 раза копирования данных, 4 переключения контекста Второсортировки и два системных вызова Второсортировки. Как показано ниже:

для Для снижения затрат производительности, вызванных переключением контекста и копированием данных.,Kafkaиспользоватьmmapобработать его индексный файл。Kafkaсерединаизиндексдокументиспользовать Всуществоватьизвлекатьфайл журналасерединаиз новостейэффективный поиск。Эти индексные файлы поддерживаютсядляфайл, отображенный в памяти,Это позволяет Kafka быстро получать доступ и выполнять поиск по индексам в памяти.,отиускорятьсясуществоватьфайл журналасерединапозицияинформацияизпроцесс。mmap Прочитайте буфер в ядре (прочитайте буфер) из адреса и пользовательского пространства из буфера (пользователь буфер), так что буфер ядра можно использовать совместно с памятью приложения, устраняя необходимость сопоставления буфера ядра (читай буфер) копировать приезжать пользовательский буфер (пользователь буфер) из процесса, будет происходить весь процесс копирования 4 Второсортныйначальство Переключиться ниже,1 Второсортный CPU Копировать 2Второсортный DMA копия.

4.5.2 Файл отправки для передачи данных по сети

Реализовано традиционным способом: сначала прочитайте диск, а затем используйте его. socket Отправить, актуально Слишком на четыре Второсортный копия. Как показано ниже:

для Для снижения затрат производительности, вызванных переключением контекста и копированием данных.,Kafka существовать Consumer от Broker читатьданныепроцесссерединаиспользовать Понятно sendfile технология.специфическийсуществоватьздесь采использоватьизпландапроходить NIO из transferTo/transferFrom Вызов операционной системы из sendfile Достичь нулевого количества копий. 2 Второсортный Ядроданныекопировать、2 Второсортный переключатель контекста и системный вызов Второсортный удалены. CPU Копирование данных следующим образом:

4.6 Разреженный индекс

Для Чтобы облегчить извлечение журналов и очистку сроков их хранения, Kafka Помимо файлов журналов, они используются для хранения журналов. .log файл и файл индекса смещения .index èИндексный файл временной метки .timeindex документ,Имена трех файлов абсолютно одинаковы,следующее:

Kafka индексный файл isv соответствии с В соответствии сразреженный Разработан с учетом идей индексизации. разреженный Ядро индексизации не сохраняет индекс для каждой записи, а только добавляет значение индекса после записи определенной записи. Конкретный интервал равен много и применяется. log.index.interval.bytes Параметры для управления, размер по умолчанию: 4 КБ, значит Kafka Напишите хотя бы 4KB После сообщения данных в существующий индексный файл будет добавлена ​​индексная запись. Видно, что размер одного сообщения будет влиять Kakfa Индекс частоты вставки, следовательно log.index.interval.bytes Слишком Kafka Настройка значения важного параметра. потому что чтоиндексдокумент Слишкомв соответствии с Инкрементирует элементы индекса в порядке сообщений, поэтому Kafka Для поиска целевого элемента индекса можно использовать алгоритм двоичного поиска, что сокращает временную сложность. O(lgN), что значительно сокращает время поиска.

Индекс смещения file.index

Смещениеиндексдокументиз Структура элемента индексаследующее:

Относительное смещение:保жить Виндексдокументимяначальстволапшаизначинать Смещениеиз Разница,Предполагаемый индексный файл для:00000000000000000100.index,Тогда начальное значение смещения равно 100., при объёме хранения для 150 из индексация новостей,Относительное смещение из в существующем индексном файле составляет 150 - 100 = 50.. Преимущество этого заключается в использовании 4 字节保жить Смещение Прямо сейчас Может,Можно сэкономить много дискового пространства.

Физическое расположение файла:информациясуществовать log Сохраните местоположение в файле, то есть Kafka Вы можете быстро найти сообщение «Жить существовать» по смещению сообщения, введя индексный файл смещения. log Физическое местоположение в файле. Используя значение физического местоположения, мы можем быстро изменить его. log документсерединапопытаться найтиприезжатьпереписыватьсяиз новостей Понятно。Ниже я использую фотографии для представления Kafka Как быстро получить сообщения:

гипотеза Kafka Необходимо найти перемещение как 3550 из новостей,Так Kafka Во-первых, использование алгоритма двоичного поиска позволит найти жилье меньше, чем 3550 из Максимальная запись индекса: [3528, 2310272], после получения пункта индекса приезжать, Кафка Будет основано на записи индекса существующего физического местоположения файла. log от позиции в файле 2310272 Начинайте поиск последовательно, пока не найдете место перемещения для 3550 из новостей Записыватьдляконец。

Индексный файл метки времени.timeindex

Kafka существовать 0.10.0.0 В будущих версиях к сообщениям будет добавляться информация о временных метках, чтобы удовлетворить потребности пользователей в запросе записей сообщений на основе временных меток, Kafka добавляет индексный файл временной метки,时间戳индексдокументиз Структура элемента индексаследующее:

Получение файла индекса временной метки аналогично файлу индекса смещения. Ниже представлена ​​диаграмма сообщений быстрого поиска:

4.7 broker & раздел данных

Kafka Кластер содержит несколько маклер. один topic Обычно их несколько partition,partition распределенныйсуществоватьдругойиз Broker включено, для хранения topic из новостей, что делает Kafka существующего может обрабатывать и хранить сообщения на нескольких машинах, давая kafka поставлять Давать Понятнои ХОРОШОиз новостейвычислительная мощностьирядом КВозможность расширения。

4.8 Модель многореакторной многопоточной сети

много Reactor многопоточная сетевая модель Это эффективная модель сетевой связи, в которой используется Reactor Потоки — рабочие потоки для обработки сетевых запросов, могут полностью использовать много ядер. CPU производительности, улучшить пропускную способность системы и скорость отклика. Кафка для повышения пропускной способности системы, существования Broker Эта модель используется, когда клиент обрабатывает сообщения, как показано ниже:

SocketServer и KafkaRequestHandlerPool Есть два наиболее важных компонента:

• Сокет Сервер: реализация Reactor Режим обработки много Клиент (включая клиента и других broker Node) из одновременных запросов, и результаты обработки начинают Client。
• KafkaRequestHandlerPool：Reactor Режим в из Worker Пул потоков, который определяет множество рабочих потоков для обработки реальных операций. I/O логику запроса.

Весь процесс обработки запроса на стороне сервера условно разделен на следующие этапы:

1. Акцептор принимает запросы от клиентов.
2. опросраспределение Давать Processor Обработка нитей.
3. Processor Инкапсулируйте запрос в Request объект, поставить приезжать RequestQueue очередь.
4. KafkaRequestHandlerPool Назначьте рабочие потоки для обработки RequestQueue серединаизпросить。
5. KafkaRequestHandler После того как поток обработает запрос, он ответит Response возвращаться Давать Processor нить.
6. Processor Поток ответит клиенту.

05. Исследование других знаний

5.1 Балансировка нагрузки

5.1.1 Балансировка нагрузки производителя

Kafka Завершение дисбалансировки производства нагрузка в основном относится к тому, как отправить сообщение отправить в Подходит для разделения. Кафка Когда производитель создает сообщение, он доставляет сообщение в указанный раздел в соответствии с разделителем, поэтому Kafka избалансировка нагрузка во многом зависит от разделителей. Кафка Разделитель по умолчанию Kafka Предоставить из Дефолт Партиционер. Он из раздела Стратегия основан на Key ценить Распределение разделовиз:

• если ключ не равен нулю：верно Key ценить Hash вычислить,отВсе разделысерединав соответствии с Key из Hash value вычисляет номер раздела, тот же; Key ценитьиз новостейбыло написано содин Раздел,Реализация последовательных сообщений является ключевой;
• если ключ равен нулю：информация Волякопросиз Способ,существоватьВсе доступные разделысередина Напишите отдельноинформация。если Нет настроенияиспользовать Kafka Разделитель по умолчанию, пользователи могут реализовать Partitioner Интерфейс, реализуйте метод разделения самостоятельно.

5.1.2 Балансировка потребительской нагрузки

существовать Kafka , каждый раздел (Partition) может использоваться только одним потребителем в одной группе потребителей. В группе потребителей много потребителей, когда, Кафка балансировка будет выполнена автоматически нагрузку, распределяйте перегородки равномерно на каждого потребителя. существовать Kafka в,потребительская балансировка Алгоритм нагрузки может включать заданную группу потребителей из partition.assignment.strategy параметры для выбора. В настоящее время основные распределения разделов следующие:

• range: В предпосылке обеспечения равновесия потребителям выделяются непрерывные перегородки, и соответствующая реализация RangeAssignor；
• round-robin：существовать Обеспечьте балансиз Под предпосылкой,опросраспределение,Соответствующая реализация — RoundRobinAssignor;
• Версия 0.11.0.0 Представлено новое распределение разделов Стратегия StickyAssignor,Его преимущество состоит в том, что он может максимально сохранить исходные результаты распределения разделов, обеспечивая при этом баланс разделов.,и избежать множества избыточных операций выделения разделов,Сократите время выполнения перераспределения разделов.

5.2 Управление кластером

Kafka С помощью ZooKeeper Выполните управление кластером. Кафка много информации, все существуют ZK Средний уход, например broker Кластерная информация, потребитель информация о кластере, topic сопутствующая информация, partition Информация и т. д. Кафка из ОЧЕНЬ много функция Слишком основана на ZK Осознайте из, например, partition Селектор, брокер Управление кластером, потребитель Балансировка нагрузки и т. д. не будут описаны в этой статье из-за ограничений по объему. Вот онлайн-скриншот, который может попробовать каждый: