Alexey/DAS_2024_1
2
7
Fork 1
Code Issues Pull Requests 80 Actions Packages Projects Releases Wiki Activity

kuzarin_maxim_lab_4 #34

Merged
Alexey merged 4 commits from kuzarin_maxim_lab_4 into main 2024-10-07 23:01:48 +04:00
Conversation 1 Commits 4 Files Changed 31 +4 -4
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit d7faf2a1b7 - Show all commits

8
kuzarin_maxim_lab_4/README.md
View File

@ -5,9 +5,9 @@
### "Hello World!"
![Task 1](Images/task1.png)
### Work Queues
![Task 2](Images\task2.png)
![Task 2](Images/task2.png)
### Publish/Subscribe
![Task 3](Images\task3.png)
![Task 3](Images/task3.png)
## Описание
Для демонстрационной работы была выбрана предметная область гипотетический системы обработки посылок. Имеется некий сканер, который отправляет устройству сведения через очереди (какие штрих-коды он отсканировал, или, если произошла какая-то ошибка - какая это ошибка).
## Запуск
@ -24,9 +24,9 @@ docker compose up -d --build
2. Тратит на обработку сообщения минимальное возможное время(условно - не тратит вообще ничего)
Так как производитель отправляет сообщения 1 раз в секунду, можно понять, что первый потребитель не справится с потоком сообщения, в то время как второй будет успевать обрабатывать их. На практике это подтверждается: очередь, куда из exchange попадают сообщения для первого потребителя только растёт(не справляемся с нагрузкой). В то время как у второго значения практически всегда - о.
<br/>
![Queue 1](Images\FirstService1.png)
![Queue 1](Images/FirstService1.png)
<br/>
![Queue 2](Images\SecondService.png)
![Queue 2](Images/SecondService.png)
<br/>
Учитывая описанное ранее, можно попробовать решить проблему первого сервиса за счёт горизонтального масштабирования. Теоретически должно хватить 3-х копий, чтобы сообщения не застаивались. На практике эта гипотеза подтвердилась. Очередь пусть и не пустеет, но не становится длиннее.
<br/>