Эта статья была размещена GodPan вScalaCoolБлог команды.
Когда мы что-то изучаем, мы часто по-настоящему понимаем только значение, стоящее за этим, а затем мы можем осваивать это шаг за шагом, пока у нас не появится план. Для Кафки я тоже новичок.В этой статье я исследую Кафку с точки зрения новичка.Эта статья основана на официальных документах.Кстати, официальные документы действительно важны, так что читайте и берегите их.
задний план
Kafka была впервые разработана LinkedIn в качестве основы для собственной обработки бизнес-сообщений. После того, как LinkedIn пожертвовала Kafka для Apache, она стала проектом верхнего уровня Apache. Как высокопроизводительная распределенная система обмена сообщениями, Kafka в настоящее время используется в практическом бизнесе многими компаниями и сочетается со многими фреймворками обработки данных, такими как Hadoop, Spark и т. д.
система сообщений
В реальных бизнес-требованиях нам приходится иметь дело с различными сообщениями, такими как просмотр страниц, журналы, запросы и т. д. Итак, какие функции должна иметь хорошая система сообщений?
- Имеет функции публикации сообщений и подписки, аналогичные очередям сообщений или корпоративным системам обмена сообщениями;
- Может хранить поток сообщений и иметь отказоустойчивость;
- Возможность обработки сообщений в режиме реального времени;
Вышеупомянутые три пункта являются самыми основными возможностями хорошей системы сообщений.
Так почему же родился Кафка?
На самом деле, я считаю, что в нашей работе многие из них также подвергались воздействию очередей сообщений и даже написали простую систему сообщений, которая в основном должна иметь функцию публикации/подписки, как показано на следующем рисунке:
Среди них и потребитель A, и потребитель B подписываются на источник сообщений A и источник сообщений B. Этот режим очень прост, но он также имеет недостатки, такие как следующие два момента:
- В этом режиме потребители должны обрабатывать сообщения в режиме реального времени, потому что ни источник сообщений, ни потребитель не будут поддерживать очередь сообщений (стоимость обслуживания слишком высока), что приведет к потере сообщения, если потребитель временно не сможет потреблять.Конечно, также не может получить историческую информацию;
- Источник сообщения должен поддерживать работу, которая ему не принадлежит, например, ведение информации о подписчике (потребителе), отправка сообщений нескольким потребителям, или некоторую потребность в обработке обратной связи сообщения, которая является исходным источником чистого сообщения, будет становиться все более сложным;
Конечно, эти проблемы можно решить, например, добавить очередь сообщений между источником сообщений и потребителем, как показано на следующем рисунке:
Как видно из рисунка, теперь источнику сообщения нужно только отправить сообщение в очередь сообщений, а все остальное будет завершено очередью сообщений.Мы можем сохранять сообщение в очереди сообщений и активно пушить сообщение к сообщению, на которое была подписана Потребитель очереди, так есть ли недостатки у этого шаблона?
Ответ — да, на картинке выше — всего две очереди сообщений, поддерживать их нам несложно, но что, если их сотни или тысячи? Это не г. На самом деле, мы можем обнаружить, что функции очередей сообщений очень похожи, не более чем сохранение сообщений, отправка сообщений, предоставление обратной связи и другие функции, структура также очень похожа, в основном содержание сообщений, конечно, если вы хотите обобщить, структура сообщения также должна быть как можно более общей, независимой от конкретного языка конкретной платформы, например, с использованием формата JSON и т. д., поэтому мы можем развить следующую систему сообщений:
Этот метод, кажется, просто объединяет вышеуказанные очереди вместе, но это не так просто, потому что эта коллекция очередей сообщений должна иметь следующие функции:
- Он может управлять всеми очередями сообщений унифицированным образом, и это не является особым требованием, которое не требует от разработчиков его поддержки;
- Эффективно хранить сообщения;
- Потребители могут быстро найти сообщения, которые они хотят использовать;
Конечно, это только самые основные функции, такие как многоузловая отказоустойчивость, резервное копирование данных и т. д. Хорошая система сообщений должна справляться со многими вещами, благо Kafka нам в этом помог.
Kafka
Прежде чем разбираться в деталях Kafka, давайте взглянем на некоторые из ее основных концепций:
- Kafka работает в кластере, поэтому может иметь один или несколько сервисных узлов;
- Кластер Kafka хранит сообщения в определенных файлах, которые внешне выражаются как темы;
- Каждая запись сообщения содержит ключ, содержимое сообщения и отметку времени;
Из вышеперечисленных моментов можно примерно предположить, что Kafka — это распределенная система хранения сообщений, значит, только такая функция?Давайте продолжим рассмотрение следующего.
Чтобы иметь более мощные функции, Kafka предоставляет четыре основных интерфейса:
- Producer API позволяет приложениям публиковать сообщения в темах Kafka;
- Consumer API позволяет приложениям подписываться на темы в Kafka и получать сообщения;
- Streams API позволяет приложениям действовать как обработчики потока сообщений, например, получать сообщения из темы A и публиковать результаты обработки в теме B;
- API коннектора предоставляет функцию адаптации Kafka к существующим приложениям или системам, например коннектор базы данных, который может фиксировать изменения в структуре таблиц;
Их связь с кластером Kafka можно представить следующей схемой:
Поняв некоторые основные понятия Kafka, давайте взглянем на некоторые из его компонентов.
Topics
Как следует из названия, темы — это набор тем. В более общем смысле тема похожа на очередь сообщений. Производители могут писать в нее сообщения, а потребители — читать из нее сообщения. Тема поддерживает несколько производителей или потребителей для подписки на нее по адресу в то же время.Так что его масштабируемость очень хорошо. Тема может состоять из одного или нескольких разделов, как показано на следующем рисунке:
Сообщения в каждом разделе упорядочены, но взаимный порядок не может быть гарантирован.Если тема имеет несколько разделов, сообщения производителя могут быть указаны или размещены в указанном разделе системой в соответствии с алгоритмом.Если вам нужно, все сообщения упорядочены , так что лучше использовать только один раздел. Кроме того, раздел поддерживает чтение смещения сообщений, а перемещением сообщений управляют сами потребители, как показано на следующем рисунке:
Как видно из рисунка выше, разные потребители не мешают друг другу при чтении сообщений из одного раздела.Потребители могут контролировать данные, которые они хотят получить, задавая смещение сообщения.Например, они могут читать с начала и чтение последних данных., перечитывание и другие функции.
В последующих статьях о стратегии разделов Topic и балансе с потребителями будет подробно рассказано.
Distribution
Как упоминалось выше, Kafka — это распределенная система сообщений, поэтому, когда мы настраиваем несколько узлов Kafka Server, у него есть распределенные возможности, такие как отказоустойчивость и т. д. Разделы будут распределены на каждом узле Server, и в то же время есть еще один лидер. среди них, который будет обрабатывать все запросы на чтение и запись, а другие подписчики будут копировать информацию о данных на лидере.Если лидер не сможет предоставить услуги из-за некоторых сбоев, будет избран подписчик, который станет новым лидером для обработки этих Запросы.
Geo-Replication
Удаленное резервное копирование — это основная функция основных распределенных систем, которая используется для резервного копирования и восстановления данных в кластере.Кафка использует MirrorMaker для достижения этой функции, и пользователям нужно только настроить ее соответствующим образом.
Producers
Производители, как производители сообщений, могут сами указать, чтобы публиковать сообщения в указанные разделы в теме подписки, и политики могут быть указаны сами по себе.Например, сообщения с похожей семантикой или структурой публикуются в том же разделе, и, конечно , они также могут публиковаться системой циклически на каждом разделе.
Consumers
Потребители — это совокупность группы потребителей, которую можно назвать группой потребителей. Это абстракция более высокого уровня. Единица, которая подписывается на топик и потребляет сообщения, — это Потребители. Конечно, она также может иметь только одного потребителя ( потребитель). Вот два принципа о потребителях:
- Если все потребители находятся в одной группе получателей, то они будут координированно потреблять некоторые сообщения, подписанные на топик (распределенные по количеству разделов и получателей) для сохранения баланса нагрузки;
- Если все потребители находятся в разных группах потребителей и подписываются на одну и ту же тему, они смогут потреблять все сообщения этой темы;
Вот простой пример, который поможет вам понять:
На приведенном выше рисунке есть два узла Сервера, один Тема разделен на четыре раздела (P0-P4) и назначен двум узлам соответственно, а также есть две группы потребителей (GA, GB), из которых GA имеет два экземпляра Consumer, GB имеет четыре потребительских экземпляра.
Как видно из рисунка, первой единицей, которая подписывается на тему, является группа потребителей.Кроме того, мы обнаруживаем, что сообщения в теме рассылаются конкретным потребителям по определенным правилам.Основные принципы следующие:
- Если количество потребителей меньше количества разделов, а количество потребителей равно одному, то он потребляет все сообщения;
- Если количество потребителей меньше количества разделов, при условии, что количество потребителей равно N, а количество разделов равно M, количество разделов, которое может потреблять каждый потребитель, равно M/N или M/N+1;
- Если количество потребителей равно количеству разделов, то каждый потребитель будет в равной степени распределен по сообщениям раздела;
- Если количество потребителей больше, чем количество разделов, некоторые потребители не получат раздел сообщений и станут бездействующими;
Как правило, Kafka равномерно распределяет сообщения в соответствии с группой потребителей, например, когда есть сообщение о том, что экземпляр не работает, или когда присоединяется новый потребитель.
Guarantees
Как высокоуровневая система, Kafka предоставляет следующие гарантии:
- Сообщения добавляются по порядку.Чем раньше производитель отправит сообщение в тему, на которую подписан, тем раньше оно будет добавлено в тему.Конечно, они могут быть отнесены к разным разделам;
- Потребители упорядочиваются при потреблении сообщений в разделах темы;
- Для темы с N узлами-репликами система может выдержать до N-1 отказов узлов без потери сообщений, отправленных в тему;
Подробности этих моментов я планирую углубить в последующих статьях.
Kafka as a Messaging System
Сказав так много, я также рассказал об эволюции системы сообщений, так в чем же преимущества Kafka по сравнению с другими системами сообщений? Существуют две основные традиционные модели системы обмена сообщениями: очереди сообщений и публикация/подписка.
1. Очередь сообщений
| характеристика | описывать |
|---|---|
| Проявления | Группа потребителей получает сообщения из очереди сообщений, и сообщение будет отправлено одному из потребителей в группе. |
| Преимущество | Горизонтальное масштабирование, данные сообщения могут обрабатываться отдельно |
| недостаток | Очередь сообщений не является многопользовательской, когда запись сообщения читается процессом, сообщение будет потеряно |
2. Опубликовать/подписаться
| характеристика | описывать |
|---|---|
| Проявления | Сообщение рассылается всем потребителям |
| Преимущество | Сообщения могут совместно использоваться несколькими процессами |
| недостаток | Каждый потребитель получит все сообщения, и эффективность обработки нельзя повысить, добавив потребляющие процессы. |
Из приведенных выше двух таблиц мы можем увидеть преимущества и недостатки двух традиционных моделей системы сообщений, поэтому Kafka оптимизировалась на плечах предшественников и вобрала в себя их преимущества, в основном отраженные в следующих двух аспектах:
- Для достижения функции очереди сообщений через тему
- Таким образом, функция публикации/подписки достигается через группы потребителей.
Объединив эти два пункта (подробное описание этих двух пунктов см. в главе выше), Кафка прекрасно устраняет недостатки двух их режимов.
Kafka as a Storage System
Хранение сообщений также является основной функцией системы сообщений. По сравнению с обычным хранилищем очередей сообщений Kafka работает намного лучше. Прежде всего, Kafka поддерживает подтверждение записи для обеспечения правильности и непрерывности написания сообщений. данные, записанные на диск, будут скопированы и сохранены для обеспечения отказоустойчивости.Кроме того, Kafka использует ту же структуру для диска.То есть независимо от того, сколько данных сообщений ваш сервер в настоящее время хранит на диске, эффективность добавление данных сообщения такое же.
Механизм хранения Kafka позволяет потребителям свободно контролировать данные, которые им нужно читать.Во многих случаях вы также можете использовать Kafka в качестве высокопроизводительной распределенной файловой системы с малой задержкой.
Kafka for Stream Processing
Как представитель перфекционизма, Kafka не ограничивается наличием обычных функций, таких как чтение, запись и хранение, он также предоставляет интерфейс для обработки потоков сообщений в режиме реального времени.
Во многих случаях необработанные данные — это не то, что нам нужно. Нам нужны результаты обработки данных. Например, ключевые точки поиска дня можно получить из данных поиска дня. Вы можете использовать Streams API для достижения функции, которые вы хотите. , такие как получение данных из входной темы и публикация их в определенной выходной теме.
Потоковая обработка Kafka может решить такие проблемы, как обработка неупорядоченных данных, сложное преобразование данных и т. д.
Суммировать
Функции передачи сообщений, хранения и потоковой обработки действительно очень распространены в одном смысле, но то, как их идеально сочетать, является проявлением элегантности, Кафка добился этого.
По сравнению с распределенной системой хранения файлов HDFS, хотя она может поддерживать эффективное хранение и пакетные данные, она поддерживает только обработку прошлых исторических данных.
По сравнению с обычными системами сообщений, хотя она и может обрабатывать данные из настоящего в будущее, она не хранит исторические данные.
Кафка собирает сильные стороны многих семей, так что вся система может учитывать потребности всех аспектов.Одним словом можно сказать: «идеально»!
Эта статья начинается с эволюции системы сообщений, конкретного состава Кафки и, наконец, трех основных характеристик Кафки. Она призвана помочь каждому понять, что такое Кафка и что она делает. Конечно, это просто простой понимание новичка. , Если что-то не так в написании, я надеюсь, что все могут указать на это, я был бы признателен.