Допустим есть несколько баз, каждая из которых слушает свою очередь, эти очереди подключены к точке обмена с типом fanout, если какая то из баз отправит сообщение в эту точку обмена, то ее очередь получить сообщение этой же базы, что не хотелось бы, можно ли как то на уровне сервера сказать, чтобы эта очередь не принимала сообщения по каким то критериям, например с определённым свойством «app_id»
Не принимать свои же сообщения
Дык не делайте fanout, сделайте direct или topic и на уровне ключей маршрутизации разрулите.
Ну это получается лишнее размножение сообщений. Т.е. база вместо того чтобы отправить одно сообщение будет отправлять равное количеству баз. А если сообщений не 1 а 1000 и баз тоже не 3 а 100 это получается базе вместо того чтобы отправить 1000 сообщений придется отправить 100000. А данные должны быть во всех этих базах.
Вариант добавить в сообщение ид отправителя и не обрабатывать свои сообщения тоже рассматривался…но хотелось бы понять возможно ли такое на уровне сервера сделать
Я не говорю про отправку нескольких сообщений. Оставьте одно сообщение, но смените тип точки обмена. Это позволит настроить маршрутизацию более гибко
Может я что то не понимаю, либо я как то задачу не так объяснил. Попробую еще раз
Есть несколько баз, есть данные которые должны быть во всех базах, например “номенклатура”, “номенклатуру” могут создавать в любой из баз и при этом она должна оказаться во всех остальных базах. При типе точки direct разослать сообщение всем и при этом отправить только одно сообщение, я пока вижу только один вариант это связывать очередь с точкой, разными ключами состоящими из комбинации идентификаторов каждой из баз, но тут при добавлении новой базы, это надо переделывать все связи с точкой или есть еще какие то варианты, которые очевидны, но я их не вижу, если есть возможность приведите пример.
Лучше так не формулировать, лучше сразу формулировать в виде потоков и имён
С ваших слов выходит коллизия
OneCBase -PUSH-> one-base-exchange
1 -(fanout)-> MANY <basename>.очередь
-SUBCRIBE-> <BaseName>
То есть у вас один отправитель и 100 получателей, куда вдруг начали отправлять 100 баз свои сообщения
То есть вы сделали так ?
<BaseName> -PUSH-> broacast-exchange
1 -(fanout)-> MANY <basename>.очередь
-SUBCRIBE-> <BaseName>
У вас в точку обмена может отправлять ЛЮБАЯ база ? и ЛЮБАЯ БАЗА имеет свою очередь связанной с ОБЩЕЙ точкой обмена
Верно ?
Да все так
Во первых напомню - RMQ он про слабую связанность, то есть производитель
Ну вообще-то так не делается
ИсточникСобытия - ОднаТочкаОбмена - МногоОчередейПолучателейЗаИсключениемИсточника
В вашем случае можно обойтись настройкой биндинга через WildCard
т.е. если допустим есть База1, База2, База3. Каждая из этих баз может слать сообщения в любую из других, т.е. База1-> База2, База1-> База3, База2 -> База1, База2 -> База3 и т.д. и т.п.
то правильно делать
База1 - ТочкаДирект1 - ОчередьБаза2
База1 - ТочкаДирект1 - ОчередьБаза3
База2 - ТочкаДирект2 - ОчередьБаза1
База2 - ТочкаДирект2 - ОчередьБаза3
и т.д.
или все таки можно
База1 - ОбщаяТочкаДирект - ОчередьБаза2
База1 - ОбщаяТочкаДирект - ОчередьБаза3
База2 - ОбщаяТочкаДирект - ОчередьБаза1
База2 - ОбщаяТочкаДирект - ОчередьБаза3
и т.д.
или вообще надо делать так
База1 - ТочкаДирект1 - ОчередьБаза12
База1 - ТочкаДирект1 - ОчередьБаза13
База2 - ТочкаДирект2 - ОчередьБаза21
База2 - ТочкаДирект2 - ОчередьБаза23
и т.д.
Пользуемся подобной схемой: один отправитель шлет в свой эксчендж, на который по ключу могут быть подписано N очередей получателей. В итоге одно сообщение размножается при необходимости средствами самого RabbitMq.