Я пытаюсь создать механизм повтора, который позволит пользователям воспроизводить сообщения из очередей. Лучший дизайн, который я придумал для обмена, который содержит несколько очередей и нескольких потребителей:
-
Создайте службу рекордера, которая будет:
- Создайте очередь и привяжите к ней все ключи маршрутизации.
- Потребляйте все сообщения из обмена.
- Сохранить все сообщения в БД.
-
Запрос подписчика на повтор.
- Каждый абонент создает новый обмен, очередь и привязывается к нему с теми же привязками, что и его очередная очередь.
- Абонент отправляет запросы на отдых на веб-сервер, чтобы начать воспроизведение с помощью фильтра (startdate и т.д.). Запрос содержит имя для обмена воспроизведением.
- Веб-сервер извлекает данные из БД и публикует их для конкретного обмена.
- уточнения могут быть добавлены как присоединение RequestId и повторение его обратно.
Вопросы:
1. Имеет ли это смысл?
2. Я изобретаю колесо? Есть ли решение для кроликов? плагин?
3. Является ли создание нескольких обменов хорошей практикой?
В этом решении для каждой очереди создается обмен для публикации того же сообщения.
Другое решение:
1. Создайте дополнительную очередь "ReplayQueue" для каждой очереди. установить TTL (допустим, месяц).
2. Каждый раз, когда пользователь запрашивает повтор, пусть он переигрывает из собственного ReplayQueue без выделения.
Это решение немного проблематично, потому что.
- Чтобы воспроизвести последний день, потребители должны будут получить все предыдущие 29 дней и отфильтровать их.
- Это решение масштабируется - очереди становятся больше (в отличие от хранилища db, которое может масштабироваться).