Статья также доступна на украинском (перейти к просмотру).

Оглавление

• Общие подходы к определению критериев качества работы брокеров сообщений
• Скорость обработки сообщений
• Балансировка нагрузки
• Репликация данных
• Персистентность данных
• Горизонтальное масштабирование и отказоустойчивость
• Гибкость при работе с сообщениями
• Безопасность использования
• Работа с Apache Pulsar в рабочей среде
• Системные требования
• Развертывание программы
• Работа с темами
• Выводы

В преыдущей статье мы уже рассматривали характеристики и вопросы практического использования современного брокера сообщений Apache Kafka. Достойной альтернативой ему может стать брокер Apache Pulsar, сопровождаемый Apache Software Foundation. Оба брокера нацелены на использование в распределённых системах публикации сообщений с подпиской и являются лидерами по ряду характеристик по сравнению с другими программными средствами этого сегмента. Однако между ними самими существует немало отличий, которые делают Pulsar более совершенным. Рассмотрим сравнительную характеристику брокеров для реализации в нашей модели распределенной системы, а также продемонстрируем процесс установки Apache Pulsar на VPS-сервер Ubuntu.

Общие подходы к определению критериев качества работы брокеров сообщений

Выбор критериев будет зависеть от целей использования и конфигурации распределенной системы. И потому важно остановиться на какой-либо конкретной модели для того, чтобы определиться с критериями или требованиями к работе брокеров.

Будем исходить из того, что сервис должен работать в высоконагруженный распределенной системе с неограниченным количеством потенциальных потребителей сообщений (Consumer) и издателей (Producer). Ее архитектура будет ориентирована на случаи. Это, например, может быть любая конвейерная или транзакционная система. Определим по отношению к ней основной список требований к работе брокера сообщений:

Большая скорость обработки сообщений;

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

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

Скорость обработки сообщений

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

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

• Кластерная организация;
• Кэширование сообщений перед отправкой;
• Использование партиций;
• Пакетная обработка сообщений (батчи другие средства);
• Отдельное хранение метаданных кластера с помощью службы ZooKeeper.

Эти и некоторые другие механизмы позволяют сервису иметь указанное значение скорости.

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

• Использование брокеров без сохранения состояний;
• Многослойность архитектуры;
• Усовершенствованный механизм партиций;
• Другие решения, прямо или косвенно повышающие скорость работы сервиса.

Следует отметить, что сервис RabbitMQ способен обрабатывать около 50 тыс. сообщений в секунду в зависимости от конфигурации системы. Очевидно, что такое значение может быть достаточным только в случае небольшого потока данных, а значит, сервис не подходит для использования в нашей модели распределенной системы. И потому он не будет нами рассматриваться в дальнейшем в качестве конкурента другим сервисам, а будет сконцентрированная внимание на двух похожих по сути брокерах – Kafka и Pulsar.

Балансировка нагрузки

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

У Kafka отсутствует устроенный механизм обеспечения автоматической балансировки нагрузки. Но его можно «сконфигурировать» с помощью посторонних средств, например, таких, как rebalancer от компании Confluent и некоторые другие.

У Pulsar указанный механизм есть. Это становится возможным за счет использования брокеров без сохранения состояния, которое можно добавлять при возникновении перегрузок в пределах кластера или экземпляра и перенаправлять на них новых клиентов. Очевидно, такой подход гораздо лучше, чем у конкурента.

Репликация данных

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

Kafka использует механизм синхронизации данных типа follow-the-leader, согласно которой исходное сообщение всегда хранится на главном узле (leader), а все зависящие от него узлы или клиенты сохраняют его копии. Здесь использована иерархическая структура, при которой окончательное решение об обновлении данных принимает исключительно главный узел. Для этого задержка может быть значительной.

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

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

Персистентность данных

Обеспечение персистентности данных в работе распределенной системы позволяет иметь постоянный доступ к ним независимо от времени их хранения. К примеру, обеспечение длительного хранения истории банковских транзакций является необходимым условием ее функционирования. Конечно, уровень персистентности может быть разным, и чем он выше, тем лучше. Однако за это нужно «оплачивать» ресурсы, к которым, в частности, можно отнести емкость SSD-дисков или других устройств хранения данных.

Оба брокера обеспечивают определенный уровень персистентности, однако в Pulsar он значительно выше, в частности, за счет использования многоуровневого хранилища с возможностью подключения внешних хранилищ данных. Это позволяет в автоматическом режиме перемещать значительные объемы уже «использованных», то есть прочитанных сообщений почти безграничных и дешевых облачных хранилищ. Такая опция отсутствует у Kafka и потому этот сервис здесь проигрывает.

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

Горизонтальное масштабирование и отказоустойчивость

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

В то же время ничто не мешает производить масштабирование и по отношению к хранилищу и это никак не повлияет на работу брокеров. То есть масштабирование здесь возможно одновременно в двух плоскостях.

Как известно, чем выше уровень масштабирования, тем более высок уровень отказоустойчивости имеет распределенная система. Это означает, что Pulsar является более стойким по отношению к сбоям.

Гибкость при работе с сообщениями

Гибкость или ориентированность распределенной системы на потребителя (конс’юмера), как правило, приветствуется. В этом смысле Pulsar имеет ряд усовершенствований, что дает основания утверждать о его более высоком уровне гибкости по сравнению с конкурентом. Рассмотрим это.

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

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

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

Безопасность использования

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

Среди рассматриваемых брокеров только Pulsar поддерживает сквозное шифрование. На данный момент его применение возможно при наличии Java-клиента.

Работа с Apache Pulsar в рабочей среде

Рассмотрим требования к программной среде, процесс установки программы и основные шаги по работе с ней.

Системные требования

Информация о системных требованиях к версии JVM для установки той или иной версии приложения можно посмотреть здесь. Общие требования нами сведены в Таблице 1.

Таблица 1. Системные требования к установке и работе Apache Pulsar.

Версия программі	Версия и тип JRE/JDK	ОС сервера	ОП сервера, Gb	Автоматизация сборки проектов
<= 2.10	11	64-bit macOS, Linux, Windows (при наличии Docker)	4	3.6.Maven 1+
> 2.10	17

Наш сервер имеет значения ОП не меньше, чем указанные в Таблице 1, 64-битную версию ОС Ubuntu и соответствующее версию Maven.

Развертывание программы

Для того чтобы решить какую версию программы мы можем установить на сервер, выясним какая версия библиотек JRE/JDK есть на данный момент на нашем сервере. Для этого введем в терминале:

$ java -version

Результат:

OpenJDK Runtime Environment (build 11.0.22+7-post-Ubuntu-0ubuntu222.04.1)
OpenJDK 64-Bit Server VM (build 11.0.22+7-post-Ubuntu-0ubuntu222.04.1, mixed mode, sharing)

Это значит, что мы можем установить версию Apache Pulsar 2.10.3 или старше.

Перед тем обновим индекс пакетов с помощью следующей команды:

$ sudo apt update

Загрузим официальный дистрибутив программы. Для этого введем в терминале:

$ wget https://archive.apache.org/dist/pulsar/pulsar-2.10.3/apache-pulsar-2.10.3-bin.tar.gz

Результат:

apache-pulsar-2.10.3-bin.tar.gz 100%[=======================================================>] 334.68M  7.90MB/s   in 32s

Итак, файл успешно загружен. Распакуем его:

$ tar xvfz apache-pulsar-2.10.3-bin.tar.gz

В результате выполнения команды был создан корневой каталог программы. Перейдем к нему:

$ cd apache-pulsar-2.10.3

Просмотрим содержимое каталога apache-pulsar-2.10.3, чтобы выяснить, какие системные директории и файлы были созданы:

$ ls -1F

Выход команды:

bin/
conf/
examples/
instances/
lib/
LICENSE
licenses/
NOTICE
README

На следующем этапе развертывания сервиса запустим автономный кластер Pulsar. Это можно сделать с помощью следующей команды:

$ bin/pulsar standalone

При запуске кластера программа создает дополнительно еще две директории: Data и Logs. В первой из них будут храниться все данные, созданные BookKeeper и RocksDB. Во второй будут храниться все журналы на стороне сервера.

Кроме того, автоматически создается общее пространство имен public/default, предназначенный для разработчиков.

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

$ bin/pulsar-daemon start standalone

Работа с темами

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

Для создания темы обычно используется следующая команда:

$ bin/pulsar-admin topics create persistent://public/default/my-topic

Где my-topic – имя нужной темы.

Для создания сообщения в выбранной теме следует воспользоваться следующей конструкцией:

$ bin/pulsar-client produce my-topic --messages 'What's new?'

При этом Pulsar переходит в режим прослушивания, что видно по виду приглашения командной строчки (см. скрин выше). Для выхода из указанного режима необходимо одновременно нажать комбинацию клавиш ctrl+C.

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

$ bin/pulsar-client consume my-topic -s 'my-subscription' -p Earliest -n 0

Формат вывода содержимого будет следующим:

----- got message -----
 key:[null], properties:[], content: What's new?

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

$ bin/pulsar-client produce my-topic --messages "$(seq -s, -f 'Mess New.%g' 1 10)"

Выводы

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

Подписывайтесь на наш телеграмм-канал https://t.me/freehostua, чтобы быть в курсе новых полезных материалов.

Смотрите наш канал Youtube на https://www.youtube.com/freehostua.

Мы в чем ошиблись, или что-то пропустили?

Напишите об этом в комментариях, мы с удовольствием ответим и обсуждаем Ваши замечания и предложения.

Дата: 17.04.2024 Автор: Александр Ровник #cqrs#devops#programming#ubuntu

Голосование 1 2 3 4 5