.. | ||
.idea | ||
screens | ||
inventory_consumer.py | ||
order_processing_consumer.py | ||
publisher.py | ||
README.md |
Лабораторная работа №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
Consumer 1
Consumer 2
RabbitMQ Management UI
Вывод: по данным об очередях с RabbitMQ Management UI видно, что второй Consumer работает быстрее и ограничен лишь скоростью отправки сообщений, но если скорость отправки сообщений не будет ограничена, то возникает риск пропуска сообщений, а также такой метод сильнее нагружает систему и усложняет отслеживания работоспособности системы, что может привести к сбоям.
Видео
Видео с разбором лабораторной работы - https://youtu.be/8GOG8MyPkO4