DAS_2024_1/kuzarin_maxim_lab_4/README.md
Кузярин Максим d7faf2a1b7 Обновить kuzarin_maxim_lab_4/README.md
Вот теперь картинки будут отображаться
2024-09-22 20:23:01 +04:00

40 lines
4.5 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Лабораторная работа 4
Данная работа посвящена работе с брокером сообщений RabbitMQ.
## Прохождение tutorial
Для каждого из уроков был создан отдельный проект, где в Program создаётся producer и concumer(s), а для подтверждения работоспособности использовалась консоль. Скриншоты подтверждения
### "Hello World!"
![Task 1](Images/task1.png)
### Work Queues
![Task 2](Images/task2.png)
### Publish/Subscribe
![Task 3](Images/task3.png)
## Описание
Для демонстрационной работы была выбрана предметная область гипотетический системы обработки посылок. Имеется некий сканер, который отправляет устройству сведения через очереди (какие штрих-коды он отсканировал, или, если произошла какая-то ошибка - какая это ошибка).
## Запуск
Для запуска лабораторной работы необходимо иметь запущенный движок Docker на устройстве.
Необходимо перейти в папку, где располагается данный файл. Далее открыть терминал и ввести команду:
```
docker compose up -d --build
```
Важно, чтобы в этот момент на компьютере был свободен порт 8081 и 5672.
Результаты работы системы можно простелить через Web GUI брокера(http://localhost:8081) или посмотрел логи контейнеров.
## Исследования
Первоначальный вариант запуска предполагает, что имеется всего 2 потребителя:
1. Тратит на обработку сообщения 2-3 секунды
2. Тратит на обработку сообщения минимальное возможное время(условно - не тратит вообще ничего)
Так как производитель отправляет сообщения 1 раз в секунду, можно понять, что первый потребитель не справится с потоком сообщения, в то время как второй будет успевать обрабатывать их. На практике это подтверждается: очередь, куда из exchange попадают сообщения для первого потребителя только растёт(не справляемся с нагрузкой). В то время как у второго значения практически всегда - о.
<br/>
![Queue 1](Images/FirstService1.png)
<br/>
![Queue 2](Images/SecondService.png)
<br/>
Учитывая описанное ранее, можно попробовать решить проблему первого сервиса за счёт горизонтального масштабирования. Теоретически должно хватить 3-х копий, чтобы сообщения не застаивались. На практике эта гипотеза подтвердилась. Очередь пусть и не пустеет, но не становится длиннее.
<br/>
![Queue 1 for 3 services](\Images\FirstService3.png)
## Видеодемонстрация
Был записан видеоролик, демонстрирующий процесс запуска и работы системы. Он расположен по [адресу](https://drive.google.com/file/d/1l7LXVXOb-oRNdS8aJGgeV7xbGCOpi1Es/view?usp=sharing)
Стоит отметить, что ошибки, которые были видны в логах сервисов связаны с относительно долгим стартом RabbitMQ (несмотря на depands_on брокер не усаапевает подняться, когда сервисы встают, и они не могут подключиться, из-за чего и падают. но из за политики перехапуска их раз за разом востанавливают, до тех пор пока брокер полностью не будет готов принимать сообщения)