2016-01-06 2 views
1

В моем приложении используется 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> 

ответ

2

Скажет, пользователь создает тема говорит «Хэллоуин» & п пользователей подписаться на него [...] Это тоже образец PubSub.

пока это «публикация» контента, а другие люди «подписываются» на этот контент, это не шаблон pub-sub.

шаблон pub-sub явно касается «бросить его по забору, кто заботится о том, кто слушает, если кто угодно». шаблон pub-sub - просто причудливый термин для типичных событий. Это означает, что кто-то сказал: «Эй! [Вещь]!» и другие люди реагируют каким-то образом, если им хочется реагировать. если конкретного человека нет, чтобы услышать, что это произошло, то и плохо. они не замечают, что это происходит. это как быть с друзьями. если одного из ваших друзей нет, то они не смогут «быть там» позже, когда они решат. они уже упустили эту возможность.

В вашей ситуации вы описываете газету или печатный журнал. контент публикуется для потребления другими людьми. абонент ожидает, что статьи и отчеты будут доставлены им в какой-то момент в будущем. если они не получат информацию, которую они обещали из журнала или газеты, они будут расстроены. они не должны «быть там» лично, когда происходят события. они получают отчет после того, как все происходит, и гарантируются (в какой-то степени) для получения отчета.

Я считаю, что для каждой отдельной темы должна быть создана новая очередь.

это очень плохая идея. вы очень быстро столкнетесь с серьезными проблемами производительности с размером и сложностью конфигурации и экземпляров RabbitMQ. Вы получите тысячи и тысячи очередей, которые редко используются, если они используются более одного раза.

Хуже всего то, что вы, скорее всего, будете обрабатывать очереди, как если бы они были базой данных. как только вы поймете, что вы не можете запросить очередь или прочитать одно и то же сообщение несколько раз, все быстро разваливается.

Как я могу динамически создать очередь для каждой темы, созданной пользователем в приложении?

Короткий ответ: не надо.

Или есть какой-то другой способ справиться с этим?

очередь сообщений - отличный способ для передачи данных между процессами. для этого используйте службы обмена сообщениями.

что вы хотите дизайн базы данных, где вы следить за тем, кто подписался на какое содержание и т.д.

все это следуя по линии вещей, которые я написал:

+0

Так Дерик если сохранить все только в БД не что ставить дополнительную нагрузку на БД, вместо опроса в очереди приложение будет опроса db для любых новых добавленных данных. Я понимаю, что очередь - это не база данных. Как насчет того, что я сохраняю данные в db, также имею общую или централизованную очередь для последних данных, если есть какие-то новые сообщения, которые она определенно будет нажимать на пользователя без необходимости опроса db. И мы всегда можем очистить старые данные из очереди. – underdog

Смежные вопросы