diff --git a/kuzarin_maxim_lab_4/README.md b/kuzarin_maxim_lab_4/README.md index 13c7432..d62d232 100644 --- a/kuzarin_maxim_lab_4/README.md +++ b/kuzarin_maxim_lab_4/README.md @@ -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 попадают сообщения для первого потребителя только растёт(не справляемся с нагрузкой). В то время как у второго значения практически всегда - о.
-![Queue 1](Images\FirstService1.png) +![Queue 1](Images/FirstService1.png)
-![Queue 2](Images\SecondService.png) +![Queue 2](Images/SecondService.png)
Учитывая описанное ранее, можно попробовать решить проблему первого сервиса за счёт горизонтального масштабирования. Теоретически должно хватить 3-х копий, чтобы сообщения не застаивались. На практике эта гипотеза подтвердилась. Очередь пусть и не пустеет, но не становится длиннее.