Kafka изначально была распределенной системой обмена сообщениями с несколькими разделами, несколькими копиями и координируемой зоопарком, разработанной LinkedIn с использованием языка Scala и переданной в дар Apache Foundation. Это высокопроизводительная распределенная система обмена сообщениями публикации и подписки, которая широко используется благодаря своей горизонтальной масштабируемости и высокой пропускной способности. В настоящее время все больше и больше систем распределенной обработки с открытым исходным кодом, таких как Cloudera, Apache Storm, Spark, Flink и т. д., поддерживают интеграцию с Kafka.
Kafka в настоящее время поддерживает несколько клиентских языков: java, python, c++, php и т. д. Поддержка разных языков также может отражать популярность промежуточного программного обеспечения сообщений со стороны.
1. Создаем фон
Kafka — это система обмена сообщениями, первоначально разработанная в LinkedIn и используемая в качестве основы для LinkedIn Activity Stream и конвейеров обработки операционных данных. Сейчас его используют многиеразличные типы компанийИспользуются как многие типы конвейеров данных и систем обмена сообщениями.
- Данные потока активности: данные, связанные с поведением пользователей веб-сайта, такие как PV, UV и т. д. Такого рода данные обычно обрабатываются, сначала записывая различные действия в виде журналов в какой-то файл, а затем периодически выполняя статистический анализ этих файлов.
- Операционные данные: данные о производительности сервера (процессор, использование ввода-вывода, время запроса, журналы обслуживания и т. д.). Существует большое разнообразие статистических методов обработки оперативных данных.
Характеристики приведенных выше данных:
Данные неизменны
Массивные данные
нужна обработка в реальном времени
Традиционные системы обмена сообщениями плохо поддерживаются.
2. Цели дизайна
Kafka — это распределенная система обмена сообщениями, основанная на публикации/подписке. Основные цели дизайна следующие:
- Возможность сохранения сообщений обеспечивается с временной сложностью O(1), а производительность доступа с постоянной временной сложностью может быть гарантирована даже для данных выше уровня TB.
- Высокая пропускная способность, даже на очень распространенных коммерческих машинах, одна машина может поддерживать передачу более 100 тыс. сообщений в секунду.
- Поддерживать разделение сообщений и распределенное потребление между серверами Kafka, обеспечивая при этом последовательную передачу сообщений в каждом разделе.
- Поддержка автономной обработки данных и обработки данных в реальном времени, рекомендуемое чтение:Обработка больших данных в режиме реального времени и в автономном режиме
- Расширение уровня онлайн-поддержки
3. Зачем использовать систему обмена сообщениями
-
разъединение
Предсказать, с какими потребностями столкнется проект в будущем, в начале проекта крайне сложно. Система сообщений вставляет неявный уровень интерфейса на основе данных в середине процесса, и оба процесса должны реализовать этот интерфейс. Это позволяет вам независимо расширять или модифицировать оба процесса, если вы убедитесь, что они подчиняются одним и тем же ограничениям интерфейса.
-
избыточность
В некоторых случаях процесс обработки данных дает сбой. Он будет потерян, если данные не будут сохранены. Очереди сообщений позволяют избежать риска потери данных, сохраняя данные до тех пор, пока они не будут полностью обработаны. В парадигме «вставить-получить-удалить», используемой во многих очередях сообщений, перед удалением сообщения из очереди ваша система обработки должна явно указать, что сообщение было обработано, тем самым гарантируя, что ваши данные будут в безопасности. сделано с его помощью.
-
Расширяемость
Поскольку очереди сообщений отделяют вашу обработку, легко увеличить частоту постановки сообщений в очередь и обработки, добавив дополнительную обработку. Не нужно менять код, не нужно настраивать параметры. Расширение так же просто, как нажать кнопку питания.
-
Гибкость и пиковая обработка
В случае всплеска трафика приложение все равно должно продолжать функционировать, но такие всплески трафика не являются обычным явлением, несомненно, огромная трата ресурсов на то, чтобы быть в режиме ожидания в любое время в соответствии со стандартом способности справиться с таким пиковым трафиком. Использование очередей сообщений позволяет критически важным компонентам выдерживать внезапное давление доступа без полного сбоя из-за внезапных перегруженных запросов.
-
возмещаемость
Когда часть системы выходит из строя, это не влияет на всю систему. Очереди сообщений уменьшают связь между процессами, поэтому даже если процесс, обрабатывающий сообщение, зависает, сообщения, добавленные в очередь, могут быть обработаны после восстановления системы.
-
гарантия заказа
В большинстве случаев важен порядок обработки данных. Большинство очередей сообщений упорядочены по своей природе и гарантируют, что данные будут обрабатываться в определенном порядке. Kafka гарантирует порядок сообщений в разделе.
-
буфер
В любой критической системе будут элементы, требующие разного времени обработки. Например, загрузка изображения занимает меньше времени, чем применение фильтров. Очереди сообщений используют уровень буфера, чтобы помочь задачам выполняться наиболее эффективно — записи в очередь обрабатываются как можно быстрее. Эта буферизация помогает контролировать и оптимизировать скорость, с которой данные проходят через систему.
-
Асинхронная связь
Много раз пользователь не хочет или не должен обрабатывать сообщение немедленно. Очереди сообщений предоставляют механизмы асинхронной обработки, которые позволяют пользователям помещать сообщения в очередь, но не обрабатывать их немедленно. Поместите столько сообщений, сколько хотите, в очередь, а затем обработайте их по мере необходимости.
4. Обычное сравнение MQ
Redis
Redis — это база данных NoSQL, основанная на парах ключ-значение, с активной разработкой и обслуживанием. Хотя это система хранения базы данных типа "ключ-значение", она поддерживает функции MQ, поэтому ее можно использовать в качестве упрощенной службы очередей.
Для операций постановки в очередь и удаления из очереди RabbitMQ и Redis каждая выполняется 1 миллион раз, а время выполнения записывается каждые 100 000 раз. Эксперименты показывают, что:
| OP/MQ | Redis | RabbitMQ |
|---|---|---|
| Ставить в очередь ( | быстро | медленный |
| вне команды | быстро | медленный |
ActiveMQ
-
пиринговый:
Производитель отправляет сообщение в очередь, может получить только потребитель.
Когда нет доступных потребителей, сообщение удерживается до тех пор, пока не появится доступный потребитель.
Очередь может иметь много потребителей, и между ними достигается балансировка нагрузки.
Итак, Queue реализует надежную балансировку нагрузки.
-
Опубликовать/подписаться:
Сообщение, отправленное издателем в тему, получат сообщение только подписчики, подписавшиеся на тему.
В отличие от однорангового подхода, сообщения, опубликованные в теме, потребляются всеми подписчиками.
-
сомневаться
В режиме публикации-подписки можно ли реализовать потребление баланса нагрузки подписчика? Когда у издателя большое количество сообщений, очевидно, что вычислительной мощности одного подписчика недостаточно.
На самом деле, в реальном сценарии несколько абонентских узлов образуют группу подписки для балансировки нагрузки при потреблении тематических сообщений, то есть групповые подписки, чтобы подписчики могли легко добиться линейного расширения емкости потребления.
RabbitMQ
RabbitMQ реализует протокол AQMP, который определяет правила и методы маршрутизации сообщений. Производитель отправляет сообщения в разные очереди с помощью правил маршрутизации, а потребитель потребляет сообщения в соответствии с именем очереди. Кроме того, RabbitMQ ориентирован на потребителя.толкатьСообщения, отношения подписки и статус потребления хранятся на стороне сервера.
- пиринговый: производитель отправляет сообщение в очередь посредством маршрутизации, и только один потребитель может его использовать.
-
Опубликовать/подписаться:
Когда RabbitMQ необходимо поддерживать несколько подписок, сообщение, отправленное издателем, записывается в несколько очередей одновременно посредством маршрутизации, и разные группы подписки используют это сообщение.
RabbitMQ поддерживает как очереди памяти, так и постоянные очереди, а потребительтолкать модель, статус потребления и отношения подписки поддерживаются сервером.Сообщения удаляются сразу после потребления, а исторические сообщения не сохраняются. Поэтому при поддержке нескольких подписок сообщение будетнесколько копий.
Kafka
-
push/pull
Kafka поддерживает только сохранение сообщений, а потребительВытяните модель, статус потребления и отношения подписки поддерживаются на стороне клиента.После того, как сообщение будет использовано, оно не будет удалено немедленно, а исторические сообщения будут сохранены. Поэтому при поддержке нескольких подписок может храниться только одна копия сообщения.
Одна и та же группа подписки будет потреблять все сообщения темы, каждое сообщение будет потребляться только одним потребляющим узлом одной и той же группы подписки, а разные потребляющие узлы в одной и той же группе подписки будут потреблять разные сообщения.
-
характеристика:
быстрая настойчивость: Сохранение сообщений может выполняться с системными издержками O(1), и эта структура может поддерживать долгосрочную стабильную производительность даже для терабайт хранилища сообщений.
высокая пропускная способность: На обычном сервере может быть достигнута пропускная способность 10 Вт/с.
полностью распределенная система: брокер, производитель и потребитель изначально поддерживают распределение и автоматически обеспечивают балансировку нагрузки.
Поддержка параллельной загрузки данных Hadoop: это жизнеспособное решение для данных журналов и автономных систем анализа, таких как Hadoop, но требует ограничений обработки в реальном времени. Kafka объединяет онлайн- и офлайн-обработку сообщений с помощью механизма параллельной загрузки Hadoop.
5. Сценарии использования Кафки
-
Информация
Kafka является лучшей заменой традиционным системам обмена сообщениями, которые используются в различных сценариях (развязка производителей данных, кэширование необработанных сообщений и т. д.), по сравнению с большинством систем обмена сообщениями, Kafka имеет лучшую пропускную способность, встроенные функции секционирования, репликации и аварийного переключения, которые хорошо подходит для обработки крупномасштабных сообщений.
По нашему опыту, сообщения, как правило, используются для более низкой пропускной способности, но требуют низкой сквозной задержки и должны обеспечивать надежные гарантии надежности.
Kafka в этой области сравнима с традиционными системами обмена сообщениями, такими как ActiveMQ или RabbitMQ. -
Отслеживание активности на сайте
Первоначальный сценарий использования kafka: отслеживание действий пользователя, действия на веб-сайте (просмотр страниц, поиск или другая информация о работе пользователя) публикуются в различных тематических центрах, эти сообщения могут обрабатываться в режиме реального времени, отслеживаться в режиме реального времени или загружаться в Hadoop или offline для обработки базы данных.
Каждый просмотр страницы пользователем генерирует очень большой объем. -
показатель
Kafka также часто используется для мониторинга данных. Централизованное агрегирование статистики, генерируемой распределенными приложениями. -
Агрегация журналов
Используйте кафку вместо решения агрегации журнала. -
потоковая обработка
Обработка сообщений Kafka состоит из нескольких этапов. где исходные входные данные потребляются из темы kafka, а затем агрегируются, обогащаются или иным образом обрабатываются в новой теме, например, в рекомендуемой новостной статье, содержимое статьи может быть получено из темы «статьи»; тогда содержимое далее обрабатывается, чтобы получить обработанный новый контент, который, наконец, рекомендуется пользователю. Эта обработка основана на потоке данных в режиме реального времени по одной теме. Начиная с версии 0.10.0.0 такую обработку данных выполняет легкая, но мощная потоковая обработка.
Помимо Kafka Streams, на выбор есть Apache Storm и Apache Samza. -
коллекция событий
Коллекция событий — это стиль дизайна приложения, в котором изменения состояния записываются в соответствии с порядком времени, и kafka поддерживает этот очень большой сценарий хранения данных журнала. -
Журнал коммитов
Кафка может быть представлена в виде распределенного за пределами журнала, журнал помогает реплицировать данные между узлами и сбоями узла, что для восстановления ресинхронизации данных, сжатие KAFKA.