Apache Kafka – Рабочие процессы

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

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

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

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

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

  • Производители регулярно отправляют сообщения в тему.
  • Брокер Kafka хранит все сообщения в разделах, настроенных для этой конкретной темы. Это гарантирует, что сообщения в равной степени разделены между разделами. Если производитель отправляет два сообщения и имеется два раздела, Kafka сохранит одно сообщение в первом разделе и второе сообщение во втором разделе.
  • Потребитель подписывается на определенную тему.
  • Как только потребитель подписывается на тему, Kafka предоставит потребителю текущее смещение темы, а также сохранит смещение в ансамбле Zookeeper.
  • Потребитель будет регулярно запрашивать у Кафки новые сообщения (например, 100 мс).
  • Как только Кафка получает сообщения от производителей, она отправляет эти сообщения потребителям.
  • Потребитель получит сообщение и обработает его.
  • Как только сообщения обработаны, потребитель отправит подтверждение брокеру Kafka.
  • Как только Кафка получает подтверждение, он меняет смещение на новое значение и обновляет его в Zookeeper. Поскольку в Zookeeper поддерживаются смещения, потребитель может правильно прочитать следующее сообщение даже во время нарушения правил работы сервера.
  • Этот поток будет повторяться до тех пор, пока потребитель не остановит запрос.
  • Потребитель имеет возможность в любое время перемотать / перейти к нужному смещению темы и прочитать все последующие сообщения.

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

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

  • Производители регулярно отправляют сообщения в тему.
  • 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, и он обычно реплицирует эти данные по всему ансамблю, отказ брокера / Zookeeper Kafka не влияет на состояние кластера Kafka. Кафка восстановит состояние после перезагрузки Зоопарка. Это дает нулевое время простоя для Кафки. Выбор лидера между брокером Kafka также осуществляется с помощью Zookeeper в случае отказа лидера.

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

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

Leave a Reply

Your email address will not be published. Required fields are marked *