В моем приложении используется Spring + RabbitMQ. Он уже разработал две функции, отображающие пользователя & сообщения его друга на домашней странице & функция уведомлений для любого события, которое произошло.Создание новой очереди для каждой темы, созданной пользователем в приложении
Для этих двух функций у меня есть предопределенные очереди в конфигурации rabbitmq, привязанные к обмену. Основной шаблон - публикация подписки.
Теперь я смущен о дизайне третьей функции. Скажем, пользователь создает в разделе «Хэллоуин» & Русские пользователи подписываются на него. Аналогично, n пользователей создадут свои n тем & другие пользователи подпишут на него для получения обновлений. Это тоже шаблон pubsub.
Я считаю, что для каждой отдельной темы должна быть создана новая очередь. Итак, как мне динамически создать очередь для каждой темы, созданной пользователем в приложении? Или есть какой-то другой способ справиться с этим?
Ниже представлена существующая конфигурация очереди приложения.
<!-- Creates a queue for consumers to retrieve messages -->
<rabbit:queue name="UserPostpublishQueue" durable="true"/>
<!-- queue for sending notifications to users -->
<rabbit:queue name="notificationQueue" durable="true"/>
<!-- Fanout exchange for a pubsub bound to UserPostpublishQueue -->
<fanout-exchange name="broadcastPosts" durable="true" xmlns="http://www.springframework.org/schema/rabbit">
<bindings>
<binding queue="UserPostpublishQueue"/>
</bindings>
</fanout-exchange>
<!-- Direct exchange for a broadcasting notifications -->
<rabbit:direct-exchange name="broadcastNotifications" durable="true" xmlns="http://www.springframework.org/schema/rabbit">
<bindings>
<binding queue="notificationQueue" key="notifications"/>
</bindings>
</rabbit:direct-exchange>
Так Дерик если сохранить все только в БД не что ставить дополнительную нагрузку на БД, вместо опроса в очереди приложение будет опроса db для любых новых добавленных данных. Я понимаю, что очередь - это не база данных. Как насчет того, что я сохраняю данные в db, также имею общую или централизованную очередь для последних данных, если есть какие-то новые сообщения, которые она определенно будет нажимать на пользователя без необходимости опроса db. И мы всегда можем очистить старые данные из очереди. – underdog