Публикация и подписка на систему обмена сообщениями
Прежде чем официально обсудить Apache Kafka (далее Kafka), давайте сначала разберемся с концепцией системы сообщений публикации и подписки и признаем важность этой системы. Отправитель (издатель) данных (сообщения) не отправляет сообщение напрямую получателю, что является особенностью системы публикации и подписки сообщений. Издатели определенным образом классифицируют сообщения, а получатели (подписчики) подписываются на них, чтобы получать сообщения определенного типа. Системы публикации и подписки обычно имеют брокера, который является центральной точкой для публикации сообщений.
Большинство вариантов использования систем обмена сообщениями с публикацией и подпиской начинаются с простой очереди сообщений или межпроцессного взаимодействия. Например, система электронной коммерции включает в себя модуль участника, модуль заказа, модуль товара, модуль рекомендаций, модуль логистики дистрибуции и т. д., и задействована передача сообщений между несколькими модулями (подсистемами).
Самым ранним прикладным решением является использование способа прямого соединения (между подсистемами), что делает многие подсистемы переплетенными и сложными. Этот метод соединения «точка-точка» образует ячеистое соединение, имеющее множество недостатков, которые не будут описываться по отдельности.
Позднее для решения проблемы прямого соединения и чередования между подсистемами появилась система очередей. Архитектура, показанная на рисунке ниже, состоит из 3 независимых систем публикации и подписки.
Такой подход намного лучше, чем использование прямого соединения «точка-точка», но здесь слишком много дублирования. Поэтому ваша компания поддерживает несколько систем для очередей данных, каждая со своими ловушками и недостатками. Более того, в будущем может появиться больше сценариев, требующих использования системы обмена сообщениями. На данный момент вам действительно нужна единая централизованная система, которую можно использовать для публикации общих типов данных, размер которых может увеличиваться по мере роста бизнеса вашей компании. Здесь появляется Кафка.
Кафка дебютирует
Kafka — это система обмена сообщениями на основе публикации и подписки, предназначенная для решения вышеуказанных проблем. Его обычно называют «распределенным журналом фиксации» или «распределенной потоковой платформой». Журналы фиксации файловой системы или базы данных используются для обеспечения надежной записи всех транзакций, и путем воспроизведения этих журналов можно реконструировать состояние системы. Точно так же данные Kafka сохраняются в определенном порядке и могут быть прочитаны по запросу. Кроме того, данные Kafka распределяются по всей системе с защитой от сбоев данных и возможностями масштабирования производительности.
сообщения и пакеты
Единица данных в Kafka называется сообщением. Если у вас есть опыт работы с базами данных до использования Kafka, вы можете думать о сообщении как о «строке данных» или «записи» в базе данных. Сообщения состоят из массивов байтов, поэтому для Кафки данные в сообщении не имеют определенного формата или значения. Сообщения могут иметь необязательные метаданные, ключ. Ключ также представляет собой массив байтов и, как и сообщение, не имеет особого значения для Кафки. Ключи используются, когда сообщения записываются в разные разделы контролируемым образом. Самый простой пример — сгенерировать согласованное хеш-значение для ключа, а затем использовать хеш-значение для деления по модулю количества разделов темы, чтобы выбрать раздел для сообщения. Это гарантирует, что сообщения с одним и тем же ключом всегда будут записываться в один и тот же раздел.
Для повышения эффективности сообщения записываются в Kafka пакетами. Пакет — это набор сообщений, относящихся к одной теме и разделу. Если каждое сообщение проходит по сети отдельно, это вызовет большие сетевые накладные расходы, а разделение сообщения на пакеты может уменьшить сетевые накладные расходы. Однако существует компромисс между временной задержкой и пропускной способностью: чем больше пакет, тем больше сообщений обрабатывается в единицу времени и тем больше время передачи одного сообщения. Пакетные данные будут сжаты, что может улучшить передачу данных и емкость хранилища, но требует дополнительной вычислительной обработки.
Темы и разделы
Шепот Кафки разделен по темам. Темы подобны таблицам в базе данных или папкам в файловой системе. Тему можно разделить на несколько разделов, а раздел — это журнал коммитов. Сообщения записываются в разделы в порядке добавления, а затем считываются в порядке поступления. Обратите внимание, что, поскольку тема обычно содержит несколько разделов, порядок сообщений не может быть гарантирован во всем разделе, но гарантируется порядок сообщений в одном разделе. Тема, показанная на рисунке ниже, имеет 4 раздела, и сообщения принудительно записываются в конце каждого раздела. Kafka реализует избыточность данных и масштабируемость за счет секционирования. Разделы могут быть распределены по разным серверам, то есть тема может охватывать несколько серверов, чтобы обеспечить более высокую производительность, чем один сервер.
Мы обычно используем слово «поток» для описания таких систем, как Kafka, которые взаимодействуют с данными. Часто люди думают о данных темы как о потоке, независимо от того, сколько разделов он имеет. Поток — это набор данных, которые перемещаются от производителя к потребителю. Так обычно описываются сообщения, когда мы обсуждаем потоковую передачу. Такие платформы, как Kaflca Streams, Apache Samza и Storm, обрабатывают сообщения в режиме реального времени, что также называется потоковой передачей. Мы можем сравнить потоковую передачу с автономной обработкой, поскольку Hadoop предназначен для обработки больших объемов данных в более поздний момент времени.
производитель и потребитель
Клиенты Kafka — это пользователи системы Kafka, и они делятся на два основных типа: производители и потребители. В дополнение к этому есть и другие клиентские API высокого уровня — Kaflca Connect API для интеграции данных и Kaflca Streams для потоковой передачи. Эти высокоуровневые клиентские API обеспечивают расширенную функциональность, используя производителей и потребителей в качестве внутренних компонентов.
Продюсер создает сообщение. В других системах публикации и подписки производители могут называться издателями или писателями. Обычно сообщение публикуется на определенную тему. Производители по умолчанию равномерно распределяют сообщения по всем разделам темы, независимо от того, в какой раздел записывается конкретное сообщение. Однако в некоторых случаях производитель будет записывать сообщение непосредственно в указанный раздел. Обычно это достигается с помощью ключа сообщения и разделителя, который генерирует хеш-значение для ключа и сопоставляет его с указанным разделом. Это гарантирует, что сообщения, содержащие один и тот же ключ, будут записываться в один и тот же раздел. Производители также могут использовать настраиваемые разделители для сопоставления сообщений с разделами в соответствии с различными бизнес-правилами. Производители подробно рассматриваются в следующей главе.
Потребители читают сообщения. В других системах публикации и подписки потребителей можно называть подписчиками или читателями. Потребители подписываются на одну или несколько тем и читают сообщения в том порядке, в котором они создаются. Потребители различают уже прочитанные сообщения, проверяя смещение диска сообщения. Смещение — это еще один вид метаданных, представляющий собой постоянно увеличивающееся целочисленное значение, которое Kafka добавляет к сообщению при его создании. В пределах данного раздела смещение для каждого шепота уникально. Потребитель сохраняет последнее тихое смещение, прочитанное каждым разделом в Zookeeper или Kafka, и если молчаливый потребитель будет закрыт или перезапущен, его состояние чтения не будет потеряно.
Потребители являются частью группы потребителей, то есть один или несколько потребителей будут читать тему вместе. Группы гарантируют, что каждый раздел может использоваться только одним потребителем. В группе, показанной на рисунке ниже, 3 потребителя читают тему одновременно. Каждый из двух потребителей читает один раздел, а другой потребитель читает два других раздела. Отображение между потребителями и разделами часто называют владением разделами-потребителями.
Таким образом, потребители могут использовать темы, содержащие большое количество сообщений. Кроме того, если потребитель выходит из строя, другие потребители в группе могут взять на себя работу отказавшего потребителя. В главе 4 будут подробно описаны потребители и группы потребителей.
брокеры и кластеры
Автономный сервер Kafka называется брокером. Брокер получает сообщение от производителя, устанавливает смещение для сообщения и отправляет сообщение на диск для сохранения. Брокеры обслуживают потребителей, отвечая на запросы на чтение разделов, возвращая сообщения, которые были зафиксированы на диске. В зависимости от конкретного оборудования и его характеристик производительности один брокер может легко обрабатывать тысячи разделов и миллионы сообщений в секунду.
Брокер можно рассматривать как узел обработки промежуточного программного обеспечения сообщений, узел Kafka — это брокер, а один или несколько брокеров могут образовывать кластер Kafka.
Брокер является неотъемлемой частью кластера. В каждом кластере есть брокер, который также действует как контроллер кластера (автоматически избирается из числа активных членов кластера). Контроллер отвечает за управление, включая назначение разделов брокерам и мониторинг брокеров.В кластере раздел подчиняется брокеру, а брокер называется лидером раздела. Раздел может быть назначен нескольким брокерам, и в это время будет происходить репликация раздела (см. рисунок ниже). Этот механизм репликации обеспечивает избыточность сообщений для разделов, и в случае сбоя одного посредника другие посредники могут взять на себя управление. Однако соответствующие потребители и производители вновь подключаются к новому лидеру.
Сохранение сообщений (на определенный срок) — важная особенность Kafka. Политика хранения сообщений брокера Kafka по умолчанию следующая: либо хранить его в течение определенного периода времени (например, 7 дней), либо хранить его до тех пор, пока сообщение не достигнет определенного размера в байтах (например, 1 ГБ). Когда количество сообщений достигает этих пределов, срок действия старых сообщений истекает, и они удаляются, поэтому общее количество доступных сообщений ни при каких обстоятельствах не может превысить размер, указанный в параметре конфигурации. Темы могут настраивать свои собственные политики хранения, которые могут молча сохранять их до тех пор, пока они больше не будут использоваться. Например, данные, используемые для отслеживания действий пользователей, могут храниться в течение нескольких дней, а метрики приложений — всего несколько часов. Тему можно настроить как компактный журнал, будет сохранено только последнее сообщение с определенным ключом. Эта ситуация хорошо работает для данных типа журнала изменений, поскольку важно только последнее изменение.
Почему выбирают Кафку
несколько производителей
Kafka может беспрепятственно поддерживать несколько производителей, независимо от того, используют ли клиенты одну тему или несколько тем. Поэтому он очень подходит для сбора данных из нескольких интерфейсных систем и предоставления данных в унифицированном формате. Например, веб-сайт с несколькими микрослужбами может создать одну тему для просмотров страниц, и все службы будут записывать данные в эту тему в одном и том же формате сообщений. Потребительские приложения получают унифицированное представление страницы без координации потока данных от разных производителей.
несколько потребителей
Помимо поддержки нескольких производителей, Kafka также поддерживает несколько потребителей, считывающих данные из одного потока сообщений, и потребители не затрагиваются напрямую. Это отличается от других систем очередей, где сообщение, прочитанное одним клиентом, не может быть прочитано другими клиентами. Кроме того, несколько потребителей могут сформировать группу, которая совместно использует поток сообщений и гарантирует, что каждое данное сообщение будет обработано всей группой только один раз.
Дисковое хранилище данных
Kafka не только поддерживает несколько потребителей, но также позволяет потребителям читать сообщения не в режиме реального времени благодаря функциям хранения данных Kafka. «Информация фиксируется на диске и сохраняется в соответствии с установленными правилами хранения. Каждая тема может устанавливать отдельные правила хранения для удовлетворения потребностей разных потребителей, и каждая тема может сохранять разное количество сообщений. Потребители могут быть не в состоянии вовремя прочитать сообщения из-за низкой скорости обработки или внезапных пиков трафика, а постоянные данные могут гарантировать, что данные не будут потеряны. • Потребители могут на короткое время отключаться от сети во время обслуживания приложений, не беспокоясь о потере сообщений или помехах на стороне производителя. Потребители могут быть отключены, но сообщения останутся в Kafka. Потребители могут продолжить обработку сообщений с того места, где они остановились.
Масштабируемость
Чтобы с легкостью обрабатывать большие объемы данных, Kafka с самого начала разрабатывалась как гибкая и масштабируемая система. Пользователи могут начать с одного брокера на этапе разработки, затем масштабировать его до небольшого кластера разработки из 3 брокеров, а затем, по мере роста соли данных, кластер, развернутый в производственной среде, может содержать сотни брокеров. Масштабирование онлайн-кластера вообще не влияет на общую доступность системы. Другими словами, кластер, содержащий несколько брокеров, может продолжать предоставлять услуги клиентам, даже если отдельные брокеры выходят из строя. Для повышения отказоустойчивости кластера необходимо настроить более высокий коэффициент репликации.
высокая производительность
Все упомянутые выше функции делают Kafka высокопроизводительной системой обмена сообщениями для публикации и подписки. Масштабируя производителей, потребителей и брокеров, Kafka может легко обрабатывать огромные потоки сообщений. Он также гарантирует задержку сообщений менее секунды при обработке больших объемов данных.