Особенности кафки
В качестве промежуточного программного обеспечения для сообщений Kafka имеет следующие функции:
- Высокая пропускная способность: пропускная способность до сотен тысяч
- Высокий уровень параллелизма: поддержка тысяч клиентов для одновременного чтения и записи
- Низкая задержка: задержка составляет всего несколько миллисекунд.
- Сохранение и надежность сообщений: сообщения сохраняются на локальном диске при поддержке резервного копирования данных.
- Толерантность к кластерам. Позволяет сбой узлов N-1 (N - количество копий)
- Масштабируемость: Поддержка динамического расширения кластера
Сценарии применения
По характеристикам Kafka существуют следующие сценарии применения:
- Промежуточное ПО для сообщений: сама Kafka, как стандартное промежуточное ПО для сообщений, может использоваться для асинхронной передачи сообщений между производителями и потребителями.
- Журнал: благодаря высокой пропускной способности Kafka можно эффективно собирать журналы.
- Сбор данных: для высокой пропускной способности и высокого уровня параллелизма kafka можно использовать для записи некоторых данных о пользователях/системах в реальном времени.
главное существительное
- Брокер: каждый сервер Kafka называется посредником, который поддерживает горизонтальное расширение.Обычно в кластере есть несколько посредников.Статус каждого посредника одинаков, и отношения ведущий-подчиненный отсутствуют.
- Координатор: координатор кластера Kafka назначит брокера с наименьшей нагрузкой в качестве координатора.
- Тема: Все сообщения имеют свою собственную категорию, и эта категория называется Тема. Сообщения в теме могут храниться на нескольких брокерах (независимо от производителя и потребителя).
- Производитель: основной орган, который генерирует сообщение, называется производителем, который отвечает за публикацию сообщения в указанной теме.
- Потребитель: основная часть объекта-потребителя называется Потребитель, который отвечает за потребление сообщений в указанной теме.
- ConsumerGroup (CG): Каждый Потребитель принадлежит к определенной CG, а Тема может соответствовать нескольким CG.Сообщения темы будут отправляться всем CG, но CG могут выбрать отправку всем Потребителям или указанному Потребителю, что является удобной реализацией одноадресные и широковещательные. В то же время потребители под одной и той же CG могут добиться балансировки нагрузки.
- Раздел: конкретный физический объект, в котором хранятся данные.Каждая тема будет разделена на несколько разделов. Каждому разделу соответствует папка, в которой хранятся файлы данных и индексов. Сообщения в каждом Разделе упорядочены, но данные разных Разделов не могут определить порядок
- Репликация: резервная копия раздела, раздел будет иметь несколько реплик, которые хранятся на разных брокерах.
- Сегмент: относится к каждому файлу данных, раздел соответствует нескольким сегментам, и каждому сегменту соответствует индексный файл.
- Смещение: относится к порядковому номеру сообщения, который постоянно увеличивается Каждое сообщение в разделе будет иметь свое собственное смещение, которое используется для уникальной идентификации сообщения. Поскольку файл данных упорядочен, его можно быстро найти по смещению.
Базовая архитектура
Kafka — это коммуникационная среда RPC, которая естественным образом поддерживает режим публикации-подписки распределенной архитектуры.Кластер Kafka представляет собой типичную децентрализованную конструкцию.Основная конструкция выглядит следующим образом:
Zookeeper
Метаданные кластера Kafka хранятся в Zookeeper, кроме этого данные сообщений не сохраняются. Каждому брокеру необходимо зарегистрироваться в Zookeeper и постоянно обновлять свои собственные метаданные (информацию о теме и разделе). Zookeeper будет использовать эти данные для достижения динамического расширения кластера.
И производитель, и потребитель регистрируют наблюдателя в Zookeeper, который используется для внесения корректировок при изменении Zookeeper. В то же время потребитель также регистрирует список разделов, который он потребляет, в Zookeeper, который используется для обнаружения брокера и установления соединения через сокет с разделом.
основные компоненты
Partition
Темы в Kafka хранятся в виде разделов. Тема будет разделена на несколько разделов и сохранена на нескольких серверах. Когда производитель производит данные, он записывает данные в раздел в соответствии с указанной темой в соответствии с определенными правилами.
Можно установить количество разделов для каждой темы, но следует отметить, что раздел может использоваться только одним потребителем.Если разделов слишком мало, некоторые потребители не смогут использовать данные. Кроме того, рекомендуется, чтобы количество разделов также было больше, чем количество брокеров в кластере, чтобы лидеры разделов могли быть распределены между брокерами как можно более равномерно. Следует также отметить, что чем больше разделов разбито, тем больше места требуется.
Обычно раздел должен иметь несколько копий (репликацию), KAFKA позволяет пользователям устанавливать количество резервных копий данных данных, а копии будут храниться на разных брокерах. Во всех репликах (в том числе сама) будет лидер разбиения для чтения и письма, а планирование выборов лидера и другие операции завершены Zookeeker
Producer
Producter Напрямую отправляет сообщение лидеру раздела брокера, и его не нужно передавать через прокси-сервер, поскольку каждый брокер в кластере Kafka может отдельно отвечать на операции Producter и возвращать некоторую информацию о теме (выживающей машине) / местоположении лидера. / ...)
Клиент Producer отвечает за принятие указанного алгоритма балансировки нагрузки и управление разделами, в которые будет отправлено сообщение. В то же время производитель может накапливать сообщения в памяти до определенного количества и отправлять их в виде пакета, что может эффективно сократить количество операций ввода-вывода и повысить эффективность. Конкретные параметры партии могут быть установлены вручную, например, накопленное количество/временной интервал и т. д.
Производитель может отправлять данные в Kafka асинхронно и после отправки получит ответ Futrue, включая значение смещения и другую информацию. Вы можете контролировать количество подтверждающих сообщений, которые должен получать источник, указав параметр acks.
- Когда параметр acks равен n: производитель получит подтверждение брокера только тогда, когда n реплик раздела получат сообщение
- Когда параметр acks равен -1: производитель получит подтверждение от брокера после того, как все реплики раздела получат сообщение.
- Когда параметр acks равен 0: производитель не будет ждать ответа брокера, который может получить максимальную пропускную способность, но может привести к потере данных
Consumer
Kafka, значение смещения чтения сообщения поддерживается Потребителем, поэтому потребитель может свободно читать сообщение. При этом вне зависимости от того, что сообщение не было потрачено, данные какое-то время будут храниться в кафке
Kafka предоставляет два потребительских API: высокоуровневый API и образец API. Пример API поддерживает соединение только с одним брокером и не имеет состояния.Каждый запрос должен указывать значение смещения, поэтому он более гибкий.
API высокого уровня инкапсулирует доступ к брокеру в кластере и может прозрачно обращаться к теме, сохраняя при этом состояние потребляемых сообщений каждый раз, когда потребляется следующее сообщение. API высокого уровня также поддерживает потребление сообщений в форме группы (CG).Сообщение будет отправлено всем CG, и CG выберет отправку его всем потребителям последовательно или указанному потребителю.
основной механизм
сжатие сообщений
Kafka может отправлять данные в виде коллекции (пакета), и на этой основе Kafka может сжимать пакет. После выполнения сжатия на стороне производителя выполняется распаковка на стороне потребителя, что уменьшает объем данных, необходимых для передачи, и снижает нагрузку на сеть. Kafka добавляет в заголовок сообщения байт для описания атрибута сжатия. Последние два бита этого байта указывают кодировку, используемую для сжатия. Если последние два бита равны 0, это означает, что сообщение не сжато.
надежность сообщения
В идеале сообщение отправляется успешно и отправляется только один раз, это называется ровно один раз, но не удалось отправить сообщение по неизбежным обстоятельствам, и передача сообщения происходит
Чтобы решить проблему такого рода, на стороне производителя при отправке сообщения производитель будет ждать, пока брокер отправит ответ, после получения ответа производитель подтвердит, что сообщение было отправлено в kafka правильно. , иначе он будет повторно отправлен.
На стороне потребителя, поскольку брокер записывает значение смещения в разделе, это значение указывает на следующее сообщение, полученное потребителем.Если потребитель получает сообщение, но потребление не удается, брокер может найти предыдущее сообщение в соответствии со смещением. значение, а потребитель также может управлять смещением значения для выполнения произвольной обработки сообщения.
Резервный механизм
(Эта часть описана в разделе «Основные компоненты — раздел»)
стратегия потребления сообщений
Классификация стратегий потребления
Фиксированное потребление раздела
При выполнении потребительского потребления новостей вы можете указать раздел новостей сообщения
Перебалансировать потребление разделов
Как правило, в рамках темы существует несколько разделов, и раздел может быть использован потребителем только в одной CG. Можно использовать различные методы использования, указав стратегию перебалансировки. Существует два типа стратегий перебалансировки: разбиение по диапазонам (Range) и разбиение по кругу (RoundRobin).
Стратегия секции опроса состоит в том, чтобы сортировать секции в соответствии с хэш-кодом, а затем выделять секции потребителям, взяв секцию по модулю.
Перебалансировать время триггера
При возникновении следующих трех ситуаций операция перебалансировки будет запущена для повторного указания раздела:
- Новый потребитель был добавлен внутри CG
- потребитель покидает CG
- темаДобавить раздел
Процесс выполнения ребаланса
Выполнение ребалансировки завершается Лидером CG, который отвечает за трансляцию результата выполнения в CG через координатора в кластере брокера после выполнения. При запуске первого потребителя CG, потребитель определит координатора в группе с kafka, и тогда все участники в CG будут общаться с координатором
Выборы Лидера CG проходят в два этапа,Join GroupиSynchronizing Group State.
-
Join Groupсцена, все участники будут отправлять запросы на присоединение к группе координатору. Когда все потребители отправят запросы, координатор выберет потребителя в качестве лидера и отправит лидеру информацию CG. -
Synchronizing Group Stateсцена, все потребители отправят координатору запрос SynchronizingGroupState, а лидер отправит координатору схему разбиения, а координатор вернет результат разбиения всем потребителям после получения схемы разбиения, тем самым завершив синхронизацию схемы разбиения
эффективный дизайн
сохранение сообщения
Сохранение сообщений обусловлено не только необходимостью резервного копирования данных.Дело в том, что время линейного чтения и записи намного выше, чем время случайного чтения и записи.Доступ осуществляется быстрее, поэтому многие современные операционные системы используют свободную память как диск Кэш.Хотя это приведет к снижению производительности при восстановлении памяти, повышение эффективности чтения и записи является значительным.
Исходя из этого факта, используя файловую систему для поддержания данных, полагаясь на кэш страницы, лучше, чем поддержание кэша в памяти из-за более компактной структуры данных. Вместо того, чтобы поддерживать как можно больше в памяти кэша памяти, если мы пишем данные в постоянный журнал, флуш не вызывается, что означает, что данные будут переданы на ядро и потомнуть позже, мы также можем настроить для управления, когда данные покраснел на физический диск
гарантия постоянного времени
Постоянная очередь сообщений в kafka реализована путем чтения и записи файлов, аналогичной форме журналов. Хотя эта операция не поддерживает расширенную семантику, она может очень эффективно выполнять параллельные операции, и все операции выполняются за постоянное время.Производительность конечной системы полностью не зависит от размера данных, и жесткий диск может быть полностью использован для эффективных служб сообщений. .
байтовая копия
Чтобы решить проблему копирования байтов, Kafka принимает формат сообщения «стандартное байтовое сообщение», которое совместно используется производителями, потребителями и брокерами. Файлы журнала Kafka записываются в формате «стандартного байтового сообщения» на диск. Чтобы повысить эффективность передачи данных между кэшем страниц и сокетом, в системе unix используется механизм «нулевого копирования», то есть системный вызов системного вызова sendfile, а java также предоставляет интерфейс для доступа к этому системному вызову.
Чтобы объяснить, почему этот подход решает проблему снижения производительности при копировании байтов, давайте сначала опишем общие шаги по отправке данных из файла в сокет:
- ОС считывает данные с диска в кеш страниц в пространстве ядра
- Приложение считывает данные из пространства ядра в кеш страницы пользовательского пространства.
- Приложение записывает данные обратно в кеш сокета в пространстве ядра
- ОС записывает данные из кеша сокета в кеш сетевой карты
- данные пересылаются по сети
Мы можем обнаружить, что этот процесс включает по крайней мере 4 копии байта, 2 системных вызова и 2 переключения из режима ядра в пользовательский режим, и если мы можем напрямую записывать данные в кеш сокета, мы можем уменьшить количество ненужных переключений. Если используется метод sendfile, данные могут быть напрямую скопированы из кэша страниц ядра в кэш сокетов ядра без дополнительного переключения состояния системы. Таким образом, даже если в нисходящем направлении есть много потребителей, это не будет оказывать давления на службу кластера.
Подробнее о механизме нулевого копирования читайте в другой моей статье:Говоря о механизме нулевого копирования
Частые небольшие IO
Частые маленькие IO могут быть решены путем отправки набора сообщений за раз вместо одного сообщения, которое добавляется в журнал в виде блоков сообщений на сервере. В то же время потребитель также запрашивает большое количество линейных блоков данных одновременно при запросе. Набор сообщений упаковывает массив байтов или файл и, необязательно, десериализует его