Автор:мо

введение

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

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

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

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

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

Как показано на рисунке выше, Кафка Зависит от Producer、Broker、Consumer к И ответственное Управление кластеромиз ZooKeeper В целом функции каждой части заключаются в следующем:

• Producer：продюсер,Отвечает за создание сообщений и проведение определенных исследований. от Стратегия Отправить сообщение приезжатьподходитиз Broker；
• Broker：Экземпляр службы,Отвечает за сохранение, передачу и другие функции сообщений;
• Consumer : Потребитель, ответственный от Broker Получить подписку из новостейи потреблять,Обычно много потребителей образуют группу,Сообщения могут быть использованы только одним потребителем в одной группе;
• ZooKeeper：负责 broker、consumer 集群元данныеиз Управление и т. д.；（Примечание: продюсер прямое соединение broker,Нетсуществовать zk Сохраните любые данные, просто передайте ZK монитор broker и topic и другая информация）

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

• topic：Тема сообщения。Kafka в соответствии с topic Для классификации сообщений нам нужно лишь указать время отправки и получения сообщений. topic。
• partition：Раздел。дляподъемная системаиз Колебание,один topic Обычно их несколько partition,partition распределенныйсуществовать Нет同из Broker включено, для хранения topic из новостей, что делает Kafka существовамного может обрабатывать и хранить сообщения на нескольких машинах, давая kafka Он обеспечивает возможности параллельной обработки сообщений и возможности горизонтального расширения. Кроме того, для повышения надежности системы разделите Обычно делятся на группы, и каждая группа имеет основную partition、многоиндивидуальныйкопировать раздел, и распределение существует по-другому из broker начальство,отростприезжатьАварийное восстановлениеизэффект。
• segment：сегментация。宏观начальство看,один partition Соответствует бревно (Журнал). Зависит от Впродюсер生产из новостейвстреча Нет断追加приезжать log конец файла,для предотвращает слишком большой размер документа журнала, что приводит к неэффективному извлечению данных,Kafka Механизм сегментации и индексирования используется для объединения каждого partition разделен на формного сегмент, что также облегчает обслуживание и очистку сообщений.。每индивидуальный segment Содержит .log бревнодокумент, два индекса (.index, timeindex) документк и другие возможности издокумента. каждый Segment изданныедокументы самые маленькие из в этом абзаце offset длядокументимя,когда Находить offset из Message время, используйте бинарный поиск, чтобы быстро найти место проживания Message Расположен в Segment середина.
• offset：информациясуществоватьбревносерединаиз Расположение,информациясуществоватьбыть добавленприезжать Разделбревнодокументиз时候都встреча分配один特定изкомпенсировать。offset Это уникальный идентификатор в существующем разделе сообщений, монотонно увеличивающийся и неизменяемый из значений. Кафка проводить гарантирует порядок существования сообщений внутри раздела, но offset и Нет跨越Раздел,То есть,Кафка гарантирует, что из упорядочено по разделам, а не по темам.。

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

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

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

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

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

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

длягарантированный Сообщения надежно отправляются от производителей брокерам.,Нам нужно обеспечить две вещи；

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

стратегия взлома

Нацельтесь на проблему 1,Kafka Нам предоставлено три стратегия взлома,

• Request.required.acks = 0: запрос отправлен и подтвержден.,Мне все равно, написал я успех или нет.,Обычно используется в сценариях бревного анализа;
• Request.required.acks = 1：когда leader partition писатьуспехкназад,успех просто напиши,Потерянныйданныеизвозможный；
• Request.required.acks= -1: После того, как все копировать записываются в список ISR,这条информацияуспех просто напиши,Сильная гарантия надежности;

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

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

Нацельтесь на проблему 2,kafka Предусмотрено два типа методов отправки сообщений: синхронная (синхронная) отправка и асинхронная (асинхронная) отправка. Соответствующие параметры следующие:

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

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

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

1. существоватьОсновная сопрограммасередина调用Отправить асинхронно kafka Суть отправки сообщения заключается в помещении тела сообщения в input из канал, просто введите channel успеха, то эта функция запускается напрямую, без каких-либо блокировок. Напротив, если в channel В случае неудачи будет возвращено сообщение об ошибке. Так позвони async появляетсяиз сообщение об ошибке при записи из channel Сообщение об ошибке. Что касается конкретного финального сообщения, есть ли какое-либо сообщение об ошибке в kafka из брокер, мы не можем знать стоимость отвозвращаться.
2. когда приходят новости input из channel назад,встреча有另одиндиспетчер из сопрограммы负责遍历 ввод, чтобы на самом деле отправить сообщение приезжать конкретно Broker начальствоиз主 Partition начальство。Отправить результатыпроходитьодинАсинхронная сопрограммаруководитьмонитор,Циклическая обработка err channel и success канал, появился error Просто запомни одно бревно. Поэтому при асинхронной записи сцены напишите kafka из сообщения об ошибке, мы можем знать эту ошибку только на данный момент, чтобы узнать, какая конкретная ошибка произошла, из она не поддерживает нашу собственную функцию для ее обработки, эта точка существует trpc-go из Чиновник также был признан приезжающим.

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

Отправить синхронно(ack != 0 场景)дасуществовать Отправить асинхронность реализуется путем добавления к условных ограничений. Отправлять синхронные сообщения существуют newSyncProducerFromAsyncProducer середина开启两индивидуальныйАсинхронная сопрограмма处理информацияуспехи неудачаиз“перезвонить”,ииспользовать waitGroup Подождите, чтобы преобразовать асинхронную операцию в синхронную. Процесс примерно следующий:

Провести Приведенный выше анализ позволяет обнаружить, что Кафка Отправка сообщений по сути асинхронна, но Отправить синхроннопроходить waitGroup Преобразование асинхронных операций вдля Синхронная работа。Отправить в определенной степени гарантирует, что мы существуем в сети К Broker При передаче сообщения сообщение должно быть передано надежно. Broker。потому чтодлясуществовать Отправить В синхронном сценарии мы можем четко определить, отправлено сообщение или нет. Broker,Если сообщение не удалось отправить из-за дрожания сети, простоя компьютера и т. д., результат неизвестен.,Можетпроходить重试ждать手段确保информацияхотя бы один раз отправить в Брокер Кроме того, Кафка (0.11.0.0). версия) также Producer Предусмотрены два механизма для достиженияровно один раз Отправка сообщения: идемпотентность и транзакция.

краткое содержание

проходить стратегия взлома Конфигурация、Отправить синхронно、事务информация组合能力,我们Можетквыполнитьровно один раз семантика跨сеть К Broker Передавать сообщения. Однако продюсер получать Broker изуспех ак, а сообщение не потеряется? Чтобы понять эту проблему, мы должны сначала понять Broker Что же делали существа после получения сообщения от получать.

Надежное сохранение сообщений, отправленных брокеру

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

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

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

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

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

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

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

follower Совпадает ли копия leader Критерий оценки синхронизации зависит от Broker Конечные параметры replica.lag.time.max.ms(по умолчаниюдля 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 и ЛЕО：

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

Как показано на рисунке выше, он представляет собой файл журнала. Этот файл журнала содержит. 8 сообщения, 0 к 5 Между изMessageдля было отправлено сообщение, 5 к 7 изMessageдля Ни одно сообщение не было отправлено. бревнодокументиз HW для 6, что указывает на то, что потребители могут только тянуть 5 До из новостей, пока offset для 5 из Сообщения невидимы для потребителей. бревнодокументиз LEO для 8, здесь будет написано следующее сообщение.

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

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

Примечание: для удобно для описания,Ниже приведена аббревиатура Leader HW дляHWL.,Follower HWаббревиатурадляF,Leader LEOаббревиатурадляLEOL,Follower LEOаббревиатурадляLEOF。

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

1. исходное состояние

HWL=0,LEOL=0,HWF=0,LEOF=0。

1. Follower Нет. fetch

• Лидерполучать Производитель отправляет сообщение о завершении хранения, обновлениеLEOL=1;
• FollowerотLeader fetchданные,  Лидер получает запрос, записывает подписчиковизLEOF =0, и попробуйте обновить HWL =min(всекопироватьLEO)=0；
• eadeвозвращатьсяHWL=0иLEOL=1для подписчика,Подчиненный сохраняет сообщение и обновляет LEOF =1, HW=min(LEOF,HWL)=0。

1. Follower Нет.Второй fetch

• Снова последовательот Лидер fetchданные,  Лидер получает запрос, записывает подписчиковизLEOF =1, и попробуйте обновить HWL =min(всекопироватьLEO)=1；
• leadeвозвращатьсяHWL=1иLEOL=1 к подписчику,Leaderполучатьпросить,更новыйсебя из HW=min(LEOF,HWL)=1。

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

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

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

Шаг 1:

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

Шаг 2:

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

Шаг 3:

B Разбился, мин.ISR Настройка из 1. Итак, zookeeper встречаот ISR Выберите другой как для лидер, то есть А, но A изданные - это не полное из, но потеря данных Феномен。

В чем проблема? лежит в A После перезагрузки HW для стандартного усекается много избревно. Можно ли не обрезать? Нет, потому что для этого бревно могло быть не подано (то есть не было подано). ISR Все узлы в файле записаны), и сохранение может вызвать путаницу.

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

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

Шаг 1:

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

Шаг 2:

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

Шаг 3:

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

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

Leader Epoch

для Чтобы устранить вышеуказанные недостатки, Kafka представил Leader Epoch из концепции. лидер epoch и raft Понятие числа терминов в среднем сроке очень похоже. Вам нужно каждый раз выбирать заново. leader из, используйте строго монотонно возрастающую из 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 Генерация начального смещения (т.е. 1）,A После обнаружения конфликта он усекает свое собственное смещение для 1 избревно и начать сначала и leader синхронный. копировать A икопировать B избревно добрался до места проживания и разрешил возникшую бревно путаницу.

краткое содержание

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

Потребители получают сообщения от брокера и желательно использовать их только один раз.

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

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

Высокопроизводительное исследование Kafka

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

• Отправить асинхронно
• Отправить оптом
• технология сжатия
• Pagecache механизм&Добавляйте заказы последовательно
• нулевая копия
• разреженный индекс
• broker & раздел данных
• Модель многореакторной многопоточной сети

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

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

Отправить оптом

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

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

существовать Kafka В клиенте-производителе, когда отправляется сообщение, если включено Отправить оптом,Kafka встреча Воляинформация缓存приезжатьбуферсередина.когдабуферсерединаиз новостей Большой и маленькийприезжать batch.size или Время ожидания до linger.ms Когда, Кафка встреча Волябуферсерединаиз новостей打包成один批次руководить发送。еслисуществовать Время ожидания не наступилоприезжать batch.size,Kafka 也встреча Волябуферсерединаиз новости Отправить,от и избежать задержки сообщений.

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

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

• Колебание量：LZ4>Snappy>zstd и GZIP,Степень сжатия：zstd>LZ4>GZIP>Snappy。

существовать Kafka середина,технология сжатиядапроходитьк下两индивидуальныйженьшень数来контрольиз：

1. compress.type: управляет типом алгоритма сжатия, значение по умолчанию для none означает отсутствие сжатия.
2. Compression.level: Управление уровнем сжатия.,Диапазон значенийдля 0-9,Значение по умолчанию — для-1. когда стоит - 1 раз,Указывает использовать уровень сжатия по умолчанию.

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

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

kafka Для того, чтобы улучшить пропускную способность системы и уменьшить задержку, Broker После получения сообщения просто напишите данныеPageCacheТогда считается, что сообщение написано успешно, и PageCache серединаизданныепроходить linux из flusher 程序руководить异步刷盘（Избегайте синхронной чистки дисковиз Огромные системные накладные расходы）,Воляданныепоследовательное добавление записиприезжатьдискбревнодокументсередина.Зависит от В pagecache Он кэшируется в памяти, поэтому скорость чтения и записи очень высокая, что может значительно повысить эффективность чтения и записи. одновременное добавление записи Получите максимум от заказа I/O Операции записи избегают медленных и случайных I/O операция, которая может эффективно улучшить Kafka Колебание.

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

нулевая копия

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

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

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

Чтобы снизить затраты на производительность, вызванные переключением контекста и копированием,Kafkaиспользоватьmmapобработать его индексдокумент。Kafkaсерединаизиндексдокумент用Всуществоватьизвлекатьбревнодокументсерединаиз новостей时руководить高效Находить。这些индексдокументподдерживаетсядлякарта памятидокумент,Это позволяет Kafka быстро получать доступ и выполнять поиск по индексам в памяти.,оти加速существоватьбревнодокументсередина定位информацияизпроцесс。mmap Прочитайте буфер в ядре (прочитайте буфер) из адреса и пользовательского пространства из буфера (пользователь буфер), так что буфер ядра можно использовать совместно с памятью приложения, устраняя необходимость сопоставления буфера ядра (читай буфер) копировать приезжать пользовательский буфер (пользователь буфер) из процесса, будет происходить весь процесс копирования 4 вторичное переключение контекста, 1 Вторичный процессор Копировать 2 раза DMA копия.

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

Реализовано традиционным способом: сначала прочитать диск, а затем отправить его с помощью сокета. Фактически делается четыре копии. Как показано ниже:

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

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

для облегчения извлечения бревно и очистки по истечении срока годности, Kafka Бревнодокумент помимо хранилища имеет бревноиз.log документ,还有одинИндекс смещения file.indexиодинИндексный файл метки времени.timeindex документ,итридокументиз имеет то же имя,следующее:

Kafka изиндексдокументдав соответствии с В соответствии сразреженный индексиз思想руководить设计из。разреженный индексиз Ядро не для каждой записи сохраняется в индексе,Вместо этого значение индекса будет добавлено после записи определенной записи.,специфический这индивидуальный间隔有много Общие правилапроходить 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 Запустите последовательный поиск и найдите приезжатьdisplacementдля 3550 из новостей Записыватьдляконец。

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

Kafka существовать 0.10.0.0 В более поздней версии к сообщению добавляется информация о временной метке. Чтобы удовлетворить потребности пользователей в запросе записей сообщений на основе временной метки, Kafka добавляет документ с индексом временной метки,时间戳индексдокументизиндекс项结构следующее:

Индекс временной метки извлечения документа аналогичен индексу смещения документа, как показано ниже:

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

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

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

много 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 нить Воля响应вернуться в клиенте

Другие исследования знаний

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

продюсербалансировка нагрузки

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

• если key Нетдля null：对 Key ценить Hash вычислить,отВсе разделысередина根据 Key из Hash value вычисляет номер раздела, тот же; Key 值из новостей被писать同один Раздел,Реализация последовательного сообщения из ключа；
• если key для null：информация Волякопросиз Способ,существоватьВсе доступные разделысередина分别писатьинформация。если Нет想использовать Kafka Разделитель по умолчанию, пользователь может реализовать его Partitioner Интерфейс, реализуйте метод разделения самостоятельно.

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

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

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

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

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

Ссылки

1. https://www.cnblogs.com/arvinhuang/p/16437948.html
2. https://segmentfault.com/a/1190000039133960
3. http://matt33.com/2018/11/04/kafka-transaction/
4. https://blog.51cto.com/u_14020077/5836698
5. https://t1mek1ller.github.io/2020/02/15/kafka-leader-epoch/
6. https://cwiki.apache.org/confluence/display/KAFKA/KIP-101+-+Alter+Replication+Protocol+to+use+Leader+Epoch+rather+than+High+Watermark+for+Truncation
7. https://xie.infoq.cn/article/c06fea629926e2b6a8073e2f0
8. https://xie.infoq.cn/article/8191412c8da131e78cbfa6600
9. https://mp.weixin.qq.com/s/iEk0loXsKsMO_OCVlUsk2Q
10. https://cloud.tencent.com/developer/article/1657649
11. https://www.cnblogs.com/vivotech/p/16347074.html