В этой статье в основном объясняется, что такое Kafka, архитектура Kafka, включая рабочий процесс и механизм хранения, а также производители и потребители.В конце концов, каждый освоит самые важные концепции в Kafka, а именно: брокер, производитель, потребитель, группа потребителей, тема, раздел, реплика, лидер, последователь, это основа и основное содержание изучения и понимания Кафки.
1. Определения
KafkaЭто распределенная очередь сообщений (Message Queue), основанная на режиме публикации/подписки, которая в основном используется в сфере обработки больших данных в реальном времени.
1.1 Очередь сообщений
Kafka — это, по сути, MQ (очередь сообщений). Каковы преимущества использования очередей сообщений? (интервью спросит)
- Развязка: позволяет нам независимо расширять или изменять обработку на обеих сторонах очереди.
- Возможность восстановления: даже если процесс, обрабатывающий сообщение, завершается, сообщение, добавленное в очередь, все еще может быть обработано после восстановления системы.
- Буферизация: помогает устранить несоответствия в скорости обработки при создании и использовании сообщений.
- Гибкость и возможности пиковой обработки: очередь сообщений не будет полностью разрушена из-за внезапных перегруженных запросов, а очередь сообщений может заставить ключевые компоненты выдерживать внезапное давление доступа.
- Асинхронная связь: очереди сообщений позволяют пользователям помещать сообщения в очереди, но не обрабатывают их немедленно.
1.2 Модель публикации/подписки
Один-ко-многим производитель публикует сообщения в теме, а несколько потребителей подписываются на тему.Сообщения, опубликованные в теме, будут потребляться всеми подписчиками, а потребляемые данные не будут немедленно удалены из темы.
2. Архитектура
Kafka хранит сообщения от любого количества процессов, называемых производителями. Таким образом, данные могут быть опубликованы в разных разделах по разным темам. Внутри раздела эти сообщения индексируются и хранятся вместе с метками времени. Другие процессы, называемые потребителями, могут подписываться на сообщения из раздела. Kafka работает в кластере из одного или нескольких серверов, а разделы могут быть распределены по узлам кластера.
Некоторые важные концепции Кафки приведены ниже, чтобы у каждого было общее понимание и восприятие Кафки, а функция каждой концепции и более глубокие принципы будут подробно проанализированы позже.
- Режиссер:Производитель сообщений, клиент, который отправляет сообщения в Kafka Broker.
- Потребитель:Потребитель сообщений, клиент, который получает сообщения от Kafka Broker.
- Группа потребителей:Группа потребителей (CG), каждый потребитель в группе потребителей отвечает за потребление данных в разных разделах для повышения емкости потребления. Раздел может использоваться только одним потребителем в группе, и группы потребителей не влияют друг на друга. Все потребители принадлежат к определенной группе потребителей, то есть группа потребителей логически является подписчиком.
- Маклер:Машина кафка - это брокер. Кластер состоит из нескольких брокеров. Брокер может провести несколько тем.
- Тема:Его можно понимать как очередь, тема классифицирует сообщения, а производители и потребители сталкиваются с одной и той же темой.
- Раздел:Для достижения масштабируемости и улучшения параллелизма очень большая тема может быть распределена между несколькими брокерами (т. е. серверами), а тема может быть разделена на несколько разделов, каждый из которых представляет собой упорядоченную очередь.
- Реплика:Реплика, чтобы реализовать функцию резервного копирования, чтобы гарантировать, что при сбое узла в кластере данные раздела на узле не будут потеряны, и Kafka все еще может продолжать работать.Кафка предоставляет механизм репликации, и каждый раздел топик имеет несколько реплик, лидера и несколько последователей.
- Лидер:«Первичная» реплика нескольких реплик каждого раздела, объекты, которым производители отправляют данные, и объекты, которые потребляют данные, являются лидерами.
- Последователь:«Подчиненные» реплики нескольких реплик каждого раздела синхронизируют данные от лидера в режиме реального времени и поддерживают синхронизацию с данными лидера. Когда лидер терпит неудачу, последователь также становится новым лидером.
- компенсировать:Информация о местоположении потребления потребителя, отслеживание того, где потребляются данные, и когда потребитель вешает трубку, а затем возобновляет, он может продолжать потреблять из места потребления.
- Работник зоопарка:Чтобы кластер Kafka работал нормально, он должен полагаться на zookeeper, который помогает Kafka хранить информацию о кластере и управлять ею.
3 Рабочий процесс
Кластеры Kafka хранят потоки записей в категориях, называемых темами, каждая запись состоит из ключа, значения и метки времени.Kafka — это распределенная стриминговая платформа., Что именно это означает?
- Публикуйте потоки записей и подписывайтесь на них, подобно очередям сообщений или корпоративным системам обмена сообщениями.
- Сохраняйте потоки записей отказоустойчивым и устойчивым образом.
- Обработать поток записей.
Сообщения в Kafka классифицируются по темам: производители создают сообщения, а потребители потребляют сообщения, и все они нацелены на одну и ту же тему.
Тема — это логическое понятие, а раздел — физическое понятие.Каждый раздел соответствует файлу журнала, а в файле журнала хранятся данные, созданные производителем. Данные, созданные производителем, будут постоянно добавляться в конец файла журнала, и каждый фрагмент данных имеет свое собственное смещение. Каждый потребитель в группе потребителей будет записывать смещение, до которого он потребляет, в режиме реального времени, так что, когда ошибка устранена, он может продолжить потребление с последней позиции.
4 Механизм хранения
Поскольку сообщения, созданные производителем, будут по-прежнему добавляться в конец файла журнала, чтобы файл журнала не был слишком большим и не приводил к неэффективному расположению данных, Kafka принимаетФрагментацияипоказательМеханизм, каждый раздел разделен на несколько сегментов, каждый сегмент соответствует двум файлам: индексному файлу «.index» и файлу данных «.log». Эти файлы находятся в одном файле, и правило именования папки такое: название темы-номер раздела. Например, если в разделе first есть три раздела, соответствующие папки будут first-0, first-1 и first-2.
# ls /root/data/kafka/first-0
00000000000000009014.index
00000000000000009014.log
00000000000000009014.timeindex
00000000000000009014.snapshot
leader-epoch-checkpoint
Файлы индекса и журнала называются со смещением первого сообщения текущего сегмента. На следующем рисунке представлена схема структуры файла индекса и файла журнала.
В файле «.index» хранится большой объем индексной информации, в файле «.log» хранится большой объем данных, а метаданные в индексном файле указывают на физическое смещение сообщения в соответствующем файле данных.
5. Производители
5.1 Стратегия разделения
5.1.1 Причины разделения
- В кластере удобно расширяться, каждый раздел можно настроить в соответствии с машиной, на которой он расположен, а тема может состоять из нескольких разделов, поэтому ее можно читать и записывать в единицах разделов.
- Параллелизм можно улучшить, чтобы вы могли читать и писать в единицах разделов.
5.1.2 Принцип разделения
Нам нужно инкапсулировать данные, отправленные производителем, в объект ProducerRecord. Объекту необходимо указать некоторые параметры:
- тема: строковый тип, NotNull
- раздел: тип int, необязательный
- временная метка: длинный тип, необязательный
- ключ: строковый тип, необязательный
- значение: строковый тип, необязательный
- заголовки: тип массива, Nullable
(1) В случае указания раздела непосредственно используйте данное значение в качестве значения раздела.
(2) Если раздел не указан, но есть ключ, значение раздела получается путем взятия остатка от хеш-значения ключа и количества разделов.
(3) При отсутствии раздела с ключом или без него при первом вызове случайным образом генерируется целое число (целое число увеличивается при каждом последующем вызове), и это значение делится на количество доступных разделов, чтобы получить значение раздела. , который часто называют алгоритмом циклического опроса.
5.2 Гарантия достоверности данных
Чтобы гарантировать, что данные, отправленные производителем, могут быть надежно отправлены в указанную тему, каждый раздел темы должен отправить подтверждение производителю после получения данных, отправленных производителем.Выполнить следующий раунд отправки, в противном случае повторно отправить данные.
5.2.1 Стратегия синхронизации данных реплики
(1) Когда отправлять подтверждение?
Убедитесь, что ведомый и ведущий синхронизированы, а лидер снова отправляет ack, чтобы гарантировать, что после смерти ведущего в ведомом можно будет выбрать нового ведущего без потери данных.
(2) Сколько подписчиков отправляют подтверждение после завершения синхронизации?
После того, как все фолловеры синхронизированы, отправляется ack.
5.2.2 ISR
При втором решении все ведомые могут завершить синхронизацию до того, как производитель сможет продолжить отправку данных.Если ведомый по какой-то причине выходит из строя, лидер будет ждать, пока он не завершит синхронизацию. Как решить эту проблему?
Лидер поддерживает динамический набор синхронизированных реплик (ISR): набор последователей, синхронизированных с лидером. Когда подписчики в наборе ISR завершат синхронизацию данных, лидер отправит подтверждение подписчику. Если фолловер длительное время не синхронизирует данные с лидером, то фолловер будет выкинут из набора ISR.Порог времени задается параметром replica.lag.time.max.ms. После неудачи лидера из ISR избирается новый лидер.
5.2.3 механизм ответа подтверждения
Для некоторых менее важных данных надежность данных не очень высока, и можно допустить небольшую потерю данных, поэтому нет необходимости ждать, пока все подписчики в ISR успешно их примут.
Таким образом, Kafka предоставляет пользователям три уровня надежности.Пользователи могут выбирать следующие конфигурации в соответствии с требованиями надежности и задержки.
(1) конфигурация параметров подтверждения:
- 0: Производитель не ждет подтверждения от брокера, что обеспечивает наименьшую задержку. Брокер вернет данные перед записью на диск. При сбое брокера данные могут быть потеряны.
- 1: производитель ожидает подтверждения от брокера.Лидер раздела возвращает подтверждение после успешного размещения раздела.Если лидер выходит из строя до того, как ведомый будет успешно синхронизирован, данные будут потеряны.
- -1 (все): производитель ждет подтверждения от брокера и возвращает подтверждение после того, как все лидеры и последователи раздела будут успешно размещены. Однако, когда брокер отправляет подтверждение, лидер выходит из строя, что приводит к дублированию данных.
5.2.4 Детали устранения неполадок
LEO: максимальное смещение каждой реплики.
HW: наибольшее смещение, которое может видеть потребитель, и наименьшее значение LEO в очереди ISR.
(1) Отказ повторителя
После отказа повторителя он будет временно исключен из набора ISR.После восстановления повторителя он прочитает последнее HW, записанное на локальном диске, отрезает часть лог-файла выше HW и синхронизируется с руководитель отдела обработки данных HW. Когда LEO ведомого больше или равно HW раздела, то есть после того, как ведомый догонит ведущего, он может снова присоединиться к ISR.
(2) Ошибка лидера
После отказа лидера из ISR будет выбран новый лидер, после чего, чтобы обеспечить согласованность данных между несколькими репликами, оставшиеся фолловеры сначала обрежут часть своих лог-файлов выше HW, а затем перезапустят лидер синхронизирует данные.
Примечание. Это гарантирует только согласованность данных между репликами и не гарантирует, что данные не будут потеряны или дублированы.
5.3 Семантика «Ровно один раз»
Установка уровня ACK сервера на -1 может гарантировать, что никакие данные не будут потеряны между производителем и сервером, то естьAt Least Onceсемантика. И наоборот, установка уровня ACK сервера на 0 гарантирует, что каждое сообщение от производителя будет отправлено только один раз, т.е.At Most Onceсемантика.
По крайней мере один раз может гарантировать, что данные не будут потеряны, но не может гарантировать, что данные не будут дублироваться; наоборот, не более одного раза может гарантировать, что данные не будут дублироваться, но не может гарантировать, что данные не будут потеряны. Однако для некоторой очень важной информации, такой как данные транзакций, нижестоящие потребители данных требуют, чтобы данные не дублировались и не терялись, т.е.Exactly Onceсемантика.
Представлена версия 0.11 Kafkaидемпотентность: независимо от того, сколько дубликатов данных производитель отправляет на сервер, сервер сохранит только один. который:
At Least Once + 幂等性 = Exactly Once
Чтобы включить идемпотентность, просто добавьте параметр производителя вenable.idompotenceУстановить какtrueВот и все. Производитель с включенной идемпотентностью будет назначен PID во время инициализации, а сообщения, отправленные в тот же раздел, будут сопровождаться порядковым номером. Сторона брокера будет кэшировать
Однако PID изменится после перезапуска, и разные разделы также имеют разные первичные ключи, поэтому идемпотентность не может гарантировать Exactly Once для сеансов между разделами.
6. Потребители
6.1 Метод потребления
Потребитель считывает данные от брокера в режиме извлечения.
Потребитель принимает режим push, и скорость, с которой брокер отправляет сообщения потребителю, определяется брокером, и его трудно адаптировать к потребителям с разными скоростями потребления. Его цель состоит в том, чтобы доставлять сообщения как можно быстрее, но это может легко привести к тому, что потребители будут слишком поздно обрабатывать сообщения, как правило, из-за отказа в обслуживании и перегрузки сети. В режиме извлечения сообщения могут потребляться с соответствующей скоростью в соответствии с потребляемой мощностью потребителя.
Недостатком режима pull является то, что если у Kafka нет данных, потребитель может зациклиться, постоянно возвращая пустые данные. Поскольку потребители активно извлекают данные из брокера, им необходимо поддерживать длительный опрос.Для этого потребители Kafka будут передавать параметр тайм-аута при потреблении данных.Если в настоящее время нет данных, доступных для потребления, потребитель будет ждать в течение периода время.После возврата этот период времени является тайм-аутом.
6.2 Стратегия выделения разделов
В группе потребителей есть несколько потребителей, а топик имеет несколько разделов, поэтому неизбежно потребуется выделение разделов, то есть определение того, какой раздел потребляется каким потребителем.
У Kafka есть две стратегии распределения: RoundRobin и Range, который по умолчанию является диапазоном.Когда потребители в группе потребителей изменяются, стратегия выделения раздела (переназначение метода) будет активирована.
(1) Круговая система
Метод опроса RoundRobin выполняет хеш-сортировку по всем разделам в целом, максимальная разница в количестве разделов, выделенных в группе потребителей, равна 1, которая делится по группам, что может решить проблему несбалансированного потребления данных несколькими потребителями. .
Однако, когда группа потребителей подписывается на разные темы, это может привести к путанице в потреблении.Как показано на рисунке ниже, потребитель0 подписывается на тему А, а потребитель1 подписывается на тему Б. После сортировки разделов тем А и В они назначается группе потребителей.В разделе TopicB данные могут быть назначены потребителю0.
(2) Диапазон
Метод диапазона разделен в соответствии с темой и не вызовет проблемы путаницы при использовании метода опроса.
Однако, как показано на рисунке ниже, Consumer0 и Consumer1 подписываются на темы A и B одновременно, что может привести к неравному распределению сообщений.Когда в группе потребителей подписано больше тем, распределение разделов может быть более несбалансированным.
6.3 Поддержание смещения
Поскольку потребитель может столкнуться со сбоями, такими как сбой питания и простои в процессе потребления, после восстановления потребителя ему необходимо продолжить потребление с позиции до сбоя, поэтому потребителю необходимо записать смещение, до которого он потребляет, в режиме реального времени. , чтобы он мог продолжать потреблять после устранения сбоя.
До версии Kafka 0.9 потребитель по умолчанию сохранял смещение в Zookeeper, а начиная с версии 0.9 потребитель по умолчанию сохранял смещение во встроенной теме Kafka, которая называется __consumer_offsets.
Я только что подробно обсудил с вами архитектуру Kafka, сосредоточившись на теории и основах, необходимых для освоения Kafka.Далее я обновлю API Kafka и расширенные статьи, такие как транзакции, перехватчики и мониторинг, в виде кода и примеров. ., чтобы каждый мог полностью понять и использовать Kafka. Если это поможет вам, ставьте лайки и подбадривайте друг друга~