Служебная шина Azure - подписчики могут независимо подписаться на подписку и поделиться одним и тем же сообщением?

Когда вы создаете подписку на тему, у нее есть определенное имя подписки. Любой потребитель, который затем начинает запрашивать сообщения для этого имени подписки, будет конкурировать за сообщения по этой подписке. Если вы хотите, чтобы независимые приложения получали копию сообщения, отправленного в тему, каждое из них должно будет создать свою собственную подписку на эту тему. Вы можете почти просматривать каждую подписку как отдельную очередь, подпитываемую темой.

Я приведу пример колледжа. Тема - «Новый студент», и каждое отделение в колледже хочет получить копию сообщения для нового студента. Таким образом, у каждого отдела будет своя собственная подписка. Были бы подписки на «Музыка», «Биллингс», «Наука», «Математика» и т. Д. Каждый из них подписывался на тему «Новый студент». Таким образом, каждый отдел получает копию нового сообщения студента или даже может фильтровать то, что им интересно. Если отдел отстает в их обработке, он может развернуть больше экземпляров процессора, используя имя своей подписки, тем самым теоретически увеличивая пропускную способность, поскольку в этом случае больше потребителей конкурируют за сообщения в своей подписке.

Итак, в вашем примере каждому приложению нужно будет либо создать свою собственную подписку, либо ему будет назначена уникальная подписка, с которой можно будет получать данные при запуске. Обратите внимание, что если вы позволяете времени жизни приложения определять время жизни подписки (то есть вы создаете подписку при запуске приложения и уничтожаете ее при закрытии приложения), вам необходимо знать, что если нет активных подписок, то сообщения, отправленные в тему просто пропадет. Однако вы можете создать подписку для всех, которая будет получать только сообщения, которые не доставляются ни в одну другую подписку. Это действительно зависит от того, чего вы пытаетесь достичь.

Вам нужна не служебная шина, а концентратор событий. Концентратор событий работает именно так, как вы описали, и к нему также можно получить доступ с помощью AMQP.