Kafka Kafka была первоначально разработана компанией Linkedin. Это распределенная распределенная система обмена сообщениями с поддержкой разделов, основанная на репликах, координируемая zookeeper. Ее главная особенность заключается в том, что она может обрабатывать большие объемы данных в режиме реального времени. Удовлетворение различных сценариев спроса: такие как пакетные системы на основе Hadoop, системы реального времени с малой задержкой, потоковые механизмы storm/Spark, журналы web/nginx, журналы доступа, службы сообщений и т. д., написанные на языке scala, Linkedin в 2010 г. Вклад в Apache Foundation и стал лучшим проектом с открытым исходным кодом.
1. Предисловие Производительность очереди сообщений может быть хорошей или плохой, а структура ее механизма хранения файлов является одним из наиболее важных показателей для измерения технического уровня службы очереди сообщений. Далее будет проанализировано, как Kafka обеспечивает эффективное хранение файлов и его практическое применение с точки зрения механизма хранения файлов и физической структуры Kafka.
1.1 Особенности Кафки:- Высокая пропускная способность и низкая задержка: Kafka может обрабатывать сотни тысяч сообщений в секунду, а ее задержка составляет всего несколько миллисекунд.Каждая тема может быть разделена на несколько разделов, и группа потребителей использует разделы. - Масштабируемость: кластер kafka поддерживает горячее расширение - Постоянство и надежность: сообщения сохраняются на локальных дисках, а резервное копирование данных поддерживается для предотвращения потери данных - Отказоустойчивость: допускается сбой узлов в кластере (если количество реплик равно n, сбой узла n-1) — высокий параллелизм: поддержка тысяч клиентов для одновременного чтения и записи
1.2 Сценарии использования Кафки:- Сбор журналов: компания может использовать Kafka для сбора журналов различных сервисов и открывать их различным потребителям через Kafka в виде сервисов с унифицированным интерфейсом, таких как hadoop, Hbase, Solr и т. д. - Система обмена сообщениями: развязка и производителей и потребителей, кеширование сообщений и т.д. - Отслеживание активности пользователей: Kafka часто используется для записи различных действий веб-пользователей или пользователей приложений, таких как просмотр веб-страниц, поиск, клики и т. д. Эта информация об активности публикуется каждым сервером в теме kafka, а затем подписчиками. подпишитесь на эти действия, подписавшись на эту тему действий для мониторинга и анализа в режиме реального времени, или загрузите его в хауоп или хранилище данных для автономного анализа и анализа. - Операционные показатели: Kafka также часто используется для записи данных оперативного мониторинга. Это включает в себя сбор данных из различных распределенных приложений и создание централизованной обратной связи для различных операций, таких как сигналы тревоги и отчеты. - Потоковая передача: как искровая потоковая передача и шторм - источник событий
1.3 Идея дизайна Какфы - Выборы лидера Kafka Broker:Кластер Kakfa Broker управляется Zookeeper. Все узлы Kafka Broker отправляются в Zookeeper для регистрации временного узла, потому что Kafka только один. Брокер зарегистрируется успешно, а другие потерпят неудачу, поэтому брокер Kafka, который успешно зарегистрирует временный узел в Zookeeper, станет контроллером брокера Kafka, а другие брокеры Kafka называются последователями брокера Kafka. (Этот процесс вызывает контроллер для регистрации Watch в ZooKeeper). Этот контроллер будет отслеживать всю информацию о других брокерах Kafka.Если контроллер брокера Kafka выйдет из строя, временный узел на zookeeper исчезнет, и все брокеры Kafka исчезнут. Брокер отправится в Zookeeper, чтобы вместе зарегистрировать временный узел, потому что только один брокер Kafka зарегистрируется успешно, а остальные потерпят неудачу, поэтому брокер Kafka, который успешно зарегистрирует временный узел в Zookeeper, станет контроллером брокера Kafka, а другой брокер Kafka брокеров называют последователями Kafka Broker. Например: когда брокер не работает, контроллер брокера kafka прочитает состояние всех разделов на отключенном брокере на zookeeper и выберет реплику в списке ISR в качестве раздела. лидер (если все реплики в списке ISR отключены, выберите уцелевшую реплику в качестве лидера; если все реплики в разделе отключены, установите для нового лидера значение -1, дождитесь восстановления и подождите, пока любая из реплик ISR "живет" и выбирает его в качестве лидера; или выбирает первую "живую" реплику (не обязательно в ISR) в качестве лидера), когда брокер выходит из строя, контроллер kafka также уведомляет zookeeper, zookeeper Он уведомляет другие kafka брокеры.Здесь произошла ошибка, когда TalkingData использует Kafka0.8.1, после успешной регистрации контроллера кафки на Zookeeper время тайм-аута для связи с Zookeeper составляет 6 с, то есть, если контроллер кафки не бьется с Zookeeper через 6 с, то Zookeeper думает, что контроллер кафки сдох, она удалит временную ноду на Zookeeper, тогда другая кафка подумает, что контроллера больше нет, и бросится регистрировать временную ноду заново, а та кафка, что зарегистрировалась успешно Брокер становится контроллером, а затем предыдущему контроллеру kafka нужны различные отключения, чтобы закрыть мониторинг различных узлов и событий. Однако, когда трафик чтения и записи kafka очень велик, ошибка TalkingData заключается в том, что из-за сети и других причин контроллер kafka и Zookeeper не имеют связи в течение 6 с, поэтому новый контроллер kafka переизбирается, но исходный контроллер находится в выключенном состоянии всегда безуспешно.В настоящее время сообщение от производителя связано с наличием двух kafkas в кластере Kafka. контроллер и не может приземлиться. привести к стагнации данных. Раньше здесь была ошибка,Когда TalkingData использует Kafka0.8.1, когда ack=0, это означает, что производитель отправляет сообщение.Пока сообщение получено соответствующим лидером раздела брокера kafka, производитель возвращает успех, независимо от раздела Действительно ли лидер успешно сохранил сообщение в kafka. Когда акк=1,Указывает, что производитель отправляет сообщение, синхронно сохраняет сообщение лидеру раздела, соответствующему теме, а затем производитель возвращает сообщение об успешном выполнении, а лидер раздела асинхронно синхронизирует сообщение с другими репликами раздела. Когда ack=все или -1, Указывает, что производитель отправляет сообщение и синхронно сохраняет сообщение лидеру раздела соответствующей темы и соответствующей реплике, а затем возвращает успех. Но если некоторыеkafka controller При переключении это приведет к переключению лидера раздела (старый Лидер раздела на контроллере kafka будет избран другим брокерам kafka.), но это приведет к потере данных. - Группа потребителей:Каждый потребитель (потребитель нить) может сформировать группу (Consumer нить) группа), каждое сообщение в перегородке может потребляться только одного потребителя (потребитель нить) в группе (группы потребителей), если сообщение может потребляться несколькими потребителями (потребитель нить), то эти потребители должны быть в разных группах. Кафка не поддерживает сообщения в разделении обрабатываются двумя или более потребительских потоков под одной и той же группы потребителей, если не будет запущена новая группа потребителей. Так что если вы хотите, чтобы потреблять тему одновременно запустить несколько потребителей Группа хорошо, но следует отметить, что потребление нескольких потребителей здесь должно быть последовательным чтением сообщений в разделе. По умолчанию вновь начал потребитель начинает блокировать сообщение чтения из последнего места на голове из очередь разделов. Он не может использовать экспрессы в качестве потребителей взаимоисключающего (для обновления пессимистических блокировок) одновременно обрабатывать сообщения , как Amq. Это происходит потому , что , когда экспрессы потребляют данные в очереди, необходимо обеспечить , чтобы несколько потоков не может принять такое же сообщение А, так что требуется пессимизм на уровне строк (для обновления), что приводит к снижению производительности и потреблению недостаточной пропускной способности. Для того, чтобы обеспечить пропускную способность, Кафка позволяет только один и тот же потребитель Потребитель нить под группой получает доступ к разделу. Если вы чувствуете, что эффективность не высока, вы можете увеличить количество разделов, в горизонтальном направлении, а затем добавить новый потребительский поток, чтобы потреблять. Если вы хотите использовать несколько различных предприятий нуждаются в данных по этой теме, вы можете создать несколько групп потребителей. Каждый читает сообщения последовательно, а значения вне сайта не влияют друг на друга. Таким образом, нет никакой конкуренции замка, горизонтальная масштабируемость используются полностью, а пропускная способность чрезвычайно высок. Это также формирует концепцию распределенного потребления. При запуске группы потребителей не потреблять тему, независимо от того, сколько разделов не в теме, независимо от того, если наш потребитель Сколько потребительских потоки настроены в группе, все потребительские потоки в рамках этой группы потребителей будут потреблять все разделы, даже если есть только один поток-потребитель в этой группе потребителей, то этот поток-потребитель будет потреблять все разделы. Таким образом, оптимальная конструкция такова, что количество потребительских потоков по группам потребителей, равно числу разбиений, так что эффективность является самым высоким. Сообщение из того же раздела может использоваться только одним и тем же Потребителя Потребитель, в потребляет группу. Несколько потребителей в группе потребителей не может потреблять раздел одновременно. Под группой потребителей, независимо от того, сколько потребителей есть, потребитель группа должна вернуться и потреблять все разделы по этой теме. Когда число потребителей в группе потребителей меньше, чем число разделов по этой теме, как показано на следующем рисунке GroupA, GroupB, потребитель поток будет потреблять несколько разделов. Короче говоря, разделы по данной теме будет потребляться. если Когда число потребителей в группе потребителей, равно числу разбиений по этой теме, как показано в группе С, как показано ниже, эффективность является самым высоким в это время, и каждый раздел имеет потребительскую нить к потреблению. Когда число потребителей в группе потребителей больше, чем число разделов по этой теме, как показано на GroupD, как показано ниже, будет потребитель поток простаивает. Поэтому, когда мы создали группу потребителей, нам нужно только указать количество потребителей в нем. Там нет необходимости указывать соответствующий раздел потребления серийный номер, и потребитель будет автоматически восстановить равновесие. Потребители под несколькими группами потребителей могут потреблять такое же сообщение, но этот вид потребления также читает сообщения, чтобы потребить в пути O (1), так что эта партия сообщений, безусловно, будет потребляться неоднократно, не столько, сколько Amq. BET потребляется в качестве потребителя (заблокировать сообщение, и не может потреблять сообщение несколько раз, когда потребление) -Условия запуска потребительской перебалансировки:(1) Добавление или удаление Потребителя вызовет Перебалансировку Группы Потребителей (2) Увеличение или уменьшение Брокера вызовет Потребительское перебалансирование -Потребитель:Когда Потребитель обрабатывает сообщение в разделе, оно читается в порядке O(1). Следовательно, необходимо хранить вне сайта информацию о том, где она была прочитана в последний раз. Для API высокого уровня смещение хранится в Zookeeper, а смещение API низкого уровня поддерживается само по себе. Вообще говоря, используются API высокого уровня. Гарантия доставки потребителя, по умолчанию выполняется фиксация после прочтения сообщения, а затем обработка сообщения, автофиксация по умолчанию имеет значение true, в это время фиксация обновит внешний сайт + 1. После сбоя обработки внешний сайт был +1, и сообщение в это время будет потеряно; он настроен на чтение обработки сообщения и последующую фиксацию. В этом случае ответ стороны потребителя будет относительно медленным, и ему нужно дождаться завершения обработки. При нормальных обстоятельствах для обработки сообщения темы должна быть группа потребителей. Наилучшая практика заключается в том, что количество потребителей в группе потребителей равно количеству разделов в теме, поэтому эффективность является самой высокой, и один поток-потребитель обрабатывает один раздел. Если количество потребителей в группе потребителей меньше, чем количество партиций в топике, будет поток-потребитель, обрабатывающий несколько партиций одновременно (это автоматический механизм кафки, нам не нужно указывать), а короче все разделы в этой теме будут обработаны на оф. . если этот потребитель Количество потребителей в группе больше, чем количество разделов в топике, лишний поток-потребитель будет бездействовать и ничего не делать, а остальная часть - это поток-потребитель для обработки раздела, что приводит к пустой трате ресурсов, т.к. раздел невозможен. Обрабатывается двумя потоками-потребителями. Поэтому в наших распределенных онлайн-сервисах с несколькими сервисами количество потребителей кафки в каждом сервисе меньше, чем количество разделов соответствующей темы, но количество потребителей всех сервисов равно только количеству разделов, это потому, что услуга распределенного обслуживания Все потребители исходят от одного потребителя группа, если она исходит из разных групп потребителей, будут обработаны повторяющиеся сообщения (потребители из одной группы потребителей не могут обрабатывать один и тот же раздел, а разные группы потребителей могут обрабатывать одну и ту же тему, поэтому сообщения обрабатываются последовательно, и дубликаты будут обрабатываться Да, как правило, в этом случае используются две разные бизнес-логики, чтобы запустить две группы потребителей для обработки темы).
Если трафик производителя увеличивается, количество разделов текущей темы = количеству потребителей.В это время метод ответа заключается в расширении: увеличение раздела под темой и увеличение потребителей в группе потребителей.
![]()
![]()
- Delivery Mode :Кафка
Производителю не нужно поддерживать информацию о внешнем сайте сообщения при отправке сообщения, потому что в это время внешний сайт эквивалентен идентификатору с автоматическим приращением, и производитель может просто отправить сообщение. Кроме того, Kafka отличается от AMQ, AMQ в основном используется для обработки бизнес-логики, а Kafka — это в основном логи, поэтому производители Kafka обычно отправляют сообщения большими пакетами, отправляют большое количество сообщений в эту тему за один раз и балансируют нагрузку. на раздел. Вставьте их вместе, и оффсайт может быть добавлен как идентификатор автоинкремента сам по себе. Однако стороне-потребителю необходимо поддерживать внешнюю информацию о том, какое сообщение в данный момент потребляет раздел.
Уровень API поддерживается в Zookeeper, а API низкого уровня поддерживается собственной программой. (Только потребительская часть высокоуровневого API может отображаться в интерфейсе управления Kafka, потому что внешняя информация раздела низкоуровневого API поддерживается самой программой. Kafka этого не знает и не может отображать в интерфейсе управления. ) При использовании высокоуровневого апи сначала бери сообщение в обработку, а потом через равные промежутки времени автоматический коммит офсайт+1 (можно и на ручной), а какфа нет блокировки на обработку сообщения. Поэтому, если обработка сообщения не удалась, фиксации еще нет.
offsite+1, когда поток-потребитель перезапускается, сообщение будет использоваться повторно. Однако, как высокопроизводительная и высокопараллельная система обработки в реальном времени, в случае по крайней мере один раз она будет обработана по крайней мере один раз, что допустимо. Если вы не можете это терпеть, вам нужно использовать низкоуровневый API для самостоятельного обслуживания этой внешней информации, тогда вы можете сделать это самостоятельно, когда захотите зафиксировать вне сайта +1.
- Тема и раздел:Тема эквивалентна очереди очереди в традиционной системе сообщений MQ.Сообщение, отправляемое производителем, должно указывать, в какую тему оно отправляется, но не нужно указывать, какой раздел находится в теме, потому что kafka загрузит полученное сообщение. Баланс, равномерно распределенный по разным разделам по данной теме ( хеш(сообщение) % [количество брокеров] ). Физически эта тема разделена на один или несколько разделов, и каждый раздел эквивалентен подочереди. С точки зрения физической структуры, каждый раздел соответствует физическому каталогу (папке), а имя папки — [topicname]_[partition]_[серийный номер]. Тема может иметь бесконечное количество разделов, в зависимости от бизнес-требований и объем данных. В конфигурационном файле kafka параметр num.partitions может быть выше в любой момент, чтобы настроить количество разделов для смены темы, в Укажите количество разделов через параметры при создании темы. После создания темы количество разделов также можно изменить с помощью инструментов, предоставляемых Kafka. Вообще говоря, (1) количество разделов темы больше или равно количеству брокеров, что может повысить пропускную способность. (2) Реплика одного и того же раздела должна быть максимально распределена по разным машинам для обеспечения высокой доступности. При добавлении нового раздела, сообщение в партиции не будет перераспределено, данные сообщения в исходной партиции не изменятся, вновь добавленная партиция сначала будет пустой, а затем сообщение, попадающее в эту тему, будет переучастие в загрузке всех партиций остаток средств -Реплика раздела:Каждый раздел может хранить реплики на других узлах брокера kafka, поэтому отказ узла брокера kafka не повлияет на кластер kafka. Способ хранения копий реплик — хранить их в порядке брокеров kafka. Например, есть 5 узлов брокера kafka, тема имеет 3 раздела, и каждый раздел хранит 2 реплики, затем раздел 1 хранит брокера1, брокер2, а раздел2 хранит брокер2, брокер3. . . и так далее(Количество реплик не может быть больше, чем kafka Количество узлов брокера, иначе будет сообщено об ошибке. Количество реплик здесь - это фактически общее количество копий раздела, включая лидера, а остальные копии). Это, если брокер находится в центре города, вся кафка данных все еще завершена. Тем не менее, тем выше количество репликаций, тем более стабильна, но он возвращается к снижению ресурсов и производительности; если копия реплики меньше, она также приведет к риску данных потери системы. (1) Как передать сообщение: PRODUCTER PREWER Отправить сообщение в лидер раздела, а затем отправить его на другие разделы по лидеру Последователь. (Если продукт отправляется на каждую реплику, которое слишком медленно) (2) Вам необходимо гарантировать, сколько реплик получили это сообщение перед отправкой ACK производителю: в зависимости от количества ACKS (3) Как иметь дело с Replica Не работаю: если реплика разбиения этого отдела находится не в списке ACK, продюсер отправляется в лидер разбиения, и лидер раздела отправляет сообщение для последователя раздела без ответа. Это не повлияет на всю систему. В чем проблема Отказ Если это не работает раздел Реплика в списке ACK Media будет ждать, пока сообщение будет успешно написать сообщение, но ждать до появления времени, а затем вернуться к неисправности, потому что реплика раздела в списке ACK не отвечает, в это время кафка будет автоматически Удалите реплику разделов из этого раздела из списка ACK и не будут иметь реплику раздела в этом списке ACK при отправке сообщения. Быть (4) Как разобраться с неудачной репликами восстановления: если эта реплика раздела не находится в списке ACK, то повторно отправил управление зооздателем после запуска, то лидер продукта будет продолжать отправлять сообщение на этот раздел Foliwer. Если эта реплика раздела ранее находится в списке ACK, вам нужно будет добавить реплику этого раздела в список ACK. (Список ACK вручную добавляется и раздел определенной работы. Удалить из списка ACK, когда реплика) -Лидер и последователь раздела:Разделы также делятся на лидеров и последователей. Лидер — это основной раздел.Когда производитель пишет Kafka, он сначала записывает лидера раздела, а затем лидер раздела отправляет его другим последователям раздела. Информация о лидере и ведомом разделе контролируется Zookeeper, как только раздел Узел брокера, на котором находится лидер, не работает, и zookeeper выберет ведомого, чтобы он стал лидером раздела в последователях разделов других брокеров. -Алгоритм темы по назначению разделов и реплик разделов:(1) Отсортируйте брокера (размер = n) и выделяемый раздел. (2) Назначить i-й раздел (i%n)-му брокеру. (3) Назначить j-ю реплику i-го раздела ((i + j) %n) у брокеров
- Надежность доставки сообщенийСообщение, как добиться успеха, Kafka предусматривает три режима: - первый неудобный, при отправке он успешен, эта ситуация не может гарантировать успех сообщения Брокеру; - второй - Модель Master-Slave, только когда Мастер и все ведомые получают сообщения, эта модель обеспечивает высочайшую надежность доставки, но ухудшает производительность; - Третья модель, то есть до тех пор, пока мастер подтверждает, пожалуйста, успех; при фактическом использовании, в соответствии с характеристиками приложения, в большинстве случаев третья модель нейтрализуется и надежностью и производительностью Надежность сообщения находится на Брокере, потому что сообщение будет длиться на диске, поэтому, если нормальный Стоп является Брокером, данные на нем не теряются; но если не нормальный, СТОП может сделать представление страницы кеш для записи сообщения сообщение Потеряно, это можно настроить, настроив цикл очистки кеша страницы, порог снижен, но та же частая запись на диски повлияет на производительность, и вопрос выбора, который настраивается в соответствии с реальной ситуацией . Надежность потребления сообщений Kafka обеспечивает модель «По крайней мере один раз», потому что ход чтения сообщения обеспечивается смещением, и смещение может поддерживаться потребителями, но оно может поддерживаться в ZooKeeper, но когда потребление сообщения, потребитель виснет, OFFSET пишется не сразу, возможен повтор чтения, который тоже можно настроить на коммиты. Цикл OFFSET, снижение порога и даже потребители делают свое потребление и совершают смещение решения транзакции, но если ваше приложение не заботится о повторном потреблении, то вы просто не решаете его для обмена наибольшей производительностью.
- Подтверждение раздела:Когда ack=1, это означает, что после того, как производитель успешно записал лидер раздела, брокер возвращает успех, независимо от того, успешно ли записываются другие последователи раздела. Когда ack=2, это означает, что производитель успешно записывает лидера раздела и еще одного последователя, Брокер возвращает успех, независимо от того, успешно ли записываются другие последователи раздела. Когда ack=-1[количество разделов], это означает, что он успешен только тогда, когда все производители успешно записаны, а брокер kafka возвращает информацию об успехе.Здесь следует отметить, что если ack=1, как только брокер выходит из строя и вызывает переключение ведомого и ведущего раздела, данные будут потеряны.
- статус сообщения: в Kafka состояние сообщения хранится в потребителе, брокеру все равно, какое сообщение потребляется и кто его потребляет, и записывает только значение смещения (указывающее на следующую позицию сообщения в разделе, который будет потребляться), Это означает, что если потребитель плохо справляется с этим, сообщение брокера может быть использовано несколько раз. -сохранение сообщения: сообщение Kafka будет сохраняться в локальной файловой системе и поддерживать очень высокую эффективность o (1). Мы все знаем, что производительность чтения операций ввода-вывода является очень ресурсоемкой и медленной, что часто является узким местом для баз данных при вводе-выводе, поэтому необходимо изменить причины SSD. Но Kafka обладает высокой пропускной способностью MQ, но может быть очень эффективным сохранением сообщений в файле. Это связано с тем, что Kafka o представляет собой временную сложность последовательности записи (1), очень быструю. Причина в высокой пропускной способности. Из-за постоянного написания сообщения записываются по порядку, поэтому, когда сообщение должно быть потреблено, чтобы быть потребленным, чтобы обеспечить разделение порядка потребления сообщений. Общие машины, одиночные 100k данных в секунду. -срок действия сообщения: Kafka будет хранить сообщения в нем в течение длительного времени, чтобы потребитель мог использовать его несколько раз, конечно, многие детали настраиваются. -Produer :Производитель отправляет сообщение в тему без указания раздела, просто отправляет его напрямую. Kafka использует подтверждение раздела для проверки успешности передачи и возвращает информацию производителю.Производитель может иметь любое количество потоков, и серверу Kafka все равно. Доставка на стороне производителя гарантия по умолчанию по крайней мере один раз. Вы также можете настроить производителя на асинхронную отправку, чтобы достичь не более одного раза. Производитель может реализовать ровно один раз с идемпотентностью первичного ключа -Кафка высокая пропускная способность: высокая пропускная способность Kafka отражается на чтении и записи. Распределенное параллельное чтение и запись выполняются очень быстро. Производительность записи отражается в последовательной записи с временной сложностью O(1). Производительность чтения отражается в последовательном чтении с временной сложностью O(1), разделении темы, а поток потребления в группе потребления может выполнять последовательное чтение с высокой производительностью. - Гарантия доставки Kafka (гарантия доставки сообщений): (1) Максимум один раз сообщения могут быть потеряны и никогда не будут повторно переданы; (2) Хотя бы один раз сообщения никогда не будут потеряны, но могут быть переданы повторно; (3) Ровно один раз Каждая порция информации обязательно будет передана один и только один раз, чего и хочет пользователь. -Массовая рассылка: Kafka поддерживает пакетную отправку в единицах наборов сообщений для повышения эффективности push-уведомлений. -push-and-pull: Производитель и потребитель в Kafka используют режим push-and-pull, то есть производитель только отправляет сообщения брокеру, а потребитель только извлекает сообщения от брокера, а производство и потребление сообщений являются асинхронными. -Связь между брокерами в кластере Kafka: Это не отношения "ведущий-ведомый". Каждый брокер имеет одинаковый статус в кластере. Мы можем добавить или удалить любой узел брокера по желанию. -балансировки нагрузки: Кафка предоставляет API метаданных управляет нагрузкой между брокерами (для Kafka 0.8.x, для 0.7.x в основном используется zookeeper для достижения балансировки нагрузки). -Синхронный Асинхронный: Производитель использует асинхронный метод push, который значительно повышает пропускную способность системы Kafka (синхронный или асинхронный метод можно контролировать с помощью параметров). -Перегородка механизма перегородки: сторона брокера Kafka поддерживает раздел раздела сообщений, производитель может решить, в какой раздел отправить сообщение, в разделе Порядок сообщений — это порядок, в котором источник отправляет сообщения.В теме может быть несколько разделов, и количество конкретных разделов настраивается. Концепция разделения позволяет Kafka масштабироваться горизонтально как MQ с огромной пропускной способностью. Раздел может установить реплику-копию.Реплика-копия существует на разных узлах брокера kafka.Первый раздел является ведущим, а остальные – последователями.Сообщение сначала записывается в лидер раздела, а затем отправляется в раздел разделом лидер. последователь. Поэтому кафка может расширяться по горизонтали, то есть расширять партицию. -Автономная загрузка данных: Kafka также очень подходит для загрузки данных в Hadoop или хранилища данных благодаря поддержке масштабируемого сохранения данных. -Данные в реальном времени и автономные данные:Kafka поддерживает как автономные данные, так и данные в реальном времени, поскольку сообщения Kafka сохраняются в файлах, и можно установить период действия, поэтому Kafka можно использовать в качестве эффективного хранилища и использовать в качестве автономных данных для последующего анализа. Конечно, как распределенная система сообщений в реальном времени, она по-прежнему используется для обработки данных в реальном времени в большинстве случаев, но когда потребительская мощность снижается, данные могут накапливаться в Kafka за счет сохраняемости сообщения. -Поддержка плагинов: сейчас многие активные сообщества разработали множество плагинов для расширения функций Kafka, таких как плагины, относящиеся к Storm, Hadoop и flume. -разъединение: эквивалент MQ, выполнение асинхронных операций между производителем и потребителем и разъединение между системами. избыточность: Реплика имеет несколько копий, чтобы гарантировать, что весь сервис не пострадает, если узел брокера выйдет из строя.Расширяемость: Узлы брокера можно масштабировать по горизонтали, разделы также можно увеличивать по горизонтали, а реплики разделов также можно увеличивать по горизонтали —вершина горы: в случае резкого увеличения трафика кафка масштабируется по горизонтали, а приложениям все равно нужно продолжать функционировать - возмещаемость: Когда часть системы выходит из строя, это не повлияет на всю систему из-за реплики копии раздела. -гарантия заказа: поскольку производитель Kafka пишет сообщения, а читающие сообщения потребители представляют собой последовательное чтение и запись, гарантируется эффективная производительность. -буфер: Так как бизнес производителя может быть очень простым, в то время как back-end бизнес потребителя будет очень сложным и иметь операции с базой данных, то производитель должен быть быстрее, чем потребитель.Если нет кафки, производитель напрямую вызывает потребителя , что приведет к сбою всей системы. Скорость обработки низкая. Добавление слоя Kafka в качестве MQ может играть роль буферизации. -Асинхронная связь: как MQ, Producer взаимодействует с Consumer асинхронно.
Объект, опубликованный и подписанный в Kafka, называется топиком. Мы можем создать топик для каждого типа данных и назвать клиента, который публикует сообщения в топике, производителем, а клиент, который подписывается на топик, называется потребителем. Производители и потребители могут читать и записывать данные из нескольких тем одновременно. Кластер Kafka состоит из одного или нескольких серверов-брокеров, которые отвечают за сохранение и резервное копирование определенных сообщений Kafka.
2. ПроизводительностьПомимо дискового ввода-вывода, нам также необходимо учитывать сетевой ввод-вывод, который напрямую связан с пропускной способностью kafka.Kafka не предоставляет слишком много превосходных навыков; для стороны производителя сообщение может быть буферизовано, когда сообщение Когда число достигает определенного порога, оно отправляется брокеру пакетами, то же самое верно и для стороны потребителя, и несколько сообщений извлекаются пакетами.Однако размер тома сообщений можно указать через файл конфигурации. Со стороны брокера kafka кажется, что есть системный вызов sendfile, который потенциально может улучшить производительность сетевого ввода-вывода: сопоставить данные файла с системной памятью, и сокет может напрямую считывать соответствующую область памяти без необходимости процесс копирования и повторного обмена (это включает в себя «дисковые данные ввода-вывода» / «память ядра» / «память процесса» / «сетевой буфер», копирование данных между несколькими). На самом деле, для производителя/потребителя/брокера затраты ЦП должны быть небольшими, поэтому включение механизма сжатия сообщений является хорошей стратегией; сжатие требует небольшого количества ресурсов ЦП, но для kafka сетевой ввод-вывод должен требовать больше. сообщение, передаваемое по сети, может быть сжато.Kafka поддерживает несколько методов сжатия, таких как gzip/snappy.
3. Балансировка нагрузки: любой брокер в кластере kafka может предоставить производителю метаданные, в том числе «список серверов, оставшихся в кластере»/«разделы». «Список лидеров» и другая информация (см. информацию об узле в zookeeper). Когда производитель получает информацию о метаданных, производитель будет поддерживать сокетные соединения со всеми лидерами разделов в теме; сообщение отправляется непосредственно производителем в брокера через сокет, минуя средний уровень Любой «уровень маршрутизации» Асинхронная отправка, буферизация нескольких сообщений на стороне клиента и отправка их брокеру пакетами; слишком много операций ввода-вывода для небольших данных замедляет общую задержку в сети , а пакетная отложенная отправка на самом деле повышает эффективность сети, но это также таит в себе определенные скрытые опасности, например, когда производитель выходит из строя, те сообщения, которые не были отправлены, будут потеряны.
4. Для других JMS-реализаций модели Topic место потребления сообщений резервируется поставщиком, чтобы избежать повторной отправки сообщений или повторной отправки сообщений, которые не были успешно использованы, и т. д., а также контролировать состояние сообщения. , Это требует, чтобы JMS-брокер требовал слишком много дополнительных В kafka сообщения в разделе потребляются только одним потребителем, и нет контроля состояния сообщения и сложного механизма подтверждения сообщений. Сторона довольно легкая. Когда сообщение получено потребителем, потребитель может локально сохранить смещение последнего сообщения и периодически регистрировать смещение в zookeeper. Видно, что клиент-потребитель также очень легкий. Потребитель в kafka отвечает за ведение записей о потреблении сообщений, в то время как брокер не заботится об этом.Этот дизайн не только повышает гибкость на стороне потребителя, но и умеренно снижает сложность дизайна на стороне брокера; это отличается от многих JMS prodivers. Кроме того, дизайн сообщения ACK в kafka также сильно отличается от JMS. Сообщение в kafka отправляется потребителю пакетами (обычно в единицах количества сообщений или размера куска), и когда сообщение успешно обработано, сообщение отправляется в zookeeper.offset, без доставки ACK брокеру.Возможно, вы поняли, что этот "свободный" дизайн будет иметь риск "потерянных" сообщений/"повторной отправки сообщения".
5. Согласованная передача сообщений Kafka обеспечивает 3 вида семантики согласованности передачи сообщений: не более одного раза, не менее одного раза и ровно один раз. Минимум 1 раз: данные могут передаваться повторно, и данные могут обрабатываться повторно; максимум 1 раз: может произойти потеря данных; ровно 1 раз: это не значит, что они передаются только один раз, но есть механизм. Убедитесь, что нет ситуаций «дублирования данных» и «потеря данных».
не более одного раза: потребитель извлекает сообщение, затем сохраняет смещение, а затем обрабатывает сообщение; после того, как клиент сохраняет смещение, но процесс-потребитель дает сбой (сбой) в процессе обработки сообщения, что приводит к сбою некоторых сообщений для продолжения обработки Затем другие потребители могут взять на себя управление, но, поскольку смещение было сохранено заранее, новый потребитель не сможет получить сообщения до смещения (хотя они и не были обработаны), т. е. хотя бы один раз: потребитель извлекает сообщение, затем обрабатывает сообщение, а затем сохраняет смещение. сбой при сохранении операции смещения, что приводит к следующему, когда вы снова получаете, вы можете получить сообщение, которое было обработано в последний раз, то есть «хотя бы один раз». В сценарии «кластера Kafka» потребителю Для получения семантики непротиворечивости «ровно один раз» может быть принята следующая схема: К выходу потребителя дополнительно добавляется не менее 1 раза + максимальное количество обработанных сообщений: Ввиду существования максимального количества обработанных сообщений будет не допускать повторной обработки сообщений.
6. В replica kafka стратегия репликации основана на партиции, а не топике, кафка реплицирует данные каждой партиции на несколько серверов, любая партиция имеет одного лидера и несколько фолловеров (может и не быть), количество бэкапов можно передать через конфигурацию брокера файл для установки. Лидер обрабатывает все запросы на чтение-запись, а ведомый должен синхронизироваться с ведущим.Последователь как «потребитель», потребляющий сообщения и сохраняющий их в локальном журнале;лидер отвечает за отслеживание состояния всех последователи, если последователь слишком сильно «отстает» или терпит неудачу, лидер удалит его из списка синхронизации реплик.Когда все последователи успешно сохраняют сообщение, сообщение считается «зафиксированным», и тогда потребитель может его использовать. Эта стратегия синхронизации требует последователей. Между ней и лидером должна быть хорошая сетевая среда.Даже если выживет только один экземпляр реплики, нормальная отправка и получение сообщений все еще может быть гарантирована, пока выживает кластер zookeeper. При выборе ведомого необходимо учитывать одну проблему, а именно количество лидеров разделов, уже перенесенных на новый сервер-лидер.Если на сервере слишком много лидеров разделов, это означает, что этот сервер будет выдерживать большую нагрузку ввода-вывода. Для лидера необходимо учитывать «балансировку нагрузки», и брокер с меньшим количеством лидеров разделов с большей вероятностью станет новым лидером.
7. Формат каждой записи журнала: «4-байтовое число N представляет длину сообщения» + «N байтов содержимого сообщения», каждый журнал имеет смещение для уникальной маркировки сообщения, значение смещения 8-байтовое число, указывающее начальную позицию этого сообщения в этом разделе. Каждый раздел имеет несколько журналов на уровне физического хранилища. Состав файла (называемый сегментом). Файл сегмента называется "минимальное смещение".kafka. Например, "00000000000.kafka", где "минимальное смещение" представляет собой смещение начального сообщения в этом сегменте. При получении сообщения необходимо указать смещение и Максимальный размер чанка, смещение используется для указания начальной позиции сообщения, размер чанка используется для указания общей длины максимально полученного сообщения (косвенно указывает количество сообщений).Согласно смещению , вы можете найти файл сегмента, в котором находится сообщение, а затем в соответствии с сегментом взять разницу минимального смещения, получить его относительное положение в файле и напрямую прочитать вывод.
8. Распределенная kafka использует zookeeper для хранения некоторой метаинформации и использует механизм наблюдения zookeeper для обнаружения изменений в метаинформации и выполнения соответствующих действий (таких как сбой потребителя, запуск балансировки нагрузки и т. д.) Реестр узла брокера: Когда брокер kafka запускается, он сначала регистрирует информацию о своем узле (временный znode) в zookeeper, а когда брокер и zookeeper отключаются, znode также будет удален. регистрирует свою собственную тему и разделяет информацию, которая по-прежнему является временным znode.Группа потребителей и потребителей: при создании каждого клиента-потребителя он регистрирует свою собственную информацию в zookeeper; эта функция в основном предназначена для «балансировки нагрузки».A Несколько потребителей в группа может использовать все разделы темы в шахматном порядке; короче говоря, убедитесь, что все разделы этой темы могут быть использованы этой группой, и для соображений производительности разделы относительно равномерно распределены между каждым на потребителе. Реестр идентификаторов потребителей: каждый потребитель имеет уникальный идентификатор (хост: uuid, который может быть указан в файле конфигурации или сгенерирован системой), и этот идентификатор используется для пометки информации о потребителе.Отслеживание смещения потребителя: используется для отслеживания каждого потребителя. наибольшее смещение в используемом в данный момент разделе. Этот znode является постоянным узлом. Видно, что смещение связано с group_id, что указывает на то, что при сбое одного потребителя в группе другие потребители могут продолжать потреблять. Реестр владельца раздела: Используется для обозначения того, какой потребитель потребляет раздел. Этот узел выражает, что «раздел» может быть использован только следующим потребителем в группе, и когда потребитель в группе выйдет из строя, будет запущена балансировка нагрузки (т. Разделы потребителей) Когда потребитель запускается, инициируемые операции: A) Сначала выполните «Реестр идентификаторов потребителей»; B) Затем зарегистрируйте часы в узле «Реестр идентификаторов потребителей», чтобы отслеживать «выход» и «выход» других потребителей. в текущей группе "присоединиться"; пока этот znode Изменения в списке узлов под путем вызовут балансировку нагрузки потребителей в этой группе (например, если потребитель выйдет из строя, другие потребители займут разделы). C) В узле «Реестр идентификаторов брокера» зарегистрируйте следите за выживанием брокера; если список брокеров изменится, это вызовет перебалансировку потребителей во всех группах.
Резюме: 1) Сторона производителя использует zookeeper для «обнаружения» списка брокеров и каждого раздела в разделе «Тема». Лидер устанавливает подключение к сокету и отправляет сообщения. 2) Сторона брокера использует zookeeper для регистрации информации о брокере и отслеживает выживание лидера раздела. 3) Сторона потребителя использует zookeeper для регистрации информации о потребителе, включая список разделов, потребляемых потребителями. и т. д., а также используется для обнаружения списка посредников, установления соединения через сокет с лидером раздела и получения сообщений.
9. Выбор лидера Ядром Kafka является лог-файл, а синхронизация лог-файла в кластере — это самый базовый элемент распределенной системы данных. Нам не нужны последователи, если лидеры никогда не уходят! Как только лидер вышел из строя, необходимо выбрать нового лидера среди последователей.Однако сами последователи могут слишком долго задерживаться или давать сбои, поэтому в качестве лидера необходимо выбрать высококачественного последователя.Должно быть гарантировано, что сообщение представлен, лидер отключен, вновь избранный лидер должен быть в состоянии предоставить это сообщение. В большинстве распределенных систем для выбора нового лидера используется метод мажоритарного голосования.При мажоритарном методе голосования наиболее подходящий лидер выбирается динамически в соответствии со статусом всех узлов реплики.Кафка не использует этот метод. Kafka динамически поддерживает набор синхронизированных реплик (сокращенно ISR), узлы в этом наборе в высокой степени согласованы с лидером, и любое сообщение должно быть прочитано каждым членом набора.После того, как узел прочитает и добавит в журнал , он уведомляет внешнюю среду о том, что сообщение отправлено. Таким образом, любой узел в этом наборе может быть выбран лидером в любое время.ISR поддерживается в ZooKeeper. Если в ISR есть узлы f+1, то разрешено предоставлять услуги в обычном режиме без потери сообщений при выходе из строя f узлов. Члены ISR являются динамическими. Если узел удаляется, он может снова присоединиться к ISR, когда снова достигнет состояния «синхронизации». Этот метод выбора лидера очень быстр и подходит для сценариев приложений Kafka. Дурная идея: что, если все узлы не работают? Гарантия Kafka на то, что данные не будут потеряны, основана на том, что по крайней мере один узел находится в рабочем состоянии.Если все узлы не работают, это не может быть гарантировано. В практических приложениях, когда все реплики не работают, они должны реагировать вовремя. Есть два варианта: 1. Подождать, пока любой узел в ISR восстановится и станет ведущим. 2. Выберите первый восстановленный узел среди всех узлов (а не только ISR) в качестве лидера Это компромисс между доступностью и непрерывностью. Если вы дождетесь восстановления узлов в ISR, после отказа узлов в ISR или исчезновения данных кластер никогда не восстановится. Если вы дождетесь неожиданного восстановления узла ISR, данные этого узла будут использоваться как онлайн-данные, которые могут отличаться от реальных данных, поскольку некоторые данные могут быть не синхронизированы. В настоящее время Kafka выбирает вторую стратегию, в будущих версиях выбор этой стратегии будет настраиваемым и может гибко подбираться по сценарию. С этой дилеммой сталкивается не только Кафка, но и почти все распределенные системы данных.
10. Управление репликами В приведенном выше обсуждении в качестве примера рассматривается только одна тема и один раздел, но на самом деле Kafka будет управлять тысячами разделов темы.Kafka пытается сделать все разделы равномерно распределенными по всем узлам в кластере вместо того, чтобы концентрироваться на некоторых узлы, и постарайтесь максимально сбалансировать отношения master-slave, чтобы каждая точка служила лидером определенной доли раздела.Также очень важно оптимизировать процесс выбора лидера, который определяет пустое окно период, когда система выходит из строя, как долго. Kafka выбирает узел в качестве "контроллера". Когда узел оказывается неработоспособным, он отвечает за выбор нового лидера среди всех узлов плавающего раздела, что позволяет Kafka эффективно управлять отношениями ведущий-ведомый всех узлов раздела. партиями. если контроллер вниз, один из активных узлов переключится на новый контроллер.
11. Синхронизация лидера и реплики Для раздела «посредник», сохраняющий положительный раздел, является «лидером» раздела, а «посредник», сохраняющий резервный раздел, является «последователем» раздела. Резервный раздел полностью скопирует сообщения положительного раздела, включая дополнительные значения атрибутов, такие как номер сообщения. Чтобы сохранить согласованность содержимого положительного раздела и резервного раздела, решение, принятое Kafka, состоит в том, чтобы запустить процесс-потребитель для потребления на «брокере», который сохраняет резервный раздел, чтобы содержимое положительного раздела было согласовано. с содержимым резервного раздела. Как правило, раздел имеет один «положительный раздел» и ноль или более «резервных разделов». Можно настроить общее количество «положительных разделов + резервных разделов».Для этой конфигурации разные темы могут иметь разные значения конфигурации. Обратите внимание, что производители и потребители общаются только с «лидером», который держит положительный раздел.
Kafka позволяет разделам темы иметь несколько реплик.Это число можно настроить.Вы можете настроить количество реплик для каждой темы. Kafka автоматически создает резервную копию данных на каждой реплике, поэтому данные по-прежнему доступны, когда узел выходит из строя. Функция копирования Kafka необязательна, вы можете настроить только одну копию, что фактически эквивалентно только одной копии данных. Единицей для создания реплик является раздел топика. У каждого раздела есть лидер и ноль или более последователей. Все операции чтения и записи обрабатываются лидером. Как правило, количество разделов намного больше, чем количество брокеров. лидер каждой секции Равномерно распределяется между брокерами. Все последователи копируют журнал лидера, а сообщения и порядок в журнале такие же, как и в лидере. Последователи получают сообщения от лидера, как обычные потребители, и сохраняют их в своих собственных файлах журналов. Многие распределенные системы обмена сообщениями автоматически обрабатывают неудачные запросы, и у них есть четкое определение того, жив ли узел. Кафка определяет, жив узел или нет. Есть два условия: 1. Узел должен иметь возможность поддерживать соединение с ZooKeeper. , Zookeeper проверяет соединение каждой ноды через механизм heartbeat 2. Если нода является ведомой, она должна иметь возможность синхронизировать операцию записи лидера по времени, и задержка не должна быть слишком большой. условия должны быть точно «синхронизированы (синхронизированы)», а не расплывчато говорить «активен» или «сбой».Лидер будет отслеживать все «синхронизированные» узлы, как только один из них выйдет из строя, застрял или задерживается слишком долго. это долго,лидер удалит.Что касается того,насколько задержка "слишком большая",то определяется параметром replica.lag.max.messages.Что застрял и как параметр replica.lag. time.max .ms решил. Только когда сообщение добавляется в журнал всеми репликами, оно считается «зафиксированным», и только зафиксированное сообщение будет отправлено потребителю, так что не нужно беспокоиться о потере сообщения после ухода лидера. вниз. Производитель также может выбрать, ждать ли уведомления о том, что сообщение отправлено, что определяется параметром acks. Kafka гарантирует, что пока существует «синхронизирующий» узел, «зафиксированные» сообщения не будут потеряны.
2.3 Распределение хранения разделов в теме
|--report_push-1
|--report_push-2
|--report_push-3
|--launch_info-0
|--launch_info-1
|--launch_info-2
|--launch_info-3
В файловом хранилище Kafka есть несколько разных разделов в одной и той же теме, каждый раздел представляет собой каталог, правило именования разделов — это имя раздела + порядковый номер, первый номер раздела начинается с 0, а максимальное число — это количество разделов минус количество разделов 1. Когда сообщение отправляется, оно отправляется в тему, которая по сути является каталогом, а тема состоит из нескольких разделов.Его организационная структура показана на следующем рисунке:
Мы видим, что Раздел представляет собой структуру Очереди, сообщения в каждом Разделе упорядочены, создаваемые сообщения постоянно добавляются к Разделу, и каждому сообщению присваивается уникальное значение смещения.
Кластер Kafka сохранит все сообщения, независимо от того, используются они или нет;Мы можем установить время истечения срока действия сообщения, и только просроченные данные будут автоматически очищены, чтобы освободить место на диске.Например, если мы установим время истечения сообщения на 2 дня, то все сообщения в течение этих 2 дней будут сохраняться в кластере, а данные будут очищаться только в том случае, если оно превышает два дня.
Kafka поддерживает только значение смещения в разделе, потому что это смещение определяет, сообщение какого раздела потребляется. Каждый раз, когда потребитель потребляет сообщение, смещение увеличивается на 1. На самом деле состояние сообщения полностью контролируется Потребителем, который может отслеживать и сбрасывать значение смещения, чтобы Потребитель мог прочитать сообщение в любом месте.
Существует несколько соображений по поводу хранения журналов сообщений в виде разделов.Во-первых, это удобно для расширения в кластере.Каждый раздел можно настроить в соответствии с машиной, на которой он расположен, и тема может состоять из нескольких разделов, поэтому весь кластер может быть подходит для данных любого размера, второе — улучшить параллелизм, потому что его можно читать и записывать в единицах раздела.
Из приведенного выше введения мы можем узнать, что данные в kafka являются постоянными и отказоустойчивыми. Kafka позволяет пользователям устанавливать количество реплик для каждой темы.Количество реплик определяет, сколько брокеров будут хранить записанные данные. Если вы установите количество реплик равным 3, то часть данных будет храниться на 3 разных машинах, поэтому 2 машины могут выйти из строя. Обычно рекомендуется, чтобы количество реплик было не менее 2, чтобы гарантировать, что потребление данных не повлияет на увеличение, уменьшение или перезапуск компьютера. Если у вас более высокие требования к сохранению данных, вы можете установить количество реплик равным 3 или более.
Темы в Kafka хранятся в виде партиций.Каждой теме можно задать свое количество партиций.Количество партиций определяет количество сообщений, из которых состоит тема. Когда Producer создает данные, он публикует сообщения в каждом разделе темы в соответствии с определенными правилами (это правило можно настроить). Все реплики, упомянутые выше, находятся в разделах, но только одна реплика раздела будет выбрана в качестве ведущей для чтения и записи.
Факторы, которые следует учитывать при установке значения раздела.Раздел может использоваться только одним потребителем (потребитель может одновременно использовать несколько разделов), следовательно, если количество установленных разделов меньше количества потребителей, будут потребители, которые не могут потреблять данные. Поэтому рекомендуется, чтобы количество разделов превышало количество одновременно работающих потребителей. С другой стороны, рекомендуется, чтобы количество разделов было больше, чем количество брокеров кластера, чтобы лидер Разделы можно равномерно распределить между брокерами и, наконец, сделать балансировку нагрузки кластера. В Cloudera каждая тема состоит из сотен разделов. Следует отметить, что Kafka необходимо выделить часть памяти для каждого раздела для кэширования данных сообщений.Если количество разделов больше, для Kafka следует выделить больший объем кучи. 2.4 Способ хранения файлов в разделе![Kafka文件存储机制那些事]()
2.5 Структура хранения файлов сегментов в разделах Производитель отправляет сообщение в топик, и сообщение будет равномерно распределено по нескольким разделам (случайным образом или в соответствии с функцией обратного вызова, указанной пользователем), kafka Брокер получает сообщение и добавляет сообщение в последний сегмент соответствующего раздела.Когда количество сообщений в сегменте достигает настроенного значения или время публикации сообщения превышает пороговое значение, сообщения в сегменте будут сброшены на диск , а на диск будет сброшен только сброс. Потребитель сообщений можно только потреблять. После того, как сегмент достигнет определенного размера, он не будет записывать данные в сегмент, и брокер создаст новый сегмент.
Каждая часть соответствует индексу в памяти, записывающему смещение первого сообщения в каждом сегменте.
В каждом сегменте хранится много сообщений, и идентификатор сообщения определяется его логическим расположением, то есть идентификатор сообщения может быть непосредственно расположен в месте хранения сообщения, избегая дополнительного сопоставления идентификатора с местоположением.![Kafka文件存储机制那些事]()
![Kafka文件存储机制那些事]()
![Kafka文件存储机制那些事]()
2.6 Как найти сообщение по смещению в разделе
Kafka запишет смещение в zk. Однако частые записи в zk клиентским API zk — неэффективная операция. 0.8.2 kafka представляет собственное хранилище смещений, которое перемещает управление смещением из zk и может масштабироваться по горизонтали. Принцип заключается в использовании компактного из kafka Тема и смещение напрямую передаются в уплотненную тему с комбинацией группы потребителей, темы и раздела в качестве ключа. В то же время Kafka поддерживает триплет в памяти, чтобы поддерживать последнюю информацию о смещении, и когда потребитель приходит за получением последней информации о смещении, ее можно взять прямо в памяти. Конечно, kafka позволяет быстро сохранять последнюю информацию о смещении на диск.
3. Принцип репликации разделов
Алгоритм распределения копирования выглядит следующим образом:
4. Некоторые особенности Kafka Broker 4.1 Kafka Broker без сохранения состояния: 1. Брокер не имеет механизма копирования.После того, как брокер выйдет из строя, сообщения брокера будут недоступны. 2. Брокер не сохраняет статус подписчиков, а сохраняют его сами подписчики. 3. Удаление сообщений становится проблемой из-за безгражданства (сообщения, которые могут быть удалены, подписываются), Kafka принимает SLA на основе времени (гарантия уровня обслуживания), и сообщения будут удаляться после того, как они будут храниться в течение определенного периода. времени (обычно 7 дней). 4. Подписчики сообщений могут перематывать обратно в любое место для повторного использования.В случае сбоя подписчика они могут выбрать наименьшее смещение для повторного чтения сообщения потребления.
4.2 Доставка и жизненный цикл сообщения:1. Это не строго JMS, поэтому у kafka нет строгих требований к дублированию сообщений, потерям, ошибкам и типу последовательности.(Это самое большое отличие от AMQ)2. Kafka обеспечивает доставку по крайней мере один раз, то есть, когда потребитель выходит из строя, некоторые сообщения могут быть доставлены повторно. 3. Поскольку каждый раздел может использоваться только одним потребителем в группе потребителей, Kafka гарантирует, что сообщения в каждом разделе будут подписываться последовательно. 4. Kafka вычисляет проверку CRC для каждого сообщения для обнаружения ошибок.Сообщения, не прошедшие проверку CRC, будут отбрасываться напрямую.
4.3 Сжатие
Kafka поддерживает пакетную отправку сообщений. Исходя из этого, Kafka также поддерживает сжатие наборов сообщений. Производитель может сжимать наборы сообщений в формате GZIP или Snappy. После сжатия на стороне производителя его необходимо распаковать на стороне потребителя. Преимущество сжатия заключается в уменьшении объема передаваемых данных и уменьшении нагрузки на передачу по сети.При обработке больших данных узкое место часто отражается в сети, а не в ЦП.
Итак, как отличить, сжато сообщение или нет? Kafka добавляет в заголовок сообщения байт, описывающий атрибут сжатия. Последние два бита этого байта указывают кодировку, используемую для сжатия сообщения. Если последние два бита равны 0, то указывает что сообщение не сжато.
4.4 Надежность сообщения
В системе сообщений очень важно обеспечить надежность сообщений во время производства и потребления.В реальном процессе доставки сообщений могут возникнуть следующие три ситуации:
- не удалось отправить сообщение
- сообщение отправляется несколько раз
- Лучший случай: ровно один раз , сообщение было отправлено успешно и только один раз
Существует множество систем, которые заявляют, что реализуются ровно один раз, но игнорируют ситуации, когда производители или потребители могут выйти из строя во время производства и потребления. Например, хотя источник успешно отправляет сообщение, но сообщение теряется во время отправки или успешно отправляется брокеру, оно также успешно извлекается потребителем, но потребитель не может обработать полученное сообщение.
Со стороны Producer: этим занимается Kafka. Когда сообщение отправлено, Producer будет ждать, пока брокер успешно получит ответ на сообщение (время ожидания можно контролировать с помощью параметров). Если сообщение потеряно в пути или в одном из брокеры зависают, Producer повторно отправляет (мы знаем, что у Kafka есть механизм резервного копирования, которым можно управлять с помощью параметров, чтобы дождаться получения сообщений всеми резервными узлами).
Со стороны потребителя: как упоминалось ранее о разделе, сторона брокера записывает значение смещения в разделе, которое указывает на следующее сообщение, которое потребитель собирается использовать. Когда Потребитель получает сообщение, но зависает во время обработки, Потребитель может повторно найти предыдущее сообщение через это значение смещения, а затем обработать его. Потребитель также имеет право управлять этим значением смещения и произвольно обрабатывать сообщения, сохраняемые на стороне брокера.
4.5 Механизм резервного копирования
Механизм резервного копирования — это новая функция версии Kafka0.8, и появление механизма резервного копирования значительно повышает надежность и стабильность кластера Kafka. Благодаря механизму резервного копирования Kafka позволяет узлам в кластере зависать, не затрагивая весь кластер. Кластер резервного номера N допускает отказ N-1 узла. Во всех узлах резервного копирования есть узел в качестве узла LEAD, который сохраняет списки других узлов резервного копирования и поддерживает синхронизацию между отдельными резервными копиями. Ниже объясняется механизм резервного копирования Kafka:
![]()
4.6 Дизайн, связанный с эффективностью Kafka
4.6.1 Постоянство сообщенийKafka в значительной степени полагается на файловую систему для хранения и кэширования сообщений (данные AMQ сохраняются в базе данных mysql), потому что диски обычно считаются медленными, что приводит к скептицизму в отношении конкурентоспособности структур сохранения. На самом деле, будет ли диск быстрым или медленным, зависит от того, как мы используем диск. Потому что скорость линейной записи на диск намного выше, чем скорость случайной записи. Линейные операции чтения и записи предсказуемы в большинстве сценариев приложений.4.6.2 Гарантия производительности с постоянным временемРаздел каждой темы - это большая папка с бесчисленным количеством маленьких сегментов папки, но раздел - это очередь, а элементы в очереди - это сегменты. При потреблении начните с 0-го сегмента, и новое сообщение существует. Последнее сообщение в очередь. Для сегмента это тоже очередь, элемент очереди — это сообщение, а соответствующий удаленный идентификатор — какое сообщение. При потреблении начинайте потребление с первого сообщения сегмента, а новое сообщение существует в конце сегмента.
Постоянные очереди для систем сообщений могут быть построены на чтении и добавлении в файл, точно так же, как решения для ведения журналов в целом. Его преимущество в том, что все операции выполняются за постоянное время, а операции чтения и записи не блокируют друг друга. Эта конструкция имеет большие преимущества в производительности: в конечном итоге производительность системы полностью не зависит от размера данных, и сервер может в полной мере использовать преимущества дешевых жестких дисков для предоставления эффективных служб обмена сообщениями.
На самом деле бесконечное увеличение дискового пространства без ущерба для производительности означает, что мы можем предоставить функции, недоступные обычным системам обмена сообщениями. Например, сообщения не удаляются сразу после использования, мы можем хранить эти сообщения в течение относительно длительного периода времени (например, недели).
5. Kafka производитель-потребитель Система сообщений обычно состоит из трех частей: производитель, потребитель и брокер.Производитель напишет сообщение брокеру, а потребитель прочитает сообщение от брокера.Различные реализации MQ Брокер будет другим, но суть Брокера заключается в том, чтобы отвечать за размещение сообщения в системе хранения сервера. Конкретные шаги заключаются в следующем:![]()
Рисунок 4-1 Взаимодействие клиента и сервера
5.1 Producers
Производители отправляют сообщения непосредственно в ведущий раздел на брокере без какого-либо посредника или другой маршрутной переадресации. Чтобы реализовать эту функцию, каждый брокер в кластере Kafka может ответить на запрос производителя и вернуть некоторую метаинформацию о теме, в том числе о том, какие машины активны, где находятся ведущие разделы темы и какие ведущие разделы находятся в к текущему этапу можно получить доступ напрямую.
Клиенты-производители сами контролируют, в какие разделы помещаются сообщения.Это может быть реализовано путем случайного распределения, реализации класса случайных алгоритмов балансировки нагрузки или указания некоторых алгоритмов разделения. Kafka предоставляет пользователям интерфейс для реализации пользовательских разделов. Пользователи могут указать partitionKey для каждого сообщения и использовать этот ключ для реализации некоторых алгоритмов разделения хеша. Например, если в качестве ключа раздела используется идентификатор пользователя, сообщения с таким же идентификатором пользователя будут отправляться в тот же раздел.
Пакетная отправка данных может значительно повысить эффективность обработки.Kafka Producer может накапливать сообщения в памяти до определенного числа и отправлять запросы в виде пакета. Количество пакетов может контролироваться параметрами производителя.Значение параметра может быть установлено на количество накопленных сообщений (например, 500), накопленный временной интервал (например, 100 мс) или размер накопленных данных (64 КБ). . Увеличивая размер пакета, можно уменьшить количество сетевых запросов и операций ввода-вывода на диск.Конечно, конкретные настройки параметров необходимо взвешивать с точки зрения эффективности и своевременности.
Производители могут отправлять сообщения в kafka асинхронно и параллельно, но обычно производитель получает будущий ответ после отправки сообщения, который возвращает значение смещения или ошибку, возникшую в процессе отправки. Есть очень важный параметр "acks", определяющий запрос производителя на лидера Количество реплик, которые раздел получил подтверждение. Если количество подтверждений равно 0, это означает, что производитель не будет ждать ответа брокера. Следовательно, производитель не может знать, успешно ли отправлено сообщение, что может приведет к потере данных, но в то же время значение acks равное 0 позволит получить максимальную пропускную способность системы.
Если для acks установлено значение 1, это означает, что производитель получит подтверждение от посредника, когда ведущий раздел получит сообщение, что будет иметь большую надежность, поскольку клиент будет ждать, пока посредник не подтвердит получение сообщения. Если установлено значение -1, производитель получит подтверждение от брокера, когда все разделы резервного копирования получат сообщение, этот параметр может получить максимальную гарантию надежности.
Сообщения Kafka состоят из заголовка фиксированной длины и массива байтов переменной длины. Поскольку сообщения Kafka поддерживают массивы байтов, Kafka может поддерживать любой пользовательский формат серийных номеров или другие существующие форматы, такие как Apache Avro, protobuf и т. д. Kafka не ограничивает размер отдельного сообщения, но мы рекомендуем, чтобы размер сообщения не превышал 1 МБ, обычно до того, как размер общего сообщения составит 1~10 КБ.
При публикации сообщения клиент kafka сначала создает сообщение и добавляет сообщение в набор сообщений (Kafka поддерживает пакетную публикацию, вы можете добавить несколько сообщений в набор сообщений и опубликовать его в одной строке), при отправке сообщения производитель Клиенту необходимо указать тему, к которой относится сообщение.
5.2 ConsumersKafka предоставляет два набора потребительских API, разделенных на высокоуровневый API и API-интерфейс образца. Sample-api — это низкоуровневый API, который поддерживает соединение с одним брокером, и этот API полностью не имеет состояния, и в каждом запросе нужно указывать значение смещения, поэтому этот API также является наиболее гибким.
В kafka значение смещения того сообщения, которое читается в данный момент, поддерживается потребителем., поэтому потребитель может решить, как читать данные в kafka.Например, потребитель может повторно использовать уже использованные данные, сбросив значение смещения. Независимо от того, используются они или нет, Kafka будет сохранять данные в течение определенного периода времени. Этот период времени можно настроить. Только по истечении срока действия Kafka удалит данные. (Это отличается от AMQ, сообщения AMQ обычно сохраняются в mysql, а использованные сообщения будут удалены)
Высокоуровневый API инкапсулирует доступ к ряду брокеров в кластере и может прозрачно использовать тему. Он сам поддерживает состояние потребляемых сообщений, то есть каждый раз потребляется следующее сообщение.
Высокоуровневый API также поддерживает потребление тем в форме групп.Если потребители имеют одинаковое имя группы, то Kafka эквивалентна службе сообщений очереди, и каждый потребитель потребляет данные в соответствующем разделе сбалансированным образом. Если у потребителей разные имена групп, то kafka эквивалентна широковещательному сервису, который рассылает все сообщения в теме каждому потребителю.
API высокого уровня и API низкого уровня предназначены для потребителя и не имеют ничего общего с производителем.
API высокого уровня заключается в том, что выпускной раздел, прочитанный потребителем, хранятся на зоофильтере. API высокого уровня начнет очередной поток для автоматического синхронизации выключения для Zookeeper через регулярные промежутки времени. Другими словами, если используется API высокого уровня, каждое сообщение может быть прочитано только один раз, и после чтения сообщения не имеет значения, не имеет значения, будет ли обработка моей потребителями или нет. Высокий Другая поток API уровня автоматически синхронизирует Office + 1 к зоофирку. Если возникает проблема с потребителем, чтением данных, Offsite также будет синхронизирован на зоопакере. Следовательно, если потребительская обработка не удалась, она будет продолжаться следующим. Это часто неправильное поведение. Следовательно, лучшая практика заключается в том, чтобы напрямую позволить всему исключительному исключению всей потребительской группы заканчиваться после завершения после завершения обработки потребителей, но последняя часть чтения данных теряется, потому что офсиат в зоофире был +1. Ждать, чтобы начать Conusmer снова При группировке он уже начал читать и обрабатывать с следующего.
Низкоуровневый API — это внешний сайт раздела, читаемый потребителем и поддерживаемый в собственной программе потребителя. Не будет синхронизирован с zookeeper. Однако для удобства мониторинга kafka manager обычно синхронизируется с zookeeper вручную. Преимущество этого в том, что, как только потребитель сообщения не сможет прочитать, внешний сайт этого сообщения поддерживается нами, и мы не будем +1. При следующем перезапуске вы начнете читать с этого оффсайта. Это можно сделать точно раз гарантирует точность данных.
Для группы потребителей: 1. Разрешить группе потребителей (включая нескольких потребителей, таких как кластер, потребляющий одновременно) использовать тему, а различным группам потребителей использовать независимо. 2. Чтобы уменьшить затраты на распределенную координацию между различными потребителями в группе потребителей, укажите раздел как наименьшую единицу параллельного потребления, то есть потребители в группе могут использовать только разные разделы.
![]()
Отношения между потребителем и разделом: - Если потребителей больше, чем разделов, это пустая трата, потому что дизайн kafka не допускает параллелизма на разделе, поэтому количество потребителей не должно быть больше, чем количество разделов - Если потребителей меньше, чем разделов, потребитель будет соответствовать Для нескольких разделов количество потребителей и разделов в основном распределяется здесь разумно, иначе данные в разделах будут выбираться неравномерно. - Если потребитель читает данные из нескольких разделов, порядок между данными не гарантируется.Кафка гарантирует только то, что данные упорядочены в одном разделе, но несколько разделов будут отличаться в зависимости от порядка чтения Брокер и раздел вызовут перебалансировку, поэтому раздел, соответствующий потребителю, изменится после перебалансировки - когда данные не могут быть получены из высокоуровневого интерфейса, он будет заблокирован.
В случае низкой нагрузки каждый поток может потреблять несколько разделов. Но когда нагрузка высока, Потребитель Лучше всего, чтобы количество потоков соответствовало количеству разделов. Если вы все еще не можете потреблять его, вы должны снова запустить процесс Consumer.Количество потоков в процессе также совпадает с количеством разделов.
При использовании сообщений клиенту kafka необходимо указать тему и номер раздела (каждый раздел соответствует логическому потоку журнала, например, раздел представляет линейку продуктов, а раздел представляет результат сегментации журнала линейки продуктов по дням). подписывается, он будет итеративно читать сообщения.Если сообщений нет, клиент-потребитель будет блокироваться до тех пор, пока не будет опубликовано новое сообщение. Потребитель может накапливать и подтверждать полученные сообщения. Когда он подтверждает сообщение определенного смещения, это означает, что предыдущее сообщение также было успешно получено. В это время брокер обновит смещение на zookeeper. реестр.
5.3 Эффективная передача данных 1. Издатель может публиковать несколько сообщений одновременно (добавляя сообщения в набор сообщений для публикации), а потребитель потребляет одно сообщение за итерацию.
6. Kafka и Zookeeper 6.1 Контроль координации Zookeeper 1. Управление динамическим присоединением и выходом брокеров и потребителей. (Производителем не нужно управлять, любой компьютер может отправить сообщение Kakfa Broker в качестве производителя) 2. Запустить балансировку нагрузки, когда брокер или потребитель присоединяется или уходит, будет запущен алгоритм балансировки нагрузки, так что несколько потребителей в балансировка нагрузки потребления группы потребителей. (Поскольку потребитель использует один или несколько разделов, раздел может использоваться только одним потребителем)
1. Предисловие Производительность очереди сообщений может быть хорошей или плохой, а структура ее механизма хранения файлов является одним из наиболее важных показателей для измерения технического уровня службы очереди сообщений. Далее будет проанализировано, как Kafka обеспечивает эффективное хранение файлов и его практическое применение с точки зрения механизма хранения файлов и физической структуры Kafka.
1.1 Особенности Кафки:- Высокая пропускная способность и низкая задержка: Kafka может обрабатывать сотни тысяч сообщений в секунду, а ее задержка составляет всего несколько миллисекунд.Каждая тема может быть разделена на несколько разделов, и группа потребителей использует разделы. - Масштабируемость: кластер kafka поддерживает горячее расширение - Постоянство и надежность: сообщения сохраняются на локальных дисках, а резервное копирование данных поддерживается для предотвращения потери данных - Отказоустойчивость: допускается сбой узлов в кластере (если количество реплик равно n, сбой узла n-1) — высокий параллелизм: поддержка тысяч клиентов для одновременного чтения и записи
1.2 Сценарии использования Кафки:- Сбор журналов: компания может использовать Kafka для сбора журналов различных сервисов и открывать их различным потребителям через Kafka в виде сервисов с унифицированным интерфейсом, таких как hadoop, Hbase, Solr и т. д. - Система обмена сообщениями: развязка и производителей и потребителей, кеширование сообщений и т.д. - Отслеживание активности пользователей: Kafka часто используется для записи различных действий веб-пользователей или пользователей приложений, таких как просмотр веб-страниц, поиск, клики и т. д. Эта информация об активности публикуется каждым сервером в теме kafka, а затем подписчиками. подпишитесь на эти действия, подписавшись на эту тему действий для мониторинга и анализа в режиме реального времени, или загрузите его в хауоп или хранилище данных для автономного анализа и анализа. - Операционные показатели: Kafka также часто используется для записи данных оперативного мониторинга. Это включает в себя сбор данных из различных распределенных приложений и создание централизованной обратной связи для различных операций, таких как сигналы тревоги и отчеты. - Потоковая передача: как искровая потоковая передача и шторм - источник событий
1.3 Идея дизайна Какфы - Выборы лидера Kafka Broker:Кластер Kakfa Broker управляется Zookeeper. Все узлы Kafka Broker отправляются в Zookeeper для регистрации временного узла, потому что Kafka только один. Брокер зарегистрируется успешно, а другие потерпят неудачу, поэтому брокер Kafka, который успешно зарегистрирует временный узел в Zookeeper, станет контроллером брокера Kafka, а другие брокеры Kafka называются последователями брокера Kafka. (Этот процесс вызывает контроллер для регистрации Watch в ZooKeeper). Этот контроллер будет отслеживать всю информацию о других брокерах Kafka.Если контроллер брокера Kafka выйдет из строя, временный узел на zookeeper исчезнет, и все брокеры Kafka исчезнут. Брокер отправится в Zookeeper, чтобы вместе зарегистрировать временный узел, потому что только один брокер Kafka зарегистрируется успешно, а остальные потерпят неудачу, поэтому брокер Kafka, который успешно зарегистрирует временный узел в Zookeeper, станет контроллером брокера Kafka, а другой брокер Kafka брокеров называют последователями Kafka Broker. Например: когда брокер не работает, контроллер брокера kafka прочитает состояние всех разделов на отключенном брокере на zookeeper и выберет реплику в списке ISR в качестве раздела. лидер (если все реплики в списке ISR отключены, выберите уцелевшую реплику в качестве лидера; если все реплики в разделе отключены, установите для нового лидера значение -1, дождитесь восстановления и подождите, пока любая из реплик ISR "живет" и выбирает его в качестве лидера; или выбирает первую "живую" реплику (не обязательно в ISR) в качестве лидера), когда брокер выходит из строя, контроллер kafka также уведомляет zookeeper, zookeeper Он уведомляет другие kafka брокеры.Здесь произошла ошибка, когда TalkingData использует Kafka0.8.1, после успешной регистрации контроллера кафки на Zookeeper время тайм-аута для связи с Zookeeper составляет 6 с, то есть, если контроллер кафки не бьется с Zookeeper через 6 с, то Zookeeper думает, что контроллер кафки сдох, она удалит временную ноду на Zookeeper, тогда другая кафка подумает, что контроллера больше нет, и бросится регистрировать временную ноду заново, а та кафка, что зарегистрировалась успешно Брокер становится контроллером, а затем предыдущему контроллеру kafka нужны различные отключения, чтобы закрыть мониторинг различных узлов и событий. Однако, когда трафик чтения и записи kafka очень велик, ошибка TalkingData заключается в том, что из-за сети и других причин контроллер kafka и Zookeeper не имеют связи в течение 6 с, поэтому новый контроллер kafka переизбирается, но исходный контроллер находится в выключенном состоянии всегда безуспешно.В настоящее время сообщение от производителя связано с наличием двух kafkas в кластере Kafka. контроллер и не может приземлиться. привести к стагнации данных. Раньше здесь была ошибка,Когда TalkingData использует Kafka0.8.1, когда ack=0, это означает, что производитель отправляет сообщение.Пока сообщение получено соответствующим лидером раздела брокера kafka, производитель возвращает успех, независимо от раздела Действительно ли лидер успешно сохранил сообщение в kafka. Когда акк=1,Указывает, что производитель отправляет сообщение, синхронно сохраняет сообщение лидеру раздела, соответствующему теме, а затем производитель возвращает сообщение об успешном выполнении, а лидер раздела асинхронно синхронизирует сообщение с другими репликами раздела. Когда ack=все или -1, Указывает, что производитель отправляет сообщение и синхронно сохраняет сообщение лидеру раздела соответствующей темы и соответствующей реплике, а затем возвращает успех. Но если некоторыеkafka controller При переключении это приведет к переключению лидера раздела (старый Лидер раздела на контроллере kafka будет избран другим брокерам kafka.), но это приведет к потере данных. - Группа потребителей:Каждый потребитель (потребитель нить) может сформировать группу (Consumer нить) группа), каждое сообщение в перегородке может потребляться только одного потребителя (потребитель нить) в группе (группы потребителей), если сообщение может потребляться несколькими потребителями (потребитель нить), то эти потребители должны быть в разных группах. Кафка не поддерживает сообщения в разделении обрабатываются двумя или более потребительских потоков под одной и той же группы потребителей, если не будет запущена новая группа потребителей. Так что если вы хотите, чтобы потреблять тему одновременно запустить несколько потребителей Группа хорошо, но следует отметить, что потребление нескольких потребителей здесь должно быть последовательным чтением сообщений в разделе. По умолчанию вновь начал потребитель начинает блокировать сообщение чтения из последнего места на голове из очередь разделов. Он не может использовать экспрессы в качестве потребителей взаимоисключающего (для обновления пессимистических блокировок) одновременно обрабатывать сообщения , как Amq. Это происходит потому , что , когда экспрессы потребляют данные в очереди, необходимо обеспечить , чтобы несколько потоков не может принять такое же сообщение А, так что требуется пессимизм на уровне строк (для обновления), что приводит к снижению производительности и потреблению недостаточной пропускной способности. Для того, чтобы обеспечить пропускную способность, Кафка позволяет только один и тот же потребитель Потребитель нить под группой получает доступ к разделу. Если вы чувствуете, что эффективность не высока, вы можете увеличить количество разделов, в горизонтальном направлении, а затем добавить новый потребительский поток, чтобы потреблять. Если вы хотите использовать несколько различных предприятий нуждаются в данных по этой теме, вы можете создать несколько групп потребителей. Каждый читает сообщения последовательно, а значения вне сайта не влияют друг на друга. Таким образом, нет никакой конкуренции замка, горизонтальная масштабируемость используются полностью, а пропускная способность чрезвычайно высок. Это также формирует концепцию распределенного потребления. При запуске группы потребителей не потреблять тему, независимо от того, сколько разделов не в теме, независимо от того, если наш потребитель Сколько потребительских потоки настроены в группе, все потребительские потоки в рамках этой группы потребителей будут потреблять все разделы, даже если есть только один поток-потребитель в этой группе потребителей, то этот поток-потребитель будет потреблять все разделы. Таким образом, оптимальная конструкция такова, что количество потребительских потоков по группам потребителей, равно числу разбиений, так что эффективность является самым высоким. Сообщение из того же раздела может использоваться только одним и тем же Потребителя Потребитель, в потребляет группу. Несколько потребителей в группе потребителей не может потреблять раздел одновременно. Под группой потребителей, независимо от того, сколько потребителей есть, потребитель группа должна вернуться и потреблять все разделы по этой теме. Когда число потребителей в группе потребителей меньше, чем число разделов по этой теме, как показано на следующем рисунке GroupA, GroupB, потребитель поток будет потреблять несколько разделов. Короче говоря, разделы по данной теме будет потребляться. если Когда число потребителей в группе потребителей, равно числу разбиений по этой теме, как показано в группе С, как показано ниже, эффективность является самым высоким в это время, и каждый раздел имеет потребительскую нить к потреблению. Когда число потребителей в группе потребителей больше, чем число разделов по этой теме, как показано на GroupD, как показано ниже, будет потребитель поток простаивает. Поэтому, когда мы создали группу потребителей, нам нужно только указать количество потребителей в нем. Там нет необходимости указывать соответствующий раздел потребления серийный номер, и потребитель будет автоматически восстановить равновесие. Потребители под несколькими группами потребителей могут потреблять такое же сообщение, но этот вид потребления также читает сообщения, чтобы потребить в пути O (1), так что эта партия сообщений, безусловно, будет потребляться неоднократно, не столько, сколько Amq. BET потребляется в качестве потребителя (заблокировать сообщение, и не может потреблять сообщение несколько раз, когда потребление) -Условия запуска потребительской перебалансировки:(1) Добавление или удаление Потребителя вызовет Перебалансировку Группы Потребителей (2) Увеличение или уменьшение Брокера вызовет Потребительское перебалансирование -Потребитель:Когда Потребитель обрабатывает сообщение в разделе, оно читается в порядке O(1). Следовательно, необходимо хранить вне сайта информацию о том, где она была прочитана в последний раз. Для API высокого уровня смещение хранится в Zookeeper, а смещение API низкого уровня поддерживается само по себе. Вообще говоря, используются API высокого уровня. Гарантия доставки потребителя, по умолчанию выполняется фиксация после прочтения сообщения, а затем обработка сообщения, автофиксация по умолчанию имеет значение true, в это время фиксация обновит внешний сайт + 1. После сбоя обработки внешний сайт был +1, и сообщение в это время будет потеряно; он настроен на чтение обработки сообщения и последующую фиксацию. В этом случае ответ стороны потребителя будет относительно медленным, и ему нужно дождаться завершения обработки. При нормальных обстоятельствах для обработки сообщения темы должна быть группа потребителей. Наилучшая практика заключается в том, что количество потребителей в группе потребителей равно количеству разделов в теме, поэтому эффективность является самой высокой, и один поток-потребитель обрабатывает один раздел. Если количество потребителей в группе потребителей меньше, чем количество партиций в топике, будет поток-потребитель, обрабатывающий несколько партиций одновременно (это автоматический механизм кафки, нам не нужно указывать), а короче все разделы в этой теме будут обработаны на оф. . если этот потребитель Количество потребителей в группе больше, чем количество разделов в топике, лишний поток-потребитель будет бездействовать и ничего не делать, а остальная часть - это поток-потребитель для обработки раздела, что приводит к пустой трате ресурсов, т.к. раздел невозможен. Обрабатывается двумя потоками-потребителями. Поэтому в наших распределенных онлайн-сервисах с несколькими сервисами количество потребителей кафки в каждом сервисе меньше, чем количество разделов соответствующей темы, но количество потребителей всех сервисов равно только количеству разделов, это потому, что услуга распределенного обслуживания Все потребители исходят от одного потребителя группа, если она исходит из разных групп потребителей, будут обработаны повторяющиеся сообщения (потребители из одной группы потребителей не могут обрабатывать один и тот же раздел, а разные группы потребителей могут обрабатывать одну и ту же тему, поэтому сообщения обрабатываются последовательно, и дубликаты будут обрабатываться Да, как правило, в этом случае используются две разные бизнес-логики, чтобы запустить две группы потребителей для обработки темы).
Если трафик производителя увеличивается, количество разделов текущей темы = количеству потребителей.В это время метод ответа заключается в расширении: увеличение раздела под темой и увеличение потребителей в группе потребителей.
- Тема и раздел:Тема эквивалентна очереди очереди в традиционной системе сообщений MQ.Сообщение, отправляемое производителем, должно указывать, в какую тему оно отправляется, но не нужно указывать, какой раздел находится в теме, потому что kafka загрузит полученное сообщение. Баланс, равномерно распределенный по разным разделам по данной теме ( хеш(сообщение) % [количество брокеров] ). Физически эта тема разделена на один или несколько разделов, и каждый раздел эквивалентен подочереди. С точки зрения физической структуры, каждый раздел соответствует физическому каталогу (папке), а имя папки — [topicname]_[partition]_[серийный номер]. Тема может иметь бесконечное количество разделов, в зависимости от бизнес-требований и объем данных. В конфигурационном файле kafka параметр num.partitions может быть выше в любой момент, чтобы настроить количество разделов для смены темы, в Укажите количество разделов через параметры при создании темы. После создания темы количество разделов также можно изменить с помощью инструментов, предоставляемых Kafka. Вообще говоря, (1) количество разделов темы больше или равно количеству брокеров, что может повысить пропускную способность. (2) Реплика одного и того же раздела должна быть максимально распределена по разным машинам для обеспечения высокой доступности. При добавлении нового раздела, сообщение в партиции не будет перераспределено, данные сообщения в исходной партиции не изменятся, вновь добавленная партиция сначала будет пустой, а затем сообщение, попадающее в эту тему, будет переучастие в загрузке всех партиций остаток средств -Реплика раздела:Каждый раздел может хранить реплики на других узлах брокера kafka, поэтому отказ узла брокера kafka не повлияет на кластер kafka. Способ хранения копий реплик — хранить их в порядке брокеров kafka. Например, есть 5 узлов брокера kafka, тема имеет 3 раздела, и каждый раздел хранит 2 реплики, затем раздел 1 хранит брокера1, брокер2, а раздел2 хранит брокер2, брокер3. . . и так далее(Количество реплик не может быть больше, чем kafka Количество узлов брокера, иначе будет сообщено об ошибке. Количество реплик здесь - это фактически общее количество копий раздела, включая лидера, а остальные копии). Это, если брокер находится в центре города, вся кафка данных все еще завершена. Тем не менее, тем выше количество репликаций, тем более стабильна, но он возвращается к снижению ресурсов и производительности; если копия реплики меньше, она также приведет к риску данных потери системы. (1) Как передать сообщение: PRODUCTER PREWER Отправить сообщение в лидер раздела, а затем отправить его на другие разделы по лидеру Последователь. (Если продукт отправляется на каждую реплику, которое слишком медленно) (2) Вам необходимо гарантировать, сколько реплик получили это сообщение перед отправкой ACK производителю: в зависимости от количества ACKS (3) Как иметь дело с Replica Не работаю: если реплика разбиения этого отдела находится не в списке ACK, продюсер отправляется в лидер разбиения, и лидер раздела отправляет сообщение для последователя раздела без ответа. Это не повлияет на всю систему. В чем проблема Отказ Если это не работает раздел Реплика в списке ACK Media будет ждать, пока сообщение будет успешно написать сообщение, но ждать до появления времени, а затем вернуться к неисправности, потому что реплика раздела в списке ACK не отвечает, в это время кафка будет автоматически Удалите реплику разделов из этого раздела из списка ACK и не будут иметь реплику раздела в этом списке ACK при отправке сообщения. Быть (4) Как разобраться с неудачной репликами восстановления: если эта реплика раздела не находится в списке ACK, то повторно отправил управление зооздателем после запуска, то лидер продукта будет продолжать отправлять сообщение на этот раздел Foliwer. Если эта реплика раздела ранее находится в списке ACK, вам нужно будет добавить реплику этого раздела в список ACK. (Список ACK вручную добавляется и раздел определенной работы. Удалить из списка ACK, когда реплика) -Лидер и последователь раздела:Разделы также делятся на лидеров и последователей. Лидер — это основной раздел.Когда производитель пишет Kafka, он сначала записывает лидера раздела, а затем лидер раздела отправляет его другим последователям раздела. Информация о лидере и ведомом разделе контролируется Zookeeper, как только раздел Узел брокера, на котором находится лидер, не работает, и zookeeper выберет ведомого, чтобы он стал лидером раздела в последователях разделов других брокеров. -Алгоритм темы по назначению разделов и реплик разделов:(1) Отсортируйте брокера (размер = n) и выделяемый раздел. (2) Назначить i-й раздел (i%n)-му брокеру. (3) Назначить j-ю реплику i-го раздела ((i + j) %n) у брокеров
- Надежность доставки сообщенийСообщение, как добиться успеха, Kafka предусматривает три режима: - первый неудобный, при отправке он успешен, эта ситуация не может гарантировать успех сообщения Брокеру; - второй - Модель Master-Slave, только когда Мастер и все ведомые получают сообщения, эта модель обеспечивает высочайшую надежность доставки, но ухудшает производительность; - Третья модель, то есть до тех пор, пока мастер подтверждает, пожалуйста, успех; при фактическом использовании, в соответствии с характеристиками приложения, в большинстве случаев третья модель нейтрализуется и надежностью и производительностью Надежность сообщения находится на Брокере, потому что сообщение будет длиться на диске, поэтому, если нормальный Стоп является Брокером, данные на нем не теряются; но если не нормальный, СТОП может сделать представление страницы кеш для записи сообщения сообщение Потеряно, это можно настроить, настроив цикл очистки кеша страницы, порог снижен, но та же частая запись на диски повлияет на производительность, и вопрос выбора, который настраивается в соответствии с реальной ситуацией . Надежность потребления сообщений Kafka обеспечивает модель «По крайней мере один раз», потому что ход чтения сообщения обеспечивается смещением, и смещение может поддерживаться потребителями, но оно может поддерживаться в ZooKeeper, но когда потребление сообщения, потребитель виснет, OFFSET пишется не сразу, возможен повтор чтения, который тоже можно настроить на коммиты. Цикл OFFSET, снижение порога и даже потребители делают свое потребление и совершают смещение решения транзакции, но если ваше приложение не заботится о повторном потреблении, то вы просто не решаете его для обмена наибольшей производительностью.
- Подтверждение раздела:Когда ack=1, это означает, что после того, как производитель успешно записал лидер раздела, брокер возвращает успех, независимо от того, успешно ли записываются другие последователи раздела. Когда ack=2, это означает, что производитель успешно записывает лидера раздела и еще одного последователя, Брокер возвращает успех, независимо от того, успешно ли записываются другие последователи раздела. Когда ack=-1[количество разделов], это означает, что он успешен только тогда, когда все производители успешно записаны, а брокер kafka возвращает информацию об успехе.Здесь следует отметить, что если ack=1, как только брокер выходит из строя и вызывает переключение ведомого и ведущего раздела, данные будут потеряны.
- статус сообщения: в Kafka состояние сообщения хранится в потребителе, брокеру все равно, какое сообщение потребляется и кто его потребляет, и записывает только значение смещения (указывающее на следующую позицию сообщения в разделе, который будет потребляться), Это означает, что если потребитель плохо справляется с этим, сообщение брокера может быть использовано несколько раз. -сохранение сообщения: сообщение Kafka будет сохраняться в локальной файловой системе и поддерживать очень высокую эффективность o (1). Мы все знаем, что производительность чтения операций ввода-вывода является очень ресурсоемкой и медленной, что часто является узким местом для баз данных при вводе-выводе, поэтому необходимо изменить причины SSD. Но Kafka обладает высокой пропускной способностью MQ, но может быть очень эффективным сохранением сообщений в файле. Это связано с тем, что Kafka o представляет собой временную сложность последовательности записи (1), очень быструю. Причина в высокой пропускной способности. Из-за постоянного написания сообщения записываются по порядку, поэтому, когда сообщение должно быть потреблено, чтобы быть потребленным, чтобы обеспечить разделение порядка потребления сообщений. Общие машины, одиночные 100k данных в секунду. -срок действия сообщения: Kafka будет хранить сообщения в нем в течение длительного времени, чтобы потребитель мог использовать его несколько раз, конечно, многие детали настраиваются. -Produer :Производитель отправляет сообщение в тему без указания раздела, просто отправляет его напрямую. Kafka использует подтверждение раздела для проверки успешности передачи и возвращает информацию производителю.Производитель может иметь любое количество потоков, и серверу Kafka все равно. Доставка на стороне производителя гарантия по умолчанию по крайней мере один раз. Вы также можете настроить производителя на асинхронную отправку, чтобы достичь не более одного раза. Производитель может реализовать ровно один раз с идемпотентностью первичного ключа -Кафка высокая пропускная способность: высокая пропускная способность Kafka отражается на чтении и записи. Распределенное параллельное чтение и запись выполняются очень быстро. Производительность записи отражается в последовательной записи с временной сложностью O(1). Производительность чтения отражается в последовательном чтении с временной сложностью O(1), разделении темы, а поток потребления в группе потребления может выполнять последовательное чтение с высокой производительностью. - Гарантия доставки Kafka (гарантия доставки сообщений): (1) Максимум один раз сообщения могут быть потеряны и никогда не будут повторно переданы; (2) Хотя бы один раз сообщения никогда не будут потеряны, но могут быть переданы повторно; (3) Ровно один раз Каждая порция информации обязательно будет передана один и только один раз, чего и хочет пользователь. -Массовая рассылка: Kafka поддерживает пакетную отправку в единицах наборов сообщений для повышения эффективности push-уведомлений. -push-and-pull: Производитель и потребитель в Kafka используют режим push-and-pull, то есть производитель только отправляет сообщения брокеру, а потребитель только извлекает сообщения от брокера, а производство и потребление сообщений являются асинхронными. -Связь между брокерами в кластере Kafka: Это не отношения "ведущий-ведомый". Каждый брокер имеет одинаковый статус в кластере. Мы можем добавить или удалить любой узел брокера по желанию. -балансировки нагрузки: Кафка предоставляет API метаданных управляет нагрузкой между брокерами (для Kafka 0.8.x, для 0.7.x в основном используется zookeeper для достижения балансировки нагрузки). -Синхронный Асинхронный: Производитель использует асинхронный метод push, который значительно повышает пропускную способность системы Kafka (синхронный или асинхронный метод можно контролировать с помощью параметров). -Перегородка механизма перегородки: сторона брокера Kafka поддерживает раздел раздела сообщений, производитель может решить, в какой раздел отправить сообщение, в разделе Порядок сообщений — это порядок, в котором источник отправляет сообщения.В теме может быть несколько разделов, и количество конкретных разделов настраивается. Концепция разделения позволяет Kafka масштабироваться горизонтально как MQ с огромной пропускной способностью. Раздел может установить реплику-копию.Реплика-копия существует на разных узлах брокера kafka.Первый раздел является ведущим, а остальные – последователями.Сообщение сначала записывается в лидер раздела, а затем отправляется в раздел разделом лидер. последователь. Поэтому кафка может расширяться по горизонтали, то есть расширять партицию. -Автономная загрузка данных: Kafka также очень подходит для загрузки данных в Hadoop или хранилища данных благодаря поддержке масштабируемого сохранения данных. -Данные в реальном времени и автономные данные:Kafka поддерживает как автономные данные, так и данные в реальном времени, поскольку сообщения Kafka сохраняются в файлах, и можно установить период действия, поэтому Kafka можно использовать в качестве эффективного хранилища и использовать в качестве автономных данных для последующего анализа. Конечно, как распределенная система сообщений в реальном времени, она по-прежнему используется для обработки данных в реальном времени в большинстве случаев, но когда потребительская мощность снижается, данные могут накапливаться в Kafka за счет сохраняемости сообщения. -Поддержка плагинов: сейчас многие активные сообщества разработали множество плагинов для расширения функций Kafka, таких как плагины, относящиеся к Storm, Hadoop и flume. -разъединение: эквивалент MQ, выполнение асинхронных операций между производителем и потребителем и разъединение между системами. избыточность: Реплика имеет несколько копий, чтобы гарантировать, что весь сервис не пострадает, если узел брокера выйдет из строя.Расширяемость: Узлы брокера можно масштабировать по горизонтали, разделы также можно увеличивать по горизонтали, а реплики разделов также можно увеличивать по горизонтали —вершина горы: в случае резкого увеличения трафика кафка масштабируется по горизонтали, а приложениям все равно нужно продолжать функционировать - возмещаемость: Когда часть системы выходит из строя, это не повлияет на всю систему из-за реплики копии раздела. -гарантия заказа: поскольку производитель Kafka пишет сообщения, а читающие сообщения потребители представляют собой последовательное чтение и запись, гарантируется эффективная производительность. -буфер: Так как бизнес производителя может быть очень простым, в то время как back-end бизнес потребителя будет очень сложным и иметь операции с базой данных, то производитель должен быть быстрее, чем потребитель.Если нет кафки, производитель напрямую вызывает потребителя , что приведет к сбою всей системы. Скорость обработки низкая. Добавление слоя Kafka в качестве MQ может играть роль буферизации. -Асинхронная связь: как MQ, Producer взаимодействует с Consumer асинхронно.
2. Механизм хранения файлов Kafka
2.1 Некоторые термины у Кафки объясняются следующим образом:Объект, опубликованный и подписанный в Kafka, называется топиком. Мы можем создать топик для каждого типа данных и назвать клиента, который публикует сообщения в топике, производителем, а клиент, который подписывается на топик, называется потребителем. Производители и потребители могут читать и записывать данные из нескольких тем одновременно. Кластер Kafka состоит из одного или нескольких серверов-брокеров, которые отвечают за сохранение и резервное копирование определенных сообщений Kafka.
- Broker: узел Kafka, узел kafka является брокером, несколько брокеров могут образовывать кластер Kafka.
- Topic: тип сообщения, каталог, в котором хранится сообщение, является темой, например, журнал просмотра страниц, журнал кликов и т. д., может существовать в виде тем, а кластер Kafka может отвечать за распределение нескольких тем. в то же время.
- Partition: Физическая группировка тем, тема может быть разделена на несколько разделов, каждый раздел представляет собой упорядоченную очередь
- Segment: Раздел физически состоит из нескольких сегментов, в каждом сегменте хранится информация о сообщении.
- Producer: производственное сообщение отправляется в тему
- Consumer: подпишитесь на тему, чтобы использовать сообщение, потребитель потребляет как поток
-
Consumer Group: Группа потребителей содержит несколько потребителей, предварительно настроенных в файле конфигурации. Каждый потребитель (поток-потребитель) может образовывать группу (группа-потребитель), каждое сообщение в разделе может потребляться только одним потребителем (поток-потребитель) в группе (группа-потребитель), если сообщение может потребляться несколькими потребителями (группа-потребитель). поток) ) потребления, то эти потребители должны быть в разных группах. Kafka не поддерживает сообщения в разделе от двух или более потребителей.
потока для обработки, даже из разных групп потребителей. Он не может обрабатывать сообщения с несколькими BET как потребители, такие как AMQ. Это связано с тем, что когда несколько BET потребляют данные в очереди, необходимо убедиться, что несколько потоков не могут принять одно и то же сообщение, поэтому требуется пессимизм на уровне строк (для обновления). , что приводит к снижению производительности потребления и недостаточной пропускной способности. Чтобы обеспечить пропускную способность, Kafka позволяет только одному потребительскому потоку обращаться к одному разделу. Если вы чувствуете, что эффективность не высока, вы можете увеличить количество разделов для расширения по горизонтали, а затем добавить новый потребитель
нить для потребления. Таким образом, отсутствует конкуренция блокировок, полностью используется горизонтальная масштабируемость, а пропускная способность чрезвычайно высока. Это также формирует концепцию распределенного потребления.
- 2.2 Некоторые принципы и концепции кафки
2. ПроизводительностьПомимо дискового ввода-вывода, нам также необходимо учитывать сетевой ввод-вывод, который напрямую связан с пропускной способностью kafka.Kafka не предоставляет слишком много превосходных навыков; для стороны производителя сообщение может быть буферизовано, когда сообщение Когда число достигает определенного порога, оно отправляется брокеру пакетами, то же самое верно и для стороны потребителя, и несколько сообщений извлекаются пакетами.Однако размер тома сообщений можно указать через файл конфигурации. Со стороны брокера kafka кажется, что есть системный вызов sendfile, который потенциально может улучшить производительность сетевого ввода-вывода: сопоставить данные файла с системной памятью, и сокет может напрямую считывать соответствующую область памяти без необходимости процесс копирования и повторного обмена (это включает в себя «дисковые данные ввода-вывода» / «память ядра» / «память процесса» / «сетевой буфер», копирование данных между несколькими). На самом деле, для производителя/потребителя/брокера затраты ЦП должны быть небольшими, поэтому включение механизма сжатия сообщений является хорошей стратегией; сжатие требует небольшого количества ресурсов ЦП, но для kafka сетевой ввод-вывод должен требовать больше. сообщение, передаваемое по сети, может быть сжато.Kafka поддерживает несколько методов сжатия, таких как gzip/snappy.
3. Балансировка нагрузки: любой брокер в кластере kafka может предоставить производителю метаданные, в том числе «список серверов, оставшихся в кластере»/«разделы». «Список лидеров» и другая информация (см. информацию об узле в zookeeper). Когда производитель получает информацию о метаданных, производитель будет поддерживать сокетные соединения со всеми лидерами разделов в теме; сообщение отправляется непосредственно производителем в брокера через сокет, минуя средний уровень Любой «уровень маршрутизации» Асинхронная отправка, буферизация нескольких сообщений на стороне клиента и отправка их брокеру пакетами; слишком много операций ввода-вывода для небольших данных замедляет общую задержку в сети , а пакетная отложенная отправка на самом деле повышает эффективность сети, но это также таит в себе определенные скрытые опасности, например, когда производитель выходит из строя, те сообщения, которые не были отправлены, будут потеряны.
4. Для других JMS-реализаций модели Topic место потребления сообщений резервируется поставщиком, чтобы избежать повторной отправки сообщений или повторной отправки сообщений, которые не были успешно использованы, и т. д., а также контролировать состояние сообщения. , Это требует, чтобы JMS-брокер требовал слишком много дополнительных В kafka сообщения в разделе потребляются только одним потребителем, и нет контроля состояния сообщения и сложного механизма подтверждения сообщений. Сторона довольно легкая. Когда сообщение получено потребителем, потребитель может локально сохранить смещение последнего сообщения и периодически регистрировать смещение в zookeeper. Видно, что клиент-потребитель также очень легкий. Потребитель в kafka отвечает за ведение записей о потреблении сообщений, в то время как брокер не заботится об этом.Этот дизайн не только повышает гибкость на стороне потребителя, но и умеренно снижает сложность дизайна на стороне брокера; это отличается от многих JMS prodivers. Кроме того, дизайн сообщения ACK в kafka также сильно отличается от JMS. Сообщение в kafka отправляется потребителю пакетами (обычно в единицах количества сообщений или размера куска), и когда сообщение успешно обработано, сообщение отправляется в zookeeper.offset, без доставки ACK брокеру.Возможно, вы поняли, что этот "свободный" дизайн будет иметь риск "потерянных" сообщений/"повторной отправки сообщения".
5. Согласованная передача сообщений Kafka обеспечивает 3 вида семантики согласованности передачи сообщений: не более одного раза, не менее одного раза и ровно один раз. Минимум 1 раз: данные могут передаваться повторно, и данные могут обрабатываться повторно; максимум 1 раз: может произойти потеря данных; ровно 1 раз: это не значит, что они передаются только один раз, но есть механизм. Убедитесь, что нет ситуаций «дублирования данных» и «потеря данных».
не более одного раза: потребитель извлекает сообщение, затем сохраняет смещение, а затем обрабатывает сообщение; после того, как клиент сохраняет смещение, но процесс-потребитель дает сбой (сбой) в процессе обработки сообщения, что приводит к сбою некоторых сообщений для продолжения обработки Затем другие потребители могут взять на себя управление, но, поскольку смещение было сохранено заранее, новый потребитель не сможет получить сообщения до смещения (хотя они и не были обработаны), т. е. хотя бы один раз: потребитель извлекает сообщение, затем обрабатывает сообщение, а затем сохраняет смещение. сбой при сохранении операции смещения, что приводит к следующему, когда вы снова получаете, вы можете получить сообщение, которое было обработано в последний раз, то есть «хотя бы один раз». В сценарии «кластера Kafka» потребителю Для получения семантики непротиворечивости «ровно один раз» может быть принята следующая схема: К выходу потребителя дополнительно добавляется не менее 1 раза + максимальное количество обработанных сообщений: Ввиду существования максимального количества обработанных сообщений будет не допускать повторной обработки сообщений.
6. В replica kafka стратегия репликации основана на партиции, а не топике, кафка реплицирует данные каждой партиции на несколько серверов, любая партиция имеет одного лидера и несколько фолловеров (может и не быть), количество бэкапов можно передать через конфигурацию брокера файл для установки. Лидер обрабатывает все запросы на чтение-запись, а ведомый должен синхронизироваться с ведущим.Последователь как «потребитель», потребляющий сообщения и сохраняющий их в локальном журнале;лидер отвечает за отслеживание состояния всех последователи, если последователь слишком сильно «отстает» или терпит неудачу, лидер удалит его из списка синхронизации реплик.Когда все последователи успешно сохраняют сообщение, сообщение считается «зафиксированным», и тогда потребитель может его использовать. Эта стратегия синхронизации требует последователей. Между ней и лидером должна быть хорошая сетевая среда.Даже если выживет только один экземпляр реплики, нормальная отправка и получение сообщений все еще может быть гарантирована, пока выживает кластер zookeeper. При выборе ведомого необходимо учитывать одну проблему, а именно количество лидеров разделов, уже перенесенных на новый сервер-лидер.Если на сервере слишком много лидеров разделов, это означает, что этот сервер будет выдерживать большую нагрузку ввода-вывода. Для лидера необходимо учитывать «балансировку нагрузки», и брокер с меньшим количеством лидеров разделов с большей вероятностью станет новым лидером.
7. Формат каждой записи журнала: «4-байтовое число N представляет длину сообщения» + «N байтов содержимого сообщения», каждый журнал имеет смещение для уникальной маркировки сообщения, значение смещения 8-байтовое число, указывающее начальную позицию этого сообщения в этом разделе. Каждый раздел имеет несколько журналов на уровне физического хранилища. Состав файла (называемый сегментом). Файл сегмента называется "минимальное смещение".kafka. Например, "00000000000.kafka", где "минимальное смещение" представляет собой смещение начального сообщения в этом сегменте. При получении сообщения необходимо указать смещение и Максимальный размер чанка, смещение используется для указания начальной позиции сообщения, размер чанка используется для указания общей длины максимально полученного сообщения (косвенно указывает количество сообщений).Согласно смещению , вы можете найти файл сегмента, в котором находится сообщение, а затем в соответствии с сегментом взять разницу минимального смещения, получить его относительное положение в файле и напрямую прочитать вывод.
8. Распределенная kafka использует zookeeper для хранения некоторой метаинформации и использует механизм наблюдения zookeeper для обнаружения изменений в метаинформации и выполнения соответствующих действий (таких как сбой потребителя, запуск балансировки нагрузки и т. д.) Реестр узла брокера: Когда брокер kafka запускается, он сначала регистрирует информацию о своем узле (временный znode) в zookeeper, а когда брокер и zookeeper отключаются, znode также будет удален. регистрирует свою собственную тему и разделяет информацию, которая по-прежнему является временным znode.Группа потребителей и потребителей: при создании каждого клиента-потребителя он регистрирует свою собственную информацию в zookeeper; эта функция в основном предназначена для «балансировки нагрузки».A Несколько потребителей в группа может использовать все разделы темы в шахматном порядке; короче говоря, убедитесь, что все разделы этой темы могут быть использованы этой группой, и для соображений производительности разделы относительно равномерно распределены между каждым на потребителе. Реестр идентификаторов потребителей: каждый потребитель имеет уникальный идентификатор (хост: uuid, который может быть указан в файле конфигурации или сгенерирован системой), и этот идентификатор используется для пометки информации о потребителе.Отслеживание смещения потребителя: используется для отслеживания каждого потребителя. наибольшее смещение в используемом в данный момент разделе. Этот znode является постоянным узлом. Видно, что смещение связано с group_id, что указывает на то, что при сбое одного потребителя в группе другие потребители могут продолжать потреблять. Реестр владельца раздела: Используется для обозначения того, какой потребитель потребляет раздел. Этот узел выражает, что «раздел» может быть использован только следующим потребителем в группе, и когда потребитель в группе выйдет из строя, будет запущена балансировка нагрузки (т. Разделы потребителей) Когда потребитель запускается, инициируемые операции: A) Сначала выполните «Реестр идентификаторов потребителей»; B) Затем зарегистрируйте часы в узле «Реестр идентификаторов потребителей», чтобы отслеживать «выход» и «выход» других потребителей. в текущей группе "присоединиться"; пока этот znode Изменения в списке узлов под путем вызовут балансировку нагрузки потребителей в этой группе (например, если потребитель выйдет из строя, другие потребители займут разделы). C) В узле «Реестр идентификаторов брокера» зарегистрируйте следите за выживанием брокера; если список брокеров изменится, это вызовет перебалансировку потребителей во всех группах.
Резюме: 1) Сторона производителя использует zookeeper для «обнаружения» списка брокеров и каждого раздела в разделе «Тема». Лидер устанавливает подключение к сокету и отправляет сообщения. 2) Сторона брокера использует zookeeper для регистрации информации о брокере и отслеживает выживание лидера раздела. 3) Сторона потребителя использует zookeeper для регистрации информации о потребителе, включая список разделов, потребляемых потребителями. и т. д., а также используется для обнаружения списка посредников, установления соединения через сокет с лидером раздела и получения сообщений.
9. Выбор лидера Ядром Kafka является лог-файл, а синхронизация лог-файла в кластере — это самый базовый элемент распределенной системы данных. Нам не нужны последователи, если лидеры никогда не уходят! Как только лидер вышел из строя, необходимо выбрать нового лидера среди последователей.Однако сами последователи могут слишком долго задерживаться или давать сбои, поэтому в качестве лидера необходимо выбрать высококачественного последователя.Должно быть гарантировано, что сообщение представлен, лидер отключен, вновь избранный лидер должен быть в состоянии предоставить это сообщение. В большинстве распределенных систем для выбора нового лидера используется метод мажоритарного голосования.При мажоритарном методе голосования наиболее подходящий лидер выбирается динамически в соответствии со статусом всех узлов реплики.Кафка не использует этот метод. Kafka динамически поддерживает набор синхронизированных реплик (сокращенно ISR), узлы в этом наборе в высокой степени согласованы с лидером, и любое сообщение должно быть прочитано каждым членом набора.После того, как узел прочитает и добавит в журнал , он уведомляет внешнюю среду о том, что сообщение отправлено. Таким образом, любой узел в этом наборе может быть выбран лидером в любое время.ISR поддерживается в ZooKeeper. Если в ISR есть узлы f+1, то разрешено предоставлять услуги в обычном режиме без потери сообщений при выходе из строя f узлов. Члены ISR являются динамическими. Если узел удаляется, он может снова присоединиться к ISR, когда снова достигнет состояния «синхронизации». Этот метод выбора лидера очень быстр и подходит для сценариев приложений Kafka. Дурная идея: что, если все узлы не работают? Гарантия Kafka на то, что данные не будут потеряны, основана на том, что по крайней мере один узел находится в рабочем состоянии.Если все узлы не работают, это не может быть гарантировано. В практических приложениях, когда все реплики не работают, они должны реагировать вовремя. Есть два варианта: 1. Подождать, пока любой узел в ISR восстановится и станет ведущим. 2. Выберите первый восстановленный узел среди всех узлов (а не только ISR) в качестве лидера Это компромисс между доступностью и непрерывностью. Если вы дождетесь восстановления узлов в ISR, после отказа узлов в ISR или исчезновения данных кластер никогда не восстановится. Если вы дождетесь неожиданного восстановления узла ISR, данные этого узла будут использоваться как онлайн-данные, которые могут отличаться от реальных данных, поскольку некоторые данные могут быть не синхронизированы. В настоящее время Kafka выбирает вторую стратегию, в будущих версиях выбор этой стратегии будет настраиваемым и может гибко подбираться по сценарию. С этой дилеммой сталкивается не только Кафка, но и почти все распределенные системы данных.
10. Управление репликами В приведенном выше обсуждении в качестве примера рассматривается только одна тема и один раздел, но на самом деле Kafka будет управлять тысячами разделов темы.Kafka пытается сделать все разделы равномерно распределенными по всем узлам в кластере вместо того, чтобы концентрироваться на некоторых узлы, и постарайтесь максимально сбалансировать отношения master-slave, чтобы каждая точка служила лидером определенной доли раздела.Также очень важно оптимизировать процесс выбора лидера, который определяет пустое окно период, когда система выходит из строя, как долго. Kafka выбирает узел в качестве "контроллера". Когда узел оказывается неработоспособным, он отвечает за выбор нового лидера среди всех узлов плавающего раздела, что позволяет Kafka эффективно управлять отношениями ведущий-ведомый всех узлов раздела. партиями. если контроллер вниз, один из активных узлов переключится на новый контроллер.
11. Синхронизация лидера и реплики Для раздела «посредник», сохраняющий положительный раздел, является «лидером» раздела, а «посредник», сохраняющий резервный раздел, является «последователем» раздела. Резервный раздел полностью скопирует сообщения положительного раздела, включая дополнительные значения атрибутов, такие как номер сообщения. Чтобы сохранить согласованность содержимого положительного раздела и резервного раздела, решение, принятое Kafka, состоит в том, чтобы запустить процесс-потребитель для потребления на «брокере», который сохраняет резервный раздел, чтобы содержимое положительного раздела было согласовано. с содержимым резервного раздела. Как правило, раздел имеет один «положительный раздел» и ноль или более «резервных разделов». Можно настроить общее количество «положительных разделов + резервных разделов».Для этой конфигурации разные темы могут иметь разные значения конфигурации. Обратите внимание, что производители и потребители общаются только с «лидером», который держит положительный раздел.
Kafka позволяет разделам темы иметь несколько реплик.Это число можно настроить.Вы можете настроить количество реплик для каждой темы. Kafka автоматически создает резервную копию данных на каждой реплике, поэтому данные по-прежнему доступны, когда узел выходит из строя. Функция копирования Kafka необязательна, вы можете настроить только одну копию, что фактически эквивалентно только одной копии данных. Единицей для создания реплик является раздел топика. У каждого раздела есть лидер и ноль или более последователей. Все операции чтения и записи обрабатываются лидером. Как правило, количество разделов намного больше, чем количество брокеров. лидер каждой секции Равномерно распределяется между брокерами. Все последователи копируют журнал лидера, а сообщения и порядок в журнале такие же, как и в лидере. Последователи получают сообщения от лидера, как обычные потребители, и сохраняют их в своих собственных файлах журналов. Многие распределенные системы обмена сообщениями автоматически обрабатывают неудачные запросы, и у них есть четкое определение того, жив ли узел. Кафка определяет, жив узел или нет. Есть два условия: 1. Узел должен иметь возможность поддерживать соединение с ZooKeeper. , Zookeeper проверяет соединение каждой ноды через механизм heartbeat 2. Если нода является ведомой, она должна иметь возможность синхронизировать операцию записи лидера по времени, и задержка не должна быть слишком большой. условия должны быть точно «синхронизированы (синхронизированы)», а не расплывчато говорить «активен» или «сбой».Лидер будет отслеживать все «синхронизированные» узлы, как только один из них выйдет из строя, застрял или задерживается слишком долго. это долго,лидер удалит.Что касается того,насколько задержка "слишком большая",то определяется параметром replica.lag.max.messages.Что застрял и как параметр replica.lag. time.max .ms решил. Только когда сообщение добавляется в журнал всеми репликами, оно считается «зафиксированным», и только зафиксированное сообщение будет отправлено потребителю, так что не нужно беспокоиться о потере сообщения после ухода лидера. вниз. Производитель также может выбрать, ждать ли уведомления о том, что сообщение отправлено, что определяется параметром acks. Kafka гарантирует, что пока существует «синхронизирующий» узел, «зафиксированные» сообщения не будут потеряны.
-
2.3 Топология Кафки
Процесс анализа делится на следующие 4 шага:
- Распределение хранения разделов в теме
- Способ хранения файлов в разделе (раздел представляет собой каталог (папку) на linux-сервере)
- Структура хранения файлов сегментов в разделе
- Как найти сообщение по смещению в разделе
Благодаря подробному анализу вышеупомянутых 4 процессов мы можем ясно понять тайну механизма хранения файлов kafka.
2.3 Распределение хранения разделов в теме
Предполагая, что в кластере Kafka в экспериментальной среде есть только один брокер, xxx/message-folder является корневым каталогом хранилища файлов данных, а конфигурация файла server.properties (параметр log.dirs=xxx/message-folder) в например, брокер Kafka создает два имени темы. Это report_push и launch_info соответственно, а количество разделов — partitions=4.
Путь хранения и правила каталога:
xxx/message-folder
|--report_push-0|--report_push-1
|--report_push-2
|--report_push-3
|--launch_info-0
|--launch_info-1
|--launch_info-2
|--launch_info-3
В файловом хранилище Kafka есть несколько разных разделов в одной и той же теме, каждый раздел представляет собой каталог, правило именования разделов — это имя раздела + порядковый номер, первый номер раздела начинается с 0, а максимальное число — это количество разделов минус количество разделов 1. Когда сообщение отправляется, оно отправляется в тему, которая по сути является каталогом, а тема состоит из нескольких разделов.Его организационная структура показана на следующем рисунке:
Мы видим, что Раздел представляет собой структуру Очереди, сообщения в каждом Разделе упорядочены, создаваемые сообщения постоянно добавляются к Разделу, и каждому сообщению присваивается уникальное значение смещения.
Кластер Kafka сохранит все сообщения, независимо от того, используются они или нет;Мы можем установить время истечения срока действия сообщения, и только просроченные данные будут автоматически очищены, чтобы освободить место на диске.Например, если мы установим время истечения сообщения на 2 дня, то все сообщения в течение этих 2 дней будут сохраняться в кластере, а данные будут очищаться только в том случае, если оно превышает два дня.
Kafka поддерживает только значение смещения в разделе, потому что это смещение определяет, сообщение какого раздела потребляется. Каждый раз, когда потребитель потребляет сообщение, смещение увеличивается на 1. На самом деле состояние сообщения полностью контролируется Потребителем, который может отслеживать и сбрасывать значение смещения, чтобы Потребитель мог прочитать сообщение в любом месте.
Существует несколько соображений по поводу хранения журналов сообщений в виде разделов.Во-первых, это удобно для расширения в кластере.Каждый раздел можно настроить в соответствии с машиной, на которой он расположен, и тема может состоять из нескольких разделов, поэтому весь кластер может быть подходит для данных любого размера, второе — улучшить параллелизм, потому что его можно читать и записывать в единицах раздела.
Из приведенного выше введения мы можем узнать, что данные в kafka являются постоянными и отказоустойчивыми. Kafka позволяет пользователям устанавливать количество реплик для каждой темы.Количество реплик определяет, сколько брокеров будут хранить записанные данные. Если вы установите количество реплик равным 3, то часть данных будет храниться на 3 разных машинах, поэтому 2 машины могут выйти из строя. Обычно рекомендуется, чтобы количество реплик было не менее 2, чтобы гарантировать, что потребление данных не повлияет на увеличение, уменьшение или перезапуск компьютера. Если у вас более высокие требования к сохранению данных, вы можете установить количество реплик равным 3 или более.
Темы в Kafka хранятся в виде партиций.Каждой теме можно задать свое количество партиций.Количество партиций определяет количество сообщений, из которых состоит тема. Когда Producer создает данные, он публикует сообщения в каждом разделе темы в соответствии с определенными правилами (это правило можно настроить). Все реплики, упомянутые выше, находятся в разделах, но только одна реплика раздела будет выбрана в качестве ведущей для чтения и записи.
Факторы, которые следует учитывать при установке значения раздела.Раздел может использоваться только одним потребителем (потребитель может одновременно использовать несколько разделов), следовательно, если количество установленных разделов меньше количества потребителей, будут потребители, которые не могут потреблять данные. Поэтому рекомендуется, чтобы количество разделов превышало количество одновременно работающих потребителей. С другой стороны, рекомендуется, чтобы количество разделов было больше, чем количество брокеров кластера, чтобы лидер Разделы можно равномерно распределить между брокерами и, наконец, сделать балансировку нагрузки кластера. В Cloudera каждая тема состоит из сотен разделов. Следует отметить, что Kafka необходимо выделить часть памяти для каждого раздела для кэширования данных сообщений.Если количество разделов больше, для Kafka следует выделить больший объем кучи. 2.4 Способ хранения файлов в разделе
- Каждый раздел (каталог) эквивалентен гигантскому файлу и равномерно распределен на несколько сегментов (сегментов) файлов данных одинакового размера. Однако количество сообщений в каждом файле сегментов не обязательно одинаково, что облегчает быстрое удаление старых файлов сегментов.
- Каждый раздел должен поддерживать только последовательное чтение и запись, а жизненный цикл файла сегмента определяется параметрами конфигурации сервера.
Преимущество этого заключается в том, что он может быстро удалять ненужные файлы и эффективно улучшать использование диска.
2.5 Структура хранения файлов сегментов в разделах Производитель отправляет сообщение в топик, и сообщение будет равномерно распределено по нескольким разделам (случайным образом или в соответствии с функцией обратного вызова, указанной пользователем), kafka Брокер получает сообщение и добавляет сообщение в последний сегмент соответствующего раздела.Когда количество сообщений в сегменте достигает настроенного значения или время публикации сообщения превышает пороговое значение, сообщения в сегменте будут сброшены на диск , а на диск будет сброшен только сброс. Потребитель сообщений можно только потреблять. После того, как сегмент достигнет определенного размера, он не будет записывать данные в сегмент, и брокер создаст новый сегмент.
Каждая часть соответствует индексу в памяти, записывающему смещение первого сообщения в каждом сегменте.
- Состав файла сегмента: он состоит из двух основных частей, а именно файла индекса и файла данных. Эти два файла соответствуют друг другу и появляются парами. Суффиксы ".index" и ".log" представляют файл индекса сегмента и файл данных. соответственно.
- Правила именования файлов сегментов: первый сегмент глобального сегмента начинается с 0, а имя каждого последующего файла сегмента соответствует максимальному смещению (номер сообщения смещения) предыдущего глобального сегмента. Максимальное значение — 64-разрядная длина, 19-разрядный символ, и никакие цифры не дополняются нулями.
В каждом сегменте хранится много сообщений, и идентификатор сообщения определяется его логическим расположением, то есть идентификатор сообщения может быть непосредственно расположен в месте хранения сообщения, избегая дополнительного сопоставления идентификатора с местоположением.
Следующий список файлов представляет собой эксперимент, проведенный автором на брокере Kafka.Создайте темуXXX, содержащую 1 раздел, установите размер каждого сегмента на 500 МБ и запустите производителя для записи большого объема данных в брокер Kafka.Сегмент список файлов показан ниже на рисунке 2. выше 2 правила:
Взяв в качестве примера пару файлов файлов сегментов на рис. 2 выше, физическую структуру соответствующей связи между индексом файлом данных в сегменте можно описать следующим образом:
Индекс файла на фиг. 3 хранит большое количество метаданных, файл данных хранит большое количество сообщений, а файл индекса направлен на физический адрес смещения сообщения в соответствующем файле данных. Метаданные 3,497 в файле индекса являются примером, в свою очередь, в файле данных, в файле данных третье сообщение представлено в файле данных (в Global Partiton, представляющем сообщение 36872), и физический адрес смещения сообщения составляет 497.
На фиг.3 из файла данных сегмента, состоящего из ряда сообщений, следует следующее подробное описание физической структуры следующего сообщения:
Описание параметра:
| ключевые слова | объяснять |
|---|---|
| 8 byte offset | Каждое сообщение в партиции (partition) имеет упорядоченный идентификационный номер, который называется смещением (offset), который может однозначно определять положение каждого сообщения в партиции (partition). которыйoffset указывает номер сообщения раздела |
| 4 byte message size | размер сообщения |
| 4 byte CRC32 | Проверьте сообщение с помощью crc32 |
| 1 байт "магия" | Указывает номер версии протокола сервисной программы Kafka, выпущенной на этот раз. |
| 1 байт "атрибуты" | Указывает на автономную версию или определяет тип сжатия или тип кодирования. |
| 4 byte key length | Указывает длину ключа, когда ключ равен -1, поле ключа K byte не заполняется |
| K byte key | по желанию |
| value bytes payload | Представляет фактические данные сообщения. |
2.6 Как найти сообщение по смещению в разделе
Например, чтобы прочитать сообщение со смещением=368776, вам нужно найти его, выполнив следующие два шага.
-
Первый шаг — найти файл сегмента
В качестве примера возьмем рисунок 2 выше, где 00000000000000000000.index представляет первый файл, а начальное смещение (offset) равно 0. Начальное смещение объема сообщений второго файла 000000000000000368769.index равно 368770 = 368769 + 1. Аналогично, начальное смещение третьего файла 00000000000000737337.index равно 737338=737337 + 1, другие последующие файлы и т. д., назовите и отсортируйте эти файлы в соответствии с начальным смещением, пока список файлов ищется в соответствии со смещением **двоичный поиск ** , вы можете быстро найти конкретный файл.
Когда offset=368776, найдите 00000000000000368769.index|log
-
Второй шаг — найти сообщение в файле сегмента.Первый шаг — найти файл сегмента.Когда offset=368776, он находится, в свою очередь, по физическому расположению метаданных 000000000000000368769.index и физическому адресу смещения 000000000000000368769. log, а затем через 00000000000000368769.log Поиск последовательно до смещения=368776.
Kafka запишет смещение в zk. Однако частые записи в zk клиентским API zk — неэффективная операция. 0.8.2 kafka представляет собственное хранилище смещений, которое перемещает управление смещением из zk и может масштабироваться по горизонтали. Принцип заключается в использовании компактного из kafka Тема и смещение напрямую передаются в уплотненную тему с комбинацией группы потребителей, темы и раздела в качестве ключа. В то же время Kafka поддерживает триплет в памяти, чтобы поддерживать последнюю информацию о смещении, и когда потребитель приходит за получением последней информации о смещении, ее можно взять прямо в памяти. Конечно, kafka позволяет быстро сохранять последнюю информацию о смещении на диск.
3. Принцип репликации разделов
Особенности конструкции эффективного хранилища файлов Kafka
- Kafka делит большой файл раздела в теме на несколько небольших файловых сегментов.С помощью нескольких небольших файловых сегментов легко периодически очищать или удалять использованные файлы и уменьшать использование диска.
- Информация индекса может быстро найти сообщение и определить максимальный размер ответа.
- Сопоставляя все метаданные индекса с памятью, можно избежать операций ввода-вывода с файлом сегмента.
- За счет разреженного хранения индексных файлов пространство, занимаемое метаданными индексных файлов, может быть значительно уменьшено.
1. Репликация раздела кластера Kafka автоматически выделяется и анализируется по умолчанию.
Ниже приведен пример 4 брокеров в кластере Kafka, создающих 1 тему, содержащую 4 раздела и 2 репликации; поток данных Producer показан на рисунке:
(1)
(2) Когда к кластеру добавляются 2 узла и количество разделов увеличивается до 6, распределение выглядит следующим образом:
Логические правила размещения реплик следующие:
- В кластере Kafka у каждого брокера есть возможность поровну распределить лидера раздела.
- В вышеприведенном Разделе Брокера стрелка указывает на копию, взяв Раздел-0 в качестве примера: Раздел-0 в Брокере1 является Лидером, а Раздел-0 в Брокере2 является копией.
- Каждый из вышеописанных видов Брокера ФПГ (упорядоченный в соответствии с BrokerId) последовательно распределяет Мастер Раздела, копию следующего Брокера, таким образом распределяя итерации цикла, множественные копии следуют этому правилу.
Алгоритм распределения копирования выглядит следующим образом:
- N Брокеру будут выделены все и i-й раздел сортировки.
- Назначьте i-й раздел (i mod n)-му Брокеру.
- Назначьте j-ю реплику i-го Раздела ((i + j) mod n)-му Брокеру.
4. Некоторые особенности Kafka Broker 4.1 Kafka Broker без сохранения состояния: 1. Брокер не имеет механизма копирования.После того, как брокер выйдет из строя, сообщения брокера будут недоступны. 2. Брокер не сохраняет статус подписчиков, а сохраняют его сами подписчики. 3. Удаление сообщений становится проблемой из-за безгражданства (сообщения, которые могут быть удалены, подписываются), Kafka принимает SLA на основе времени (гарантия уровня обслуживания), и сообщения будут удаляться после того, как они будут храниться в течение определенного периода. времени (обычно 7 дней). 4. Подписчики сообщений могут перематывать обратно в любое место для повторного использования.В случае сбоя подписчика они могут выбрать наименьшее смещение для повторного чтения сообщения потребления.
4.2 Доставка и жизненный цикл сообщения:1. Это не строго JMS, поэтому у kafka нет строгих требований к дублированию сообщений, потерям, ошибкам и типу последовательности.(Это самое большое отличие от AMQ)2. Kafka обеспечивает доставку по крайней мере один раз, то есть, когда потребитель выходит из строя, некоторые сообщения могут быть доставлены повторно. 3. Поскольку каждый раздел может использоваться только одним потребителем в группе потребителей, Kafka гарантирует, что сообщения в каждом разделе будут подписываться последовательно. 4. Kafka вычисляет проверку CRC для каждого сообщения для обнаружения ошибок.Сообщения, не прошедшие проверку CRC, будут отбрасываться напрямую.
4.3 Сжатие
Kafka поддерживает пакетную отправку сообщений. Исходя из этого, Kafka также поддерживает сжатие наборов сообщений. Производитель может сжимать наборы сообщений в формате GZIP или Snappy. После сжатия на стороне производителя его необходимо распаковать на стороне потребителя. Преимущество сжатия заключается в уменьшении объема передаваемых данных и уменьшении нагрузки на передачу по сети.При обработке больших данных узкое место часто отражается в сети, а не в ЦП.
Итак, как отличить, сжато сообщение или нет? Kafka добавляет в заголовок сообщения байт, описывающий атрибут сжатия. Последние два бита этого байта указывают кодировку, используемую для сжатия сообщения. Если последние два бита равны 0, то указывает что сообщение не сжато.
4.4 Надежность сообщения
В системе сообщений очень важно обеспечить надежность сообщений во время производства и потребления.В реальном процессе доставки сообщений могут возникнуть следующие три ситуации:
- не удалось отправить сообщение
- сообщение отправляется несколько раз
- Лучший случай: ровно один раз , сообщение было отправлено успешно и только один раз
Существует множество систем, которые заявляют, что реализуются ровно один раз, но игнорируют ситуации, когда производители или потребители могут выйти из строя во время производства и потребления. Например, хотя источник успешно отправляет сообщение, но сообщение теряется во время отправки или успешно отправляется брокеру, оно также успешно извлекается потребителем, но потребитель не может обработать полученное сообщение.
Со стороны Producer: этим занимается Kafka. Когда сообщение отправлено, Producer будет ждать, пока брокер успешно получит ответ на сообщение (время ожидания можно контролировать с помощью параметров). Если сообщение потеряно в пути или в одном из брокеры зависают, Producer повторно отправляет (мы знаем, что у Kafka есть механизм резервного копирования, которым можно управлять с помощью параметров, чтобы дождаться получения сообщений всеми резервными узлами).
Со стороны потребителя: как упоминалось ранее о разделе, сторона брокера записывает значение смещения в разделе, которое указывает на следующее сообщение, которое потребитель собирается использовать. Когда Потребитель получает сообщение, но зависает во время обработки, Потребитель может повторно найти предыдущее сообщение через это значение смещения, а затем обработать его. Потребитель также имеет право управлять этим значением смещения и произвольно обрабатывать сообщения, сохраняемые на стороне брокера.
4.5 Механизм резервного копирования
Механизм резервного копирования — это новая функция версии Kafka0.8, и появление механизма резервного копирования значительно повышает надежность и стабильность кластера Kafka. Благодаря механизму резервного копирования Kafka позволяет узлам в кластере зависать, не затрагивая весь кластер. Кластер резервного номера N допускает отказ N-1 узла. Во всех узлах резервного копирования есть узел в качестве узла LEAD, который сохраняет списки других узлов резервного копирования и поддерживает синхронизацию между отдельными резервными копиями. Ниже объясняется механизм резервного копирования Kafka:
4.6 Дизайн, связанный с эффективностью Kafka
4.6.1 Постоянство сообщенийKafka в значительной степени полагается на файловую систему для хранения и кэширования сообщений (данные AMQ сохраняются в базе данных mysql), потому что диски обычно считаются медленными, что приводит к скептицизму в отношении конкурентоспособности структур сохранения. На самом деле, будет ли диск быстрым или медленным, зависит от того, как мы используем диск. Потому что скорость линейной записи на диск намного выше, чем скорость случайной записи. Линейные операции чтения и записи предсказуемы в большинстве сценариев приложений.4.6.2 Гарантия производительности с постоянным временемРаздел каждой темы - это большая папка с бесчисленным количеством маленьких сегментов папки, но раздел - это очередь, а элементы в очереди - это сегменты. При потреблении начните с 0-го сегмента, и новое сообщение существует. Последнее сообщение в очередь. Для сегмента это тоже очередь, элемент очереди — это сообщение, а соответствующий удаленный идентификатор — какое сообщение. При потреблении начинайте потребление с первого сообщения сегмента, а новое сообщение существует в конце сегмента.
Постоянные очереди для систем сообщений могут быть построены на чтении и добавлении в файл, точно так же, как решения для ведения журналов в целом. Его преимущество в том, что все операции выполняются за постоянное время, а операции чтения и записи не блокируют друг друга. Эта конструкция имеет большие преимущества в производительности: в конечном итоге производительность системы полностью не зависит от размера данных, и сервер может в полной мере использовать преимущества дешевых жестких дисков для предоставления эффективных служб обмена сообщениями.
На самом деле бесконечное увеличение дискового пространства без ущерба для производительности означает, что мы можем предоставить функции, недоступные обычным системам обмена сообщениями. Например, сообщения не удаляются сразу после использования, мы можем хранить эти сообщения в течение относительно длительного периода времени (например, недели).
5. Kafka производитель-потребитель Система сообщений обычно состоит из трех частей: производитель, потребитель и брокер.Производитель напишет сообщение брокеру, а потребитель прочитает сообщение от брокера.Различные реализации MQ Брокер будет другим, но суть Брокера заключается в том, чтобы отвечать за размещение сообщения в системе хранения сервера. Конкретные шаги заключаются в следующем:
-
Клиентское приложение-производитель выдает сообщение:
- Объект подключения клиента упаковывает сообщение в запрос и отправляет его на сервер.
- В записи сервера также есть объект подключения, отвечающий за получение запроса и сохранение сообщения в виде файла.
- Сервер возвращает результат ответа производителю-клиенту.
-
Клиентское приложение-потребитель использует сообщение:
- Объект подключения клиента также упаковывает информацию о потреблении в запрос и отправляет ее на сервер.
- Сервер извлекает сообщение из файловой системы хранения
- Сервер возвращает результат ответа клиенту-потребителю.
- Клиент восстанавливает ответ на сообщение и начинает обработку сообщения
5.1 Producers
Производители отправляют сообщения непосредственно в ведущий раздел на брокере без какого-либо посредника или другой маршрутной переадресации. Чтобы реализовать эту функцию, каждый брокер в кластере Kafka может ответить на запрос производителя и вернуть некоторую метаинформацию о теме, в том числе о том, какие машины активны, где находятся ведущие разделы темы и какие ведущие разделы находятся в к текущему этапу можно получить доступ напрямую.
Клиенты-производители сами контролируют, в какие разделы помещаются сообщения.Это может быть реализовано путем случайного распределения, реализации класса случайных алгоритмов балансировки нагрузки или указания некоторых алгоритмов разделения. Kafka предоставляет пользователям интерфейс для реализации пользовательских разделов. Пользователи могут указать partitionKey для каждого сообщения и использовать этот ключ для реализации некоторых алгоритмов разделения хеша. Например, если в качестве ключа раздела используется идентификатор пользователя, сообщения с таким же идентификатором пользователя будут отправляться в тот же раздел.
Пакетная отправка данных может значительно повысить эффективность обработки.Kafka Producer может накапливать сообщения в памяти до определенного числа и отправлять запросы в виде пакета. Количество пакетов может контролироваться параметрами производителя.Значение параметра может быть установлено на количество накопленных сообщений (например, 500), накопленный временной интервал (например, 100 мс) или размер накопленных данных (64 КБ). . Увеличивая размер пакета, можно уменьшить количество сетевых запросов и операций ввода-вывода на диск.Конечно, конкретные настройки параметров необходимо взвешивать с точки зрения эффективности и своевременности.
Производители могут отправлять сообщения в kafka асинхронно и параллельно, но обычно производитель получает будущий ответ после отправки сообщения, который возвращает значение смещения или ошибку, возникшую в процессе отправки. Есть очень важный параметр "acks", определяющий запрос производителя на лидера Количество реплик, которые раздел получил подтверждение. Если количество подтверждений равно 0, это означает, что производитель не будет ждать ответа брокера. Следовательно, производитель не может знать, успешно ли отправлено сообщение, что может приведет к потере данных, но в то же время значение acks равное 0 позволит получить максимальную пропускную способность системы.
Если для acks установлено значение 1, это означает, что производитель получит подтверждение от посредника, когда ведущий раздел получит сообщение, что будет иметь большую надежность, поскольку клиент будет ждать, пока посредник не подтвердит получение сообщения. Если установлено значение -1, производитель получит подтверждение от брокера, когда все разделы резервного копирования получат сообщение, этот параметр может получить максимальную гарантию надежности.
Сообщения Kafka состоят из заголовка фиксированной длины и массива байтов переменной длины. Поскольку сообщения Kafka поддерживают массивы байтов, Kafka может поддерживать любой пользовательский формат серийных номеров или другие существующие форматы, такие как Apache Avro, protobuf и т. д. Kafka не ограничивает размер отдельного сообщения, но мы рекомендуем, чтобы размер сообщения не превышал 1 МБ, обычно до того, как размер общего сообщения составит 1~10 КБ.
При публикации сообщения клиент kafka сначала создает сообщение и добавляет сообщение в набор сообщений (Kafka поддерживает пакетную публикацию, вы можете добавить несколько сообщений в набор сообщений и опубликовать его в одной строке), при отправке сообщения производитель Клиенту необходимо указать тему, к которой относится сообщение.
5.2 ConsumersKafka предоставляет два набора потребительских API, разделенных на высокоуровневый API и API-интерфейс образца. Sample-api — это низкоуровневый API, который поддерживает соединение с одним брокером, и этот API полностью не имеет состояния, и в каждом запросе нужно указывать значение смещения, поэтому этот API также является наиболее гибким.
В kafka значение смещения того сообщения, которое читается в данный момент, поддерживается потребителем., поэтому потребитель может решить, как читать данные в kafka.Например, потребитель может повторно использовать уже использованные данные, сбросив значение смещения. Независимо от того, используются они или нет, Kafka будет сохранять данные в течение определенного периода времени. Этот период времени можно настроить. Только по истечении срока действия Kafka удалит данные. (Это отличается от AMQ, сообщения AMQ обычно сохраняются в mysql, а использованные сообщения будут удалены)
Высокоуровневый API инкапсулирует доступ к ряду брокеров в кластере и может прозрачно использовать тему. Он сам поддерживает состояние потребляемых сообщений, то есть каждый раз потребляется следующее сообщение.
Высокоуровневый API также поддерживает потребление тем в форме групп.Если потребители имеют одинаковое имя группы, то Kafka эквивалентна службе сообщений очереди, и каждый потребитель потребляет данные в соответствующем разделе сбалансированным образом. Если у потребителей разные имена групп, то kafka эквивалентна широковещательному сервису, который рассылает все сообщения в теме каждому потребителю.
API высокого уровня и API низкого уровня предназначены для потребителя и не имеют ничего общего с производителем.
API высокого уровня заключается в том, что выпускной раздел, прочитанный потребителем, хранятся на зоофильтере. API высокого уровня начнет очередной поток для автоматического синхронизации выключения для Zookeeper через регулярные промежутки времени. Другими словами, если используется API высокого уровня, каждое сообщение может быть прочитано только один раз, и после чтения сообщения не имеет значения, не имеет значения, будет ли обработка моей потребителями или нет. Высокий Другая поток API уровня автоматически синхронизирует Office + 1 к зоофирку. Если возникает проблема с потребителем, чтением данных, Offsite также будет синхронизирован на зоопакере. Следовательно, если потребительская обработка не удалась, она будет продолжаться следующим. Это часто неправильное поведение. Следовательно, лучшая практика заключается в том, чтобы напрямую позволить всему исключительному исключению всей потребительской группы заканчиваться после завершения после завершения обработки потребителей, но последняя часть чтения данных теряется, потому что офсиат в зоофире был +1. Ждать, чтобы начать Conusmer снова При группировке он уже начал читать и обрабатывать с следующего.
Низкоуровневый API — это внешний сайт раздела, читаемый потребителем и поддерживаемый в собственной программе потребителя. Не будет синхронизирован с zookeeper. Однако для удобства мониторинга kafka manager обычно синхронизируется с zookeeper вручную. Преимущество этого в том, что, как только потребитель сообщения не сможет прочитать, внешний сайт этого сообщения поддерживается нами, и мы не будем +1. При следующем перезапуске вы начнете читать с этого оффсайта. Это можно сделать точно раз гарантирует точность данных.
Для группы потребителей: 1. Разрешить группе потребителей (включая нескольких потребителей, таких как кластер, потребляющий одновременно) использовать тему, а различным группам потребителей использовать независимо. 2. Чтобы уменьшить затраты на распределенную координацию между различными потребителями в группе потребителей, укажите раздел как наименьшую единицу параллельного потребления, то есть потребители в группе могут использовать только разные разделы.
Отношения между потребителем и разделом: - Если потребителей больше, чем разделов, это пустая трата, потому что дизайн kafka не допускает параллелизма на разделе, поэтому количество потребителей не должно быть больше, чем количество разделов - Если потребителей меньше, чем разделов, потребитель будет соответствовать Для нескольких разделов количество потребителей и разделов в основном распределяется здесь разумно, иначе данные в разделах будут выбираться неравномерно. - Если потребитель читает данные из нескольких разделов, порядок между данными не гарантируется.Кафка гарантирует только то, что данные упорядочены в одном разделе, но несколько разделов будут отличаться в зависимости от порядка чтения Брокер и раздел вызовут перебалансировку, поэтому раздел, соответствующий потребителю, изменится после перебалансировки - когда данные не могут быть получены из высокоуровневого интерфейса, он будет заблокирован.
В случае низкой нагрузки каждый поток может потреблять несколько разделов. Но когда нагрузка высока, Потребитель Лучше всего, чтобы количество потоков соответствовало количеству разделов. Если вы все еще не можете потреблять его, вы должны снова запустить процесс Consumer.Количество потоков в процессе также совпадает с количеством разделов.
При использовании сообщений клиенту kafka необходимо указать тему и номер раздела (каждый раздел соответствует логическому потоку журнала, например, раздел представляет линейку продуктов, а раздел представляет результат сегментации журнала линейки продуктов по дням). подписывается, он будет итеративно читать сообщения.Если сообщений нет, клиент-потребитель будет блокироваться до тех пор, пока не будет опубликовано новое сообщение. Потребитель может накапливать и подтверждать полученные сообщения. Когда он подтверждает сообщение определенного смещения, это означает, что предыдущее сообщение также было успешно получено. В это время брокер обновит смещение на zookeeper. реестр.
5.3 Эффективная передача данных 1. Издатель может публиковать несколько сообщений одновременно (добавляя сообщения в набор сообщений для публикации), а потребитель потребляет одно сообщение за итерацию.
2. Не создавайте отдельный кеш, используйте системный кеш страниц. Издатель публикует последовательно, а подписчик обычно немного отстает от издателя, поэтому используйте напрямуюLinuxЭффект кеша страниц также сравнивается, и в то же время сокращаются накладные расходы на управление кешем и сборку мусора.
3. Используйте sendfile для оптимизации сетевой передачи и уменьшения одной копии в памяти.6. Kafka и Zookeeper 6.1 Контроль координации Zookeeper 1. Управление динамическим присоединением и выходом брокеров и потребителей. (Производителем не нужно управлять, любой компьютер может отправить сообщение Kakfa Broker в качестве производителя) 2. Запустить балансировку нагрузки, когда брокер или потребитель присоединяется или уходит, будет запущен алгоритм балансировки нагрузки, так что несколько потребителей в балансировка нагрузки потребления группы потребителей. (Поскольку потребитель использует один или несколько разделов, раздел может использоваться только одним потребителем)
3. Поддерживайте отношения потребления и информацию о потреблении каждого раздела.
6.2 Подробная информация о Zookeeper:
1. После запуска каждого брокера в zookeeper будет зарегистрирован временный реестр брокера, включая IP-адрес брокера и номер порта, а также сохраненную информацию о темах и разделах.
2. После старта каждого потребителя на zookeeper регистрируется временный реестр потребителей: он содержит группу потребителей, к которой принадлежит потребитель, и темы, на которые он подписан.
3. Каждая группа потребителей связана с временным реестром владельцев и постоянным реестром смещений. Для каждого подписанного раздела он содержит реестр владельцев, а контент — это идентификатор потребителя, который подписывается на раздел; он также содержит реестр смещения, а контент — это смещение последней подписки.