Apache Kafka — WorkFlow

На данный момент мы обсудили основные понятия Кафки. Давайте теперь пролить свет на рабочий процесс Кафки.

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

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

Рабочий процесс обмена сообщениями Pub-Sub

Ниже приведен пошаговый рабочий процесс сообщений Pub-Sub.

• Производители отправляют сообщения в тему на регулярной основе.

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

• Потребитель подписывается на определенную тему.

• Как только потребитель подписывается на тему, Kafka предоставит потребителю текущее смещение темы, а также сохранит смещение в ансамбле Zookeeper.

• Потребитель будет регулярно запрашивать у Кафки новые сообщения (например, 100 мс).

• Как только Кафка получает сообщения от производителей, она отправляет эти сообщения потребителям.

• Потребитель получит сообщение и обработает его.

• Как только сообщения обработаны, потребитель отправит подтверждение брокеру Kafka.

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

• Этот вышеописанный поток будет повторяться до тех пор, пока потребитель не остановит запрос.

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

Производители отправляют сообщения в тему на регулярной основе.

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

Потребитель подписывается на определенную тему.

Как только потребитель подписывается на тему, Kafka предоставит потребителю текущее смещение темы, а также сохранит смещение в ансамбле Zookeeper.

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

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

Потребитель получит сообщение и обработает его.

Как только сообщения обработаны, потребитель отправит подтверждение брокеру Kafka.

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

Этот вышеописанный поток будет повторяться до тех пор, пока потребитель не остановит запрос.

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

Рабочий процесс очереди сообщений / группы потребителей

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

• Производители регулярно отправляют сообщения в тему.

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

• Отдельный потребитель подписывается на конкретную тему, предположим, что Тема-01 с идентификатором группы в качестве Группы-1 .

• Kafka взаимодействует с потребителем так же, как и Pub-Sub Messaging, пока новый потребитель не подпишется на ту же тему, Topic-01 с тем же идентификатором группы, что и Group-1 .

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

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

• Эта функция также называется Consumer Group . Таким же образом, Kafka предоставит лучшее из обеих систем очень простым и эффективным способом.

Производители регулярно отправляют сообщения в тему.

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

Отдельный потребитель подписывается на конкретную тему, предположим, что Тема-01 с идентификатором группы в качестве Группы-1 .

Kafka взаимодействует с потребителем так же, как и Pub-Sub Messaging, пока новый потребитель не подпишется на ту же тему, Topic-01 с тем же идентификатором группы, что и Group-1 .

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

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

Эта функция также называется Consumer Group . Таким же образом, Kafka предоставит лучшее из обеих систем очень простым и эффективным способом.

Роль ZooKeeper

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

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

Чтобы узнать больше о Zookeeper, пожалуйста, обратитесь к Zookeeper

Давайте продолжим, как установить Java, ZooKeeper и Kafka на вашем компьютере в следующей главе.