ИССЛЕДОВАНИЕ ЭФФЕКТИВНОСТИ БРОКЕРОВ СООБЩЕНИЙ В ВЫСОКОНАГРУЖЕННЫХ РАСПРЕДЕЛЁННЫХ СИСТЕМАХ

​STUDYING THE EFFICIENCY OF COMMUNICATION BROKERS IN HIGHLY LOAD DISTRIBUTED SYSTEMS

Makarov Pavel Sergeevich

Master`s student, Institute of Informatics and Cybernetics, Samara National Research University,

Russia, Samara

Lezin Ilya Alexandrovich

Scientific supervisor, candidate of Technical Sciences, associate professor, Samara National Research University,

Russia, Samara

АННОТАЦИЯ

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

ABSTRACT

The problem of increasing the reliability and performance of an automated system for checking student papers by implementing an asynchronous architecture using a message broker is considered. A comparative analysis of three solutions Apache Kafka, RabbitMQ and NATS was conducted by key metrics: delivery delay, throughput, failure tolerance and resource intensity. Based on the results of experimental testing, a solution based on Apache Kafka was selected, demonstrating high reliability, scalability and stable operation under high load conditions.

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

Keywords: message broker, distributed systems, high load, asynchronous architecture, system performance, delivery latency, throughput, automated system.

Введение

Современные информационные системы всё чаще переходят к распределённым архитектурам, в которых взаимодействие между компонентами происходит через обмен сообщениями. Это особенно актуально для высоконагруженных приложений, функционирующих в условиях большого числа параллельных пользователей, высокой скорости обработки и требования к надёжности. Ключевым элементом таких архитектур становятся брокеры сообщений – программные компоненты, обеспечивающие буферизацию, маршрутизацию и доставку сообщений между модулями системы [1].

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

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

Цель работы

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

Предметная область

Брокер сообщений – это программный компонент, реализующий механизм передачи сообщений между различными частями программной системы в асинхронном режиме. Он выступает посредником между отправителем и получателем, обеспечивая буферизацию, маршрутизацию, доставку и, при необходимости, хранение сообщений. Брокеры сообщений широко применяются в архитектурах, построенных по принципу микросервисов, а также в распределённых и отказоустойчивых системах.

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

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

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

Общий алгоритм функционирования системы представлен на рисунке 1.

Объекты исследования

На современном этапе развития программных систем существует большое количество решений, реализующих функции брокера сообщений. В рамках данной работы для сравнительного анализа были выбраны три широко используемых решения: Apache Kafka, RabbitMQ и NATS.

Apache Kafka – это распределённый брокер сообщений, ориентированный на высокопроизводительную обработку потоков данных. Основан на логовой модели хранения (commit log), поддерживает репликацию, масштабирование и долговременное хранение сообщений. Обеспечивает высокую пропускную способность и надёжные гарантии доставки (at-least-once, exactly-once), что делает его подходящим для крупных систем с интенсивной передачей данных. Основными недостатками являются: высокая ресурсоёмкость и сложность настройки, особенно в кластерной конфигурации [2].

RabbitMQ – брокер сообщений, реализующий протокол AMQP и использующий модель очередей и обменников для маршрутизации. Отличается гибкостью, поддержкой множества протоколов и расширенными механизмами подтверждения доставки. Хорошо подходит для приложений с комплексной логикой передачи сообщений и потребностью в точном контроле за обработкой. Ограниченная масштабируемость и увеличивающиеся задержки при росте нагрузки делают RabbitMQ менее предпочтительным в высоконагруженных сценариях [3].

NATS – лёгкий брокер сообщений с минимальными задержками и простой архитектурой, реализующий модель publish-subscribe. Подходит для сценариев с высокой скоростью передачи коротких сообщений и ограниченными ресурсами. Расширение JetStream добавляет поддержку хранения и подтверждения доставки. NATS отличается простотой развёртывания и низкой ресурсоёмкостью, но требует дополнительных механизмов для обеспечения надёжности и менее гибок в маршрутизации по сравнению с Kafka и RabbitMQ [4].

Рисунок 1. Блок-схема алгоритма функционирования системы

Методика эксперимента

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

• создание трёх прототипов, реализующих одинаковую схему взаимодействия компонентов, но с использованием разных брокеров;
• сценарии нагрузочного тестирования, включающие типичную и пиковую нагрузку;
• метрики оценки, включающие: среднюю задержку (latency), пропускную способность (throughput), стабильность доставки, загрузку CPU и памяти RAM;
• тесты отказоустойчивости, включая кратковременное отключение компонентов;
• анализ результатов с формированием обоснованного вывода о наиболее подходящем решении.

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

Тестовая среда

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

Аппаратная конфигурация:

• Процессор: 4 виртуальных ядра (AMD Ryzen 5 3500U, 2.10 ГГц);
• Оперативная память: 8 ГБ;
• Сеть: виртуализированная, с полосой пропускания до 1 Гбит/с;
• Диск: SSD, объём 256 ГБ;
• Скорость диска: Чтение до 550 МБ/с, запись до 500 МБ/с.

Программное обеспечение:

• Операционная система: Windows 10 Pro, версия 2009;
• Язык программирования: Java 17;
• Среда разработки IntelliJ IDEA Ultimate 2023;
• Средство контейнеризации: Docker 24.0, Docker Compose 2.20;
• Средство имитации нагрузки: Postman Runner;
• Система управления БД: PostgreSQL 14;
• Хранилище данных: файловая система сервера (NTFS);
• Средство мониторинга ресурсов: Docker stats;
• Брокер сообщений: Apache Kafka, RabbitMQ, NATS.

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

1. Базовая нагрузка – измерение средней и пиковой задержки доставки при стабильной нагрузке со следующими параметрами:
2. 1 поставщик, 1 потребитель;
3. Объём: 10 000 сообщений по 1 КБ.
2. Рост нагрузки – измерение масштабируемости, изменение latency и потери сообщений со следующими параметрами:
3. От 1 до 5 поставщиков;
4. Общая нагрузка: от 1 000 до 50 000 сообщений в минуту.
3. Крупные сообщения – оценка влияния размера сообщений на производительность и стабильность работы со следующими параметрами при размере сообщений: 10 КБ, 100 КБ, 1 МБ;
4. Имитация отказа – оценка устойчивости, гарантии доставки и восстановление связи при принудительной останове брокера на 5 секунд во время работы;
5. Многопоточная обработка – оценка балансировки нагрузки и задержки при конкуренции за сообщения при нескольких параллельных обработчиках (2–4 потребителя).

В рамках тестовых сценариев собирались следующие метрики [6]:

Latency (avg) – средняя задержка доставки. Это среднее время от момента отправки сообщения до его обработки в милисекундах. Метрика может быть получена по формуле:

                                                                (1)

N – общее количество обработанных сообщений;

 – время получения/обработки i-го сообщения, мс;

– время отправки i-го сообщения, мс.

Throughput – пропускная способность. Это количество обработанных сообщений в секунду. Метрика может быть получена по формуле:

                                                                                             (2)

N – количество успешно обработанных сообщений;

T – продолжительность теста, с.

Loss Rate – доля потерь сообщений. Это процент сообщений, которые были отправлены, но не получены/обработаны. Метрика может быть получена по формуле:

                                                                              (3)

 – количество отправленных сообщений;

 – количество обработанных сообщений.

1763. /RAM utilization – среднее потребление вычислительных ресурсов. Это среднее арифметическое значение потребления CPU (процессор) и RAM (оперативная память) за период теста. Метрика может быть получена по логам системы мониторинга.

Процесс тестирования начинается с моделирование нагрузки через инструмент Postman Runner. В запросах передаются данные, моделирующие загружаемую на проверку студенческую работу. Это инициирует выполнение основного потока обработки в компоненте анализа, реализованном как Java-приложение и запущенном локально в среде IntelliJ IDEA.

Компонент анализа синхронно обрабатывает входные данные, выполняя предварительную проверку и формирование результатов. Эти результаты немедленно возвращаются пользователю в виде ответа на HTTP-запрос. Параллельно, компонент отправляет результат в брокер сообщений.

Брокер сообщений, развёрнутый в контейнере Docker, принимает результат и помещает его в очередь. Сообщение хранится в брокере до тех пор, пока его не обработает потребитель. Эта часть реализуется как отдельный компонент, подписанный на очередь и работающий в фоне. После получения сообщения потребитель извлекает данные и передаёт их для сохранения.

Результаты сохраняются в двух местах: метаданные и структурированная информация заносятся в базу данных PostgreSQL, а файлы – в локальную файловую систему сервера.

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

Диаграмма последовательности процесса тестирования представлена на рисунке 2.

Рисунок 2. Диаграмма последовательности процесса тестирования

Результаты экспериментов

На основании разработанной методики были проведены серии нагрузочных тестов с использованием трёх различных брокеров сообщений. Результаты экспериментов представлены в таблицах 1–4.

Таблица 1.

Средняя задержка доставки сообщений (Latency, мс)

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

Таблица 2.

Пропускная способность (Throughput, сообщений/сек)

Kafka и NATS обеспечивают высокую пропускную способность при масштабировании. RabbitMQ заметно уступает по этому показателю при росте нагрузки.

Таблица 3.

Потери сообщений (%)

Kafka обеспечивает надёжную доставку благодаря логовой модели хранения. RabbitMQ и NATS теряют сообщения без дополнительной настройки – для NATS требуется обязательное включение JetStream.

Таблица 4.

Потребление ресурсов (среднее при пиковом тесте)

Kafka – самое ресурсоёмкое решение. NATS минимально нагружает систему, что делает его подходящим для лёгких контейнерных развёртываний. RabbitMQ занимает промежуточную позицию.

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

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

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

NATS продемонстрировал минимальные задержки и отличную производительность при малых объёмах, с наименьшим потреблением ресурсов. Однако требует включения JetStream для достижения надёжности доставки.

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

Заключение

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

Для решения данной проблемы было проведено исследование эффективности трёх популярных брокеров сообщений Apache Kafka, RabbitMQ и NATS. В качестве прикладного примера использована автоматизированная система проверки студенческих работ, где брокер используется для асинхронной передачи результатов между модулями.

На основе разработанной методики были проведены нагрузочные тесты, показавшие, что Kafka обеспечивает наилучшие показатели по надёжности, масштабируемости и устойчивости при высоких нагрузках.

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

Список литературы:

1. Тарасов С. В., Власов И. И. Микросервисные архитектуры и брокеры сообщений: проектирование и эксплуатация. СПб.: Питер, 2022. – 336 с.
2. Apache Software Foundation. Kafka Documentation [электронный ресурс]. –URL: https://kafka.apache.org/documentation/ (дата обращения: 11.05.2025)
3. RabbitMQ Blog. Benchmarking RabbitMQ // Performance Testing Best Practices [Электронный ресурс]. – URL: https://www.rabbitmq.com/blog/2021/02/23/performance-testing-rabbitmq/ (дата обращения: 11.05.2025)
4. Synadia Communications. NATS Documentation [Электронный ресурс]. – URL: https://docs.nats.io/ (дата обращения: 11.05.2025)
5. Beyer B., Jones C., Petoff J., Murphy N.R. Site Reliability Engineering: How Google Runs Production Systems. O'Reilly Media, 2016. – 552 p*(По требованию Роскомнадзора информируем, что иностранное лицо, владеющее информационными ресурсами Google является нарушителем законодательства Российской Федерации – прим. ред.).