Начиная! Народный язык знакомит вас с Кафкой

предисловие

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

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

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

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

экстремальная производительность: Основанный на разработке на языке Scala и Java, проект использует множество идей пакетной обработки и асинхронности и может обрабатывать до десятков миллионов сообщений в секунду.
Непревзойденная совместимость с экосистемами: совместимость Kafka с окружающей экосистемой — одна из лучших, особенно в области больших данных и потоковых вычислений.

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

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

Знакомство с Кафкой

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

Из официального введения мы можем получить следующую информацию:

Kafka — это распределенная стриминговая платформа. Что именно это означает?

Потоковая платформа имеет три ключевые возможности:

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

У Kafka есть два основных сценария применения:

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

Несколько очень важных концепций о Кафке:

Kafka хранит потоки записей (потоковые данные) вtopicсередина.
Каждая запись состоит из ключа, значения и метки времени.

Модель сообщения Кафки

Отступление: ранние версии JMS и AMQP относятся к соответствующим стандартам, разработанным авторитетными организациями в области служб сообщений.JavaGuideиз«Очереди сообщений на самом деле очень просты»описано в этой статье. Однако эволюция этих стандартов не поспевает за эволюцией очередей сообщений, и эти стандарты фактически находятся в заброшенном состоянии. Поэтому возможна ситуация, когда разные очереди сообщений имеют свой набор моделей сообщений.

Модель очереди: ранняя модель обмена сообщениями

Очередь используется в качестве средства передачи сообщений для удовлетворения модели производитель-потребитель.Сообщение может быть использовано только одним потребителем, а неиспользованные сообщения сохраняются в очереди до тех пор, пока они не будут использованы или истечет время ожидания.Например: если наш производитель отправляет 100 сообщений, их будут потреблять два потребителя. Как правило, два потребителя будут потреблять половину каждого сообщения в том порядке, в котором они отправляются (то есть мы с вами будем потреблять по одному).

Проблемы с моделью очереди

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

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

Модель публикации-подписки: модель сообщений Kafka

Модель публикации-подписки в основном предназначена для решения проблем модели очереди.

Модель публикации-подписки (Pub-Sub) используетТемаКак носитель сообщений, аналогичныйрежим трансляции; издатель публикует сообщение, которое доставляется всем подписчикам через тему,Пользователи, подписавшиеся после трансляции сообщения, не получат его..

В модели публикации-подписки, если есть только один подписчик, это в основном то же самое, что и модель очереди. Таким образом, модель публикации-подписки функционально совместима с моделью очереди.

Kafka использует модель публикации-подписки.

Модель сообщений RocketMQ в основном такая же, как у Kafka. Разница лишь в том, что в Kafka нет понятия очереди, которое соответствует Partition.

Интерпретация важных понятий Кафки

Кафка отправляет сообщения, опубликованные производителями,Тема, потребители, которым нужны эти сообщения, могут подписаться на этиТема,Как показано ниже:

Приведенная выше картина также приводит нас к нескольким важным концепциям Кафки:

Режиссер: Сторона, создавшая сообщение.
Потребитель: Сторона, принимающая сообщение.
Маклер: можно рассматривать как независимый экземпляр Kafka. Несколько брокеров Kafka образуют кластер Kafka.

В то же время вы, должно быть, заметили, что каждый Брокер содержит два важных понятия: Тема и Раздел:

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

Фокус:Раздел в Kafka может фактически соответствовать очереди в очереди сообщений. Не лучше ли понять?

Кроме того, еще один момент, который я считаю более важным, заключается в том, что Kafka ввела механизм многократного копирования (Replica) для раздела (Partition). Между несколькими репликами в разделе будет человек, называемый лидером, а остальные реплики называются последователями. Сообщения, которые мы отправляем, отправляются на ведущую реплику, а затем ведомые реплики могут получать сообщения от ведущей реплики для синхронизации.

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

Каковы преимущества механизма Kafka с несколькими разделами (Partition) и несколькими копиями (Replica)?

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

Роль смотрителя зоопарка в Кафке

Чтобы понять роль zookeeper в Kafka, вы должны создать среду Kafka, а затем войти в zookeeper, чтобы увидеть, какие папки связаны с Kafka и какая информация хранится в каждом узле.Не смотрите без практики, так вы со временем забудете то, чему научились!

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

Эта часть содержания ссылается на эту статью и опирается на нее:Woohoo.Краткое описание.com/afraid/ah 036405 отправить 9….

На картинке ниже показан мой локальный Zookeeper, который успешно связан с моей локальной Kafka (следующая структура папок реализована с помощью подключаемого модуля idea Zookeeper).

ZooKeeper в основном предоставляет функции управления метаданными для Kafka.

Как видно из рисунка, Zookeeper в основном делает для Kafka следующее:

Регистрация брокера: Будет посвященИспользуется для записи списка серверов брокераузел. Когда каждый брокер запускается, он регистрируется в Zookeeper, то есть создает свой собственный узел в каталоге /brokers/ids. Каждый брокер будет записывать свой собственный IP-адрес и информацию о порте для узла.
Регистрация темы: У Кафки то же самоеТематические сообщения будут разделены на несколько разделови распространять его на нескольких брокеров,Эта информация о разделе и соответствующие отношения с БрокеромОни также поддерживаются Zookeeper. Например, я создал тему с именем my-topic и в ней есть два раздела, соответствующие этим папкам будут созданы в zookeeper:/brokers/topics/my-topic/Partitions/0,/brokers/topics/my-topic/Partitions/1
балансировки нагрузки: Как упоминалось выше, Kafka назначает несколько разделов для определенной темы, и каждый раздел может быть распределен на разных брокерах, что может обеспечить лучшие возможности параллелизма. Для разных разделов одной и той же темы Kafka попытается распределить эти разделы по разным серверам брокера. Когда производитель сгенерирует сообщение, он попытается доставить его в раздел разных брокеров. Когда потребители потребляют, Zookeeper может выполнять динамическую балансировку нагрузки на основе текущего количества разделов и количества потребителей.
......

Как Kafka гарантирует порядок потребления сообщений?

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

Мы знаем, что Partition в Kafka — это место, где действительно сохраняются сообщения, и все сообщения, которые мы отправляем, помещаются сюда. А наш Partition (раздел) существует в понятии Topic (топик), и мы можем указать несколько Partitions для конкретного Topic.

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

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

Поэтому у нас есть очень простой способ обеспечить порядок потребления сообщений:1 тема соответствует только одному разделу. Это, конечно, решает проблему, но противоречит цели замысла Кафки.

При отправке сообщения в Kafka можно указать четыре параметра: тема, раздел, ключ и данные (данные). Если вы укажете Раздел при отправке сообщения, все сообщения будут отправлены в указанный Раздел. Более того, сообщения с одним и тем же ключом можно отправлять только в один и тот же раздел, а в качестве ключа мы можем использовать id таблицы/объекта.

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

Одна тема соответствует только одному разделу.
(Рекомендуется) Укажите ключ/раздел при отправке сообщений.

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

Рекомендуемое чтение

Apache Kafka с использованием ключей для раздела:Linux hint.com/Apache_Kafka…
Spring Boot и Kafka — практические примеры конфигурации:практический developer.com/2018/11/24/…
Статья, чтобы понять шесть лет больших изменений в области больших данных:woo woo woo.info Q. талант/статья/номер 8*…

публика