предисловие
Я написал один раньше«Как элегантно использовать производителей Kafka из анализа исходного кода»Если есть производители, будут и потребители.
Рекомендуется, чтобы друзья, которые относительно плохо знакомы с Kakfa, могли сначала взглянуть.
Что касается моего опыта, то в большинстве случаев речь идет о роли потребителя ниже по течению данных. также использоватьKafkaЯ потреблял более 100 миллионов сообщений в день (должен восхищаться дизайном Kakfa), в этой статье будет использован мой опыт использования Kakfa для потребления данных, чтобы рассказать о том, как эффективно потреблять данные.
потребление одного потока
Возьмите в качестве примера код предыдущего производителя, подготовьтеTopic:data-push, 3 перегородки.
Сначала отправьте на него 100 сообщений, пользовательской стратегии маршрутизации нет, поэтому сообщения будут равномерно отправлены на три раздела.
Давайте сначала поговорим о простейшем однопоточном потреблении, как показано на следующем рисунке:
Поскольку данные хешируются в трех разных разделах, один поток должен пройти через три раздела, чтобы извлечь данные.
Пример кода для однопоточного потребления:
Этот код также можно найти на официальном сайте: процесс выборки данных в буфер памяти и, наконец, запись их в базу данных.
Не будем обсуждать, как подается зачет.
Это видно из журнала потребления:
100 извлеченных фрагментов данных действительно проходят через три раздела соответственно.
Хотя однопоточное потребление простое, оно имеет следующие проблемы:
- низкая эффективность. При наличии десятков или сотен разделов один поток не может эффективно извлекать данные.
- Доступность низкая. Как только поток-потребитель будет заблокирован или даже процесс зависнет, у всей программы-потребителя возникнут проблемы.
Многопоточное потребление
Поскольку с одним потоком возникает много проблем, можно ли использовать многопоточность для повышения эффективности?
До многопоточности нам приходилось делить режим потребления на два типа: группы потребителей и независимые потребители.
Способы обработки, соответствующие этим двум режимам потребления, сильно различаются, поэтому о них необходимо поговорить отдельно.
независимая потребительская модель
начать с独立消费者模式Говоря об этом, эта модель является относительно нишевой по сравнению с потребительскими группами.
Взгляните на простой пример, чтобы увидеть его использование:
Стоит отметить: Независимым Потребителям может не предоставлятьсяgroup.idАтрибуты.
Он также отправляет 100 сообщений, и результаты потребления следующие:
Это видно из API: мы можем вручную указать, какие разделы нужно потреблять.
Напримерdata-pushВ топике три раздела, вручную могу потреблять только 1 и 2 из них, а третий могу потреблять по ситуации.
В то же время он также поддерживает многопоточный режим, каждый поток использует для потребления указанный раздел.
Для наглядности отправляются только 10 фрагментов данных.
По результатам потребления видно, что:
Поток c1 принимает только 0-й раздел, c2 — только 1-й раздел, c3 — только данные 2-го раздела.
Даже мы можем развернуть потребительский мультипроцесс, такой метод потребления выглядит следующим образом:
ПредположениеTopic:data-pushКоличество разделов равно 4, тогда мы можем создать два процесса, как показано на рисунке.
В каждом процессе есть два потока, и каждый поток использует соответствующий раздел.
Таким образом, когда нашей производительности недостаточно, чтобы добавить количество разделов темы, потребителям нужно только расширяться по горизонтали таким образом, что очень гибко.
Этот настраиваемый метод использования разделов по-прежнему применим в некоторых сценариях, например, когда производитель отправляет данные определенного типа только в один раздел за раз. Таким образом, мы можем потреблять только для этого одного раздела.
Но у этого метода есть проблема: доступность не высока, когда один из процессов зависает, данные раздела, за который отвечает процесс, не могут быть переданы другим процессам для обработки.
модель группы потребителей
Групповой режим потребления должен быть наиболее часто используемым методом потребления.
Мы можем создать N экземпляров потребителей (new KafkaConsumer()), когда все эти экземпляры используют один и тот жеgroup.idКогда они создаются, они принадлежат к одной и той же группе потребителей.
Экземпляры-потребители в одной группе потребителей могут получать сообщения, но сообщения из раздела отправляются только одному экземпляру-потребителю.
Или используйте официальную диаграмму примера, чтобы лучше понять это.
Тема состоит из четырех разделовp0 p1 p2 p3, одновременно создавая две группы потребителейgroupA，groupB.
- В группе потребления A есть два экземпляра потребления.
C1、C2. - В группе потребления B есть четыре экземпляра потребления.
C3、C4、C5、C6.
Как сообщение делится на каждый экземпляр потребления?
Из рисунка видно, что:
- C1 в группе A использует разделы P0 и P3, C2 использует разделы P1 и P2.
- Группа B имеет четыре экземпляра, поэтому каждый экземпляр потребляет один раздел, то есть между экземплярами потребления и разделами существует однозначное соответствие.
нужно знать, это:
Пример потребления здесь может быть просто понят как
new KafkaConsumer,это не имеет никакого отношения к процессу.
Например, у топика три раздела, но я запускаю два процесса для его использования.
Каждый процесс имеет два экземпляра потребления, что фактически эквивалентно четырем экземплярам.
В это время вы можете спросить, как 4 экземпляра потребляют 3 раздела?
Самобалансирующаяся группа потребителей
Этот Кафка уже сделал это за меня, он будет использоваться в группе потребителей.Rebalance.
Например, в приведенном выше случае имеется 4 экземпляра потребления в 3 разделах, в итоге только три экземпляра должны иметь возможность получить сообщение. А вот какие три, Какфа автоматически назначит нам.
Посмотрите на пример, еще доdata-pushЭта тема состоит из трех разделов.
Когда один из процессов (в котором три потока, каждый поток соответствует экземпляру потребления), результаты потребления следующие:
Все 20 элементов данных в нем потребляются тремя экземплярами этого процесса.
В это время я запустил новый процесс, и программа точно такая же, как и выше; это эквивалентно одновременному наличию двух процессов и 6 экземпляров.
Я отправляю еще 10 сообщений и нахожу:
Процесс 1 извлек только две части данных из раздела 1 (ранее все данные были получены потоками в процессе 1).
В то же время процесс 2 потребляет оставшиеся 8 сообщений, которые являются данными разделов 0 и 2 (всего данные получают только три экземпляра, но они находятся в разных процессах).
Когда я отключу процесс 2 и отправлю еще 10 фрагментов данных, я обнаружу, что все данные снова потребляются тремя потоками в процессе 1.
Я считаю, что благодаря этим тестам вы уже можете увидеть преимущества потребительской группы.
Мы можем создать несколько экземпляров потребления в группе потребления для достижения высокой доступности и высокой отказоустойчивости, и не будет ситуации, когда данные не могут быть использованы после того, как один поток и независимые потребители зависнут. В то же время метод, основанный на многопоточности, также значительно повышает эффективность потребления.
И когда добавляется новый экземпляр потребления или экземпляр потребления зависаетKakfaДля нас будет перераспределена связь между экземпляром потребления и разделом, который называется группой потребления.Rebalance.
Предпосылки для этого, как правило, следующие:
- Добавьте экземпляр потребления в группу потребления.
- Экземпляр потребления в группе потребления не работает.
- Изменилось количество подписанных тематических разделов.
- Если это обычная подписка на тему, количество соответствующих тем также изменится.
Rebalance.
Поэтому рекомендуется потреблять данные таким образом, и масштабируемость тоже очень хорошая. Когда производительности недостаточно для добавления нового раздела, вам нужно только запустить новый экземпляр потребления и добавить его в группу потребления.
Суммировать
На этот раз я поделился только несколькими различными способами потребления данных и не сосредоточился на исследовании параметров потребления и исходного кода; если вам интересно это содержимое, вы можете поделиться им в следующий раз.
Часть исходного кода, упомянутого в статье, можно найти здесь:
Добро пожаловать, чтобы обратить внимание на публичный аккаунт, чтобы общаться вместе: