Концептуальная модель предметной области#

Platform V Corax представляет собой распределенную систему обработки потоков данных, работа которой обеспечивается за счет функционирования и взаимосвязи между собой элементов внутри компонентов Corax и их взаимодействия с внешними сервисами клиента.

Общая модель#

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

• компоненты Corax:

  • Apache Kafka;

  • Apache ZooKeeper;

• элементы компонентов;

• внешние сервисы.

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

Внешний сервис представлен в виде двух участников процесса, которые общаются между собой сообщениями: производитель и потребитель. Производитель (Producer) — это приложение или сервис, который публикует сообщение, предназначенное для его потребителей. Потребитель (Consumer) — это приложение или сервис, который читает и обрабатывает сообщения от производителей. Потребители, в свою очередь могут формироваться в группу (Consumer group), если хотят получать одни и те же сообщения.

В качестве инструмента общения производителей с потребителями выступает продукт Platform V Corax, представленный компонентом Corax, который в свою очередь включает в себя сервис-координатор Apache ZooKeeper и брокер сообщений Apache Kafka.

Apache ZooKeeper — это сервис, который управляет работой брокеров.

Apache Kafka, брокер сообщений, предназначен для приема, хранения и передачи всех сообщений от его потребителей всем его подписчикам. Брокер (Broker) представлен в виде сервера, при наличии нескольких брокеров, работающих вместе, они собираются в кластер. Кластер (Cluster) необходим для обеспечения отказоустойчивости и масштабируемости. Как правило разворачивается несколько серверов-брокеров, которые работают вместе и могут заменить друг друга при отказе одного из них.

У брокера имеется свой набор топиков. Топик (Topic) — это поток данных (сообщений), объединенных одной темой. Топики делятся на партиции. Партиция (Partition) — единица хранения данных, содержащая упорядоченную и неизменную последовательность сообщений. Партиции делятся на сегменты (Segment) — минимальные физические единицы хранения данных (сообщений) на сервере.

Производители общаются непосредственно с кластером и получают информацию (метаданные) о том, где располагаются сообщения того топика, по которому производителю требуется опубиковать сообщение. Получив данные о нужной партиции, производитель публикует свое сообщение в нее и получает подтверждение об успешной записи.

Потребители обращаются в кластер за информацией о партиции топика (метаданные), на который они подписаны, и о том, где хранятся сообщения для них. Далее они обращаются в нужную партицию и читают из нее сообщения.

Далее представлены диаграммы более детально описывающие отдельные компоненты и взаимосвязи между элементами компонентов.

Взаимодействие c Apache ZooKeeper#

Apache ZooKeeper — это сервис-координатор, который хранит метаданные о распределении брокеров, топиков и партиций, их лидерах и репликах. Он предназначен для управления, распределения и автоматизации работы своих клиентов — брокеров в кластере Apache Kafka.

Сервис ZooKeeper представлен в виде серверов-узлов (Znode), которые в свою очередь собираются в ансамбль серверов (Ensemble). Минимальное число узлов для ZooKeeper — 3. Один из узлов является лидирующим и хранит и обновляет метаданные в первую очередь. Остальные узлы являются реплицирующими, то есть дублирующими информацию с лидирующего узла. Для каждого ансамбля предполагается только нечетное количество узлов. В случае отказа некоторых узлов, работающим будет считаться ансамбль, в котором строгое большинство узлов остается в рабочем состоянии.

Apache Kafka и его брокеры являются клиентом сервиса ZooKeeper и передают данные в один лидирующий узел. Если произошел сбой работы одного брокера, Kafka передает данные о сбое в ZooKeeper. ZooKeeper перераспределяет работу брокеров, переназначая лидирующие партиции и обновляя метаданные, которые потом потребуются производителям и потребителям.

Детальнее сервис описан в разделе Кластер ZooKeeper

Взаимодействие внутри Apache Kafka#

В диаграмме ниже описывается распределение, взаимосвязь и работа элементов, формирующих компонент Apache Kafka.

В кластере находится несколько брокеров, которые содержат несколько топиков, на которые подписаны потребители и в которые отсылают свои сообщения производители. У каждого топика может быть более одной партиций, которые распределены на брокерах. То есть на каждом брокере есть одна партиция из каждого топика. Одна партиция топика выбрана как лидирующая, остальные являются реплицирующими и дублируют информацию с лидирующей партиции.

Такое распределение делается с целью обеспечения отказоустойчивсти системы. Если произойдет сбой одного брокера, ZooKeeper назначит лидирующей одну из реплицирующих партиций топика на работающем брокере.

Партиция в свою очередь делится на сегменты. Они являются минимальной единицей хранения сообщений и хранятся в виде файлов на сервере. В каждом сегменте может быть более одного сообщения в зависимости от размера сегмента. Как только сегмент полностью заполнен он признается закрытым и больше сообщения не принимает.

Новые сообщения попадают в активный сегмент. При этом каждый новый сегмент называется в соответствии со смещением (Offset) — номером первого сообщения, попавшего в сегмент. Сообщения же нумеруются последовательно в соответствии с тем какими по счету попадают на сервер. Таким образом потребители могут отслеживать сообщения и отделять новые (еще не прочитанные) и старые (уже прочитанные) сообщения.

Если настроено очищение сервера от старых данных в рамках политики хранения данных, то удаление сообщений происходит по сегментам независимо от наполнения сегментов.

Взаимодействие со Schema Registry#

Schema Registry (реестр схем) — сервис хранения, управления и валидации схем данных. Это дополнительный компонент компонента Corax, который обязателен к установке.

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

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

Подробнее о реестре схем можно узнать в руководстве по Schema Registry

Взаимодействие с внешними сервисами#

Внешние сервисы — это клиентские сервисы/приложения, которые пользуются продуктом Platform V Corax для отправки/получения сообщений в режиме реального времени, и не являются частью продукта.

В топик может писать сообщения как один производитель, так и несколько. При этом один производитель может писать сразу в несколько топиков.

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