DAS_2023_1/savenkov_alexander_lab_4
2024-01-18 11:38:57 +04:00
..
.idea savenkov_alexander_lab_4_ready 2024-01-18 11:38:57 +04:00
screens savenkov_alexander_lab_4_ready 2024-01-18 11:38:57 +04:00
inventory_consumer.py savenkov_alexander_lab_4_ready 2024-01-18 11:38:57 +04:00
order_processing_consumer.py savenkov_alexander_lab_4_ready 2024-01-18 11:38:57 +04:00
publisher.py savenkov_alexander_lab_4_ready 2024-01-18 11:38:57 +04:00
README.md savenkov_alexander_lab_4_ready 2024-01-18 11:38:57 +04:00

Лабораторная работа №4 - Работа с брокером сообщений

Цель: изучение проектирования приложений при помощи брокера сообщений.

Задачи:

Необходимо выбрать предметную область и разработать следующие приложения:

Publisher. Программа, которая создаёт один exchange с типом fanout. Программа должна раз в секунду генерировать сообщения в журнал событий согласно вашей предметной области. Например, событие "пришёл заказ" или "сообщение от пользователя" или "необходимо создать отчёт". Consumer 1. Программа, которая создаёт под себя отдельную не анонимную (!) очередь (queue) (то есть имя queue НЕ пустая строка), создаёт binding на exchange и начинает принимать сообщения (consume). Программа должна обрабатывать сообщения 2-3 секунды. Можно реализовать через обычный Thread.Sleep (для C#). Consumer 2. Аналогично Consumer 1, только сообщения необходимо обрабатывать моментально. Только имя очереди должно отличаться от Consumer 1. Далее необходимо собрать и запустить приложения одновременно по одному экземпляру.

Сделать в отчёте вывод о скорости обработки consumer-ами событий от publisher-а. Для этого можно посмотреть заполненность созданных очередей. А для этого можно использовать скриншот из RabbitMQ Management UI.

Запустить несколько копий Consumer 1. Проверить заново заполненность очередей через UI.

Publisher

Код Publisher

Работа Publisher

Consumer 1

Код Consumer 1

Работа Consumer 1

Consumer 2

Работа Consumer 2

RabbitMQ Management UI

До запусков Consumer

После запуска Consumer 1

После запуска Consumer 2

Вывод: по данным об очередях с RabbitMQ Management UI видно, что второй Consumer работает быстрее и ограничен лишь скоростью отправки сообщений, но если скорость отправки сообщений не будет ограничена, то возникает риск пропуска сообщений, а также такой метод сильнее нагружает систему и усложняет отслеживания работоспособности системы, что может привести к сбоям.

Видео

Видео с разбором лабораторной работы - https://youtu.be/8GOG8MyPkO4