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

Вступление

Документация Apache Kafka - один из лучших источников знаний об этой платформе. Он включает вводную информацию, краткое руководство, детали реализации, описание API и т. Д.

Недавно, просматривая веб-страницы, я наткнулся на большую параллель, которая идеально описывает концепцию потоковой передачи событий, лежащую в основе философии Kafka.

«Потоковая передача событий - это цифровой эквивалент центральной нервной системы человеческого тела».

Честно говоря, про краткое описание не только потоковой передачи событий, но и самого Apache Kafka сказать больше нечего. Он принимает записи, хранит их и предоставляет доступ, когда это необходимо. Как нервная система!

Имея в виду приведенное выше краткое введение, несмотря на его литературную ценность, оно не содержит каких-либо подробностей о внутреннем устройстве Apache Kafka, поэтому в следующих главах я буду обсуждать некоторые технические аспекты (например, Брокеры, распределение данных, репликация данных и Хранение данных) Кафки.

Обратите внимание!

Желательно иметь опыт работы с Apache Kafka, чтобы извлечь пользу из этой статьи. Поэтому, если у вас нет большого опыта работы с Kafka или вы не слышали о нем, обратитесь к вводной статье - Настройка сцены для Apache Kafka ».

Брокеры

Как вы уже должны знать, кафка работает как кластер. Каждый из них состоит из одного или нескольких серверов, распределенных по разным центрам обработки данных. Один сервер kafka называется брокером (или сервером начальной загрузки) и может быть идентифицирован по уникальному идентификатору в пределах всего кластера.

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

Брокеры могут взаимодействовать друг с другом внутри кластера kafka, поэтому, как только клиент подключается к любому брокеру kafka, он подключается ко всем брокерам внутри всего кластера. Среди всех брокеров в кластере один работает как лидер (Контроллер). Такой ведущий сервер выбирается автоматически (вы прочтете об этом в последнем абзаце - Zookeeper & Broker Discovery) и обрабатывает административные операции (то есть назначает разделы другим брокерам).

Распространение данных, репликация данных

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

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

Такая архитектура обеспечивает избыточность данных, которая защищает от потери данных, от простоев потоковой передачи (при определенных условиях) и от задержек в обслуживании сообщений из-за того, что лидеры распределены по разным брокерам.

Хранение данных

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

Во-первых, Kafka может хранить сообщения в течение определенного периода времени (например, 4 часов или 10 дней). Другая возможность - установить размер порога (например, 5 ГБ), и в этом случае при достижении этих пределов «устаревшие» данные удаляются из кластера.

В большинстве случаев механизм хранения настраивается на всем кластере Kafka. Однако для некоторых целей можно также настроить удержание по отдельным темам. Таким образом, для темы, в которой хранятся показатели и журналы, может быть установлен срок хранения 6 часов. В то время как тема, которая работает как источник событий, может хранить данные с самого начала.

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

Zookeeper & Broker Discovery

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

Вот почему каждый брокер должен быть подключен к Apache Zookeeper, который хранит все данные, касающиеся сущностей (например, брокеров, темы, практики и т. Д.) В данном кластере. Такие «данные» называются метаданными (или данными конфигурации) и состоят из списка существующих разделов, точного количества разделов для всех разделов, созданных в кластере kafka, расположения реплик и информации о том, какой узел выбран быть лидером.

Говоря о ведущем узле (или контроллере) - Zookeeper - это место, где проходят «выборы контроллера». Если один из узлов в кластере вышел из строя, задача контроллера состоит в том, чтобы отправить информацию о таком сбое в соответствующие разделы и выбрать новый ведущий раздел.

Заявление об ограничении ответственности!

Планируется удалить Zookeeper из проекта Apache Kafka. Переходная версия Kafka будет иметь как устаревший режим (с zookeeper), так и новый без него. В следующих выпусках zookeeper может быть полностью удален из проекта Apache Kafka. В таком случае этот абзац больше не действует. Если вы хотите узнать, как kafka будет выполнять обнаружение брокеров и всю работу, которая сейчас выполняется Zookeeper - см. [3] -ю позицию в источниках, упомянутых в конце статьи.

Резюме

Apache Kafka имеет множество аспектов, среди которых есть сущности, которые необходимо знать (например, темы, разделы, смещения), особенности производителя и потребителя, схемы доставки или внутреннее устройство кластера Kafka.

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

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

Прочитанная вами статья - это не конец пути по платформе Apache Kafka.

Еще есть чему поучиться. Поэтому, если вы хотите расширить свои знания о других аспектах Kafka - обратитесь к источникам, указанным ниже.

Всего наилучшего. Продолжайте двигаться и удачи!

WN.

[1] Apache Kafka 2.3 | Документация https://kafka.apache.org/documentation/

[2] Кафка: полное руководство | Неха Нархеде, Гвен Шапира, Тодд Палино | O’Reilly Media, Inc. | 1 ноября 2017 г.

[3] Сообщение в блоге Confluent - Удаление зависимости Zookeeper в Kafka | Https://www.confluent.io/blog/removing-zookeeper-dependency-in-kafka/

[4] Документация Apache Zookeeper | Https://zookeeper.apache.org/documentation.html