# Лабораторная работа №4 - Работа с брокером сообщений
**Цель**: изучение проектирования приложений при помощи брокера сообщений.
**Задачи**:
1. Установить брокер сообщений RabbitMQ.
2. Пройти уроки 1, 2 и 3 из [RabbitMQ Tutorials](https://www.rabbitmq.com/getstarted.html) на любом языке программирования.
3. Продемонстрировать работу брокера сообщений.
## Установка брокера сообщений RabbitMQ
Можно не использовать Docker и использовать локальный ПК.
[Страница скачивания RabbitMQ с офф. сайта](https://www.rabbitmq.com/download.html).
[Страница релизов RabbitMQ](https://github.com/rabbitmq/rabbitmq-server/releases/), где есть бинарные установщики для всех современных платформ.
## Прохождение tutorial
Достаточно для каждого урока скриншота, где виден запуск одновременно `producer` и `consumer`, а также видно, что сообщения передаются.
## Разработка демонстрационных приложений
См. 3 главу tutorial.
Необходимо выбрать предметную область и разработать следующие приложения:
1.**Publisher**.
Программа, которая создаёт один **exchange**с типом _fanout_.
Программа должна раз в секунду генерировать сообщения в журнал событий согласно вашей предметной области.
Например, событие "пришёл заказ" или "сообщение от пользователя" или "необходимо создать отчёт".
2.**Consumer 1**.
Программа, которая создаёт под себя отдельную не анонимную (!) очередь (**queue**) (то есть имя queue НЕ пустая строка), создаёт **binding** на **exchange** и начинает принимать сообщения (_consume_).
Программа должна обрабатывать сообщения 2-3 секунды.
Можно реализовать через обычный _Thread.Sleep_ (для C#).
3.**Consumer 2**.
Аналогично _Consumer 1_, только сообщения необходимо обрабатывать моментально.
Только имя очереди должно отличаться от _Consumer 1_.
Далее необходимо собрать и запустить приложения одновременно по одному экземпляру.
Сделать в отчёте вывод о скорости обработки _consumer_-ами событий от _publisher_-а.
Для этого можно посмотреть заполненность созданных очередей.
А для этого можно использовать скриншот из **RabbitMQ Management UI**.
Запустить несколько копий _Consumer 1_.
Проверить заново заполненность очередей через _UI_.
## Правила оформления pull request
Код и отчёт со скриншотами необходимо положить в папку `tasks/фамилия-инициалы/lab_4`.
Не забудьте о файле `.gitignore`, чтобы не закоммитить ничего лишнего.
Для C#-проектов это, например, папки `bin` и `obj`.
Правила именования ветки: `фамилия-инициалы-lab-номер`, например, `moiseev-vv-lab-4`.
Название pull request: `[Л/Р 4] ФАМИЛИЯ ИМЯ`, например, `[Л/Р 4] Моисеев Владислав`.
Написать небольшое эссе (буквально несколько абзацев) своими словами. А помогут Вам в этом вопросы из списка:
1. Зачем сложные системы (например, социальная сеть ВКонтакте) пишутся в "распределенном" стиле, где каждое отдельное приложение (или сервис) функционально выполняет только ограниченный спектр задач?
2. Для чего были созданы системы оркестрации приложений? Каким образом они упрощают / усложняют разработку и сопровождение распределенных систем?
3. Для чего нужны очереди обработки сообщений и что может подразумеваться под сообщениями?
4. Какие преимущества и недостатки распределенных приложений существуют на Ваш взгляд?
5. Целесообразно ли в сложную распределенную систему внедрять параллельные вычисления? Приведите примеры, когда это действительно нужно, а когда нет.
## Эссе
1. Зачем сложные системы (например, социальная сеть ВКонтакте) пишутся в "распределенном" стиле, где каждое отдельное приложение (или сервис) функционально выполняет только ограниченный спектр задач?
Во-первых, такие системы обрабатывают огромные объемы данных и высокие нагрузки, поэтому разделение функциональности между отдельными приложениями или сервисами позволяет более эффективно масштабировать и обрабатывать данные. Каждое приложение выполняет свою специфическую задачу, что позволяет легко масштабировать и модифицировать систему.
2. Для чего были созданы системы оркестрации приложений? Каким образом они упрощают / усложняют разработку и сопровождение распределенных систем?
Системы оркестрации приложений созданы для упрощения и управления разработкой и сопровождением распределенных систем. Они предоставляют средства для координации работы различных сервисов, обеспечивают управление состоянием, масштабирование и мониторинг системы. Это позволяет разработчикам концентрироваться на логике приложений, не беспокоясь о низкоуровневых деталях взаимодействия между сервисами. Однако, оркестрация приложений может усложнить разработку и требует дополнительных усилий по настройке и поддержке системы.
3. Для чего нужны очереди обработки сообщений и что может подразумеваться под сообщениями?
Очереди обработки сообщений играют важную роль в распределенных системах. Они служат для асинхронной коммуникации между компонентами системы и обеспечивают отказоустойчивость и гибкость в обработке данных. Сообщения могут представлять собой запросы на выполнение определенной задачи, информацию о событии или результаты выполнения действий. Очереди позволяют более гибко и эффективно управлять потоками данных и обеспечивать их последовательную обработку, даже при высоких нагрузках.
4. Какие преимущества и недостатки распределенных приложений существуют на Ваш взгляд?
Распределенные приложения имеют свои преимущества и недостатки. Они позволяют обрабатывать большие объемы данных, расширяться горизонтально и обеспечивать высокую отказоустойчивость. Однако, разработка и поддержка таких систем могут быть сложными и требовать специфических знаний. Также, распределенные системы могут страдать от проблем с консистентностью данных, синхронизацией и возникающими задержками в обработке.
5. Целесообразно ли в сложную распределенную систему внедрять параллельные вычисления? Приведите примеры, когда это действительно нужно, а когда нет.
Внедрение параллельных вычислений в сложную распределенную систему может быть целесообразным при определенных условиях. Рассмотрим несколько примеров, когда это может быть полезно и когда необходимость в этом отсутствует:
1. Обработка больших объемов данных: Если система работает с огромными объемами данных, параллельные вычисления могут значительно ускорить обработку. Например, в аналитической системе, которая агрегирует и анализирует большие объемы данных, параллельные вычисления помогут распределить нагрузку на несколько узлов и ускорить обработку данных.
2. Вычислительно интенсивные задачи: Если система выполняет вычислительно сложные операции или алгоритмы, параллельные вычисления могут значительно сократить время обработки. Например, в системе машинного обучения, где требуется обучение модели на большом объеме данных, параллельные вычисления позволят распределить вычислительную нагрузку между несколькими узлами и ускорить процесс обучения.
Однако, есть случаи, когда внедрение параллельных вычислений может быть излишним:
1. Простые операции: Если операции в системе относительно простые и не требуют значительных вычислительных ресурсов, то внедрение параллельных вычислений может быть излишним. Например, в системе управления пользователями, где требуется простая обработка запросов на создание, обновление или удаление пользователей, параллельные вычисления не приведут к значительному ускорению.
2. Необходимость в строгой последовательности: В некоторых случаях, система может требовать строгой последовательности выполнения операций. В таких случаях, параллельные вычисления могут нарушить эту последовательность и привести к нежелательным результатам. Например, в базе данных, где нужно манипулировать данными с использованием транзакций, параллельне вычисления могут нарушить целостность данных.
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
