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

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

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

Темы Kafka, брокер и разделы

Кафка Темы похожи на таблицы базы данных. Каждая тема состоит из данных из определенного источника определенного типа. Например, состояние вашего кластера может быть темой, состоящей из информации об использовании ЦП и памяти. Точно так же входящий трафик через кластер может быть другой темой.

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

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

Разбиение на разделы и порядок

Напомним, производители пишут данные по заданной теме. Эта тема фактически разбита на несколько разделов. И каждый раздел живет независимо от других, даже для данной темы. Это может привести к большой путанице, когда порядок данных имеет значение. Возможно, вам нужны ваши данные в хронологическом порядке, но наличие нескольких разделов для вашего потока данных не гарантирует идеального порядка.

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

Ключи для перегородок

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

Все сообщения с указанным ключом отправляются в один и тот же раздел. Так, например, активность пользователя можно отслеживать в хронологическом порядке, если данные этого пользователя помечены ключом и поэтому всегда попадают в один раздел. Назовем этот раздел p0 и пользователя u0.

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

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

Заключение

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

Надеюсь, подобные статьи и официальная документация помогут вам на этом пути.