forked from Alexey/DAS_2024_1
40 lines
4.5 KiB
Markdown
40 lines
4.5 KiB
Markdown
# Лабораторная работа 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 брокер не усаапевает подняться, когда сервисы встают, и они не могут подключиться, из-за чего и падают. но из за политики перехапуска их раз за разом востанавливают, до тех пор пока брокер полностью не будет готов принимать сообщения)
|
||
|
||
|