Очередь сообщений против шины сообщений - в чем разница?
а они есть? Для меня MB знает как подписчиков, так и издателей и выступает в качестве посредника, уведомляя подписчиков о новых сообщениях (по сути, модель "push"). MQ, с другой стороны, является скорее моделью "вытягивания", где потребители вытягивают сообщения из очереди.
Я полностью сбился с пути?
5 ответов
по большому счету, когда дело доходит до программных продуктов поставщика, они используются взаимозаменяемо и не имеют сильных различий с точки зрения толчка или тяги, как вы описываете.
на автобус и очереди это действительно несколько устаревшая концепция, в последнее время вытекающая из таких систем, как IBM MQ и Tibco Rendezvous. MQ первоначально была Системой 1:1, Действительно, очередь для разделения различных систем.
Tibco, напротив, был (продан как) обмен сообщениями магистраль, где у вас может быть несколько издателей и подписчиков по одним и тем же темам.
однако оба (и более новые конкурирующие продукты) могут играть в пространстве друг друга в эти дни. Оба могут быть настроены на прерывание, а также опрос для новых сообщений. Оба опосредуют взаимодействие между различными системами.
фраза сообщений-очереди также используется для внутренних насосов сообщений внутри потока и тому подобное, и в этом контексте использование действительно, разные. Если вы думаете о классическом Windows message pump, это действительно больше модель тяги, которую вы описываете, но на самом деле это больше внутри приложения, чем между приложениями или между коробками.
Автобус Сообщением
на Автобус Сообщением - это инфраструктура обмена сообщениями, позволяющая различным системам общаться через общий набор интерфейсов(автобус сообщением).
источник: EIP
Очереди Сообщений
основная идея очереди сообщений - это просто один:
два (или более) процесса могут обмениваться информацией через доступ к общая системная очередь сообщений.
отправляющий процесс проходит через некоторый (OS) модуль передачи сообщений a сообщение в очередь, которое может быть прочитано другим процессом
источник: Дэйв Маршалл
разница
Очереди Сообщений содержит ФИФО(первый в первый выход) правило тогда как в Автобус Сообщением нет.
вывод
и посмотреть как делать такую же работу-передача сообщений между двумя приложения или модули или интерфейсы или системы или процессы, за исключением небольшой разницы ФИФО
основное отличие, которое на самом деле не было упомянуто явно в других ответах, заключается в том, что шина сообщений позволяет нескольким подписчикам, тогда как очередь будет удалять элементы один за другим к чему-либо, слушающему очередь. Если вы хотите, чтобы несколько слушателей видели одни и те же элементы, выходящие из очереди, вам придется обрабатывать это самостоятельно, служебная шина сделает это из коробки для вас.
произошло некоторое размывание линий между этими двумя понятиями, поскольку некоторые продукты теперь поддерживают функции, которые ранее принадлежали только к одной или другой категории (например, Azure Service Bus поддерживает оба подхода).
очереди
очередь сообщений получает сообщения от приложения и делает их доступными для одного или нескольких других приложений способом "первый в первом выходе" (FIFO). Во многих архитектурных сценариях, если приложение A необходимо отправить обновления или команды для приложений B и C, затем можно настроить отдельные очереди сообщений для B и C. A будет записывать отдельные сообщения в каждую очередь, и каждое зависимое приложение будет читать из своей собственной очереди (сообщение удаляется после удаления). Ни B, ни C не должны быть доступны для отправки обновлений. Каждая очередь сообщений является постоянной, поэтому, если приложение перезапускается, оно начнет вытягивать из своей очереди, как только оно вернется в сеть. Это помогает разбить зависимости между зависимые системы и могут снабдить большие масштабируемость и отказоустойчивость применения.
автобус
шина сообщений или служебная шина предоставляет возможность одному (или нескольким) приложению передавать сообщения одному или нескольким другим приложениям. Там не может быть никакой гарантии первого в первом из заказа, и абоненты на автобусе могут приходить и уходить без ведома отправителей сообщений. Таким образом, приложение A может быть написано для передачи обновлений статуса приложению B через a шина сообщений. Позже написано приложение C, которое также может воспользоваться этими обновлениями. Приложение C можно настроить для прослушивания шины сообщений и принятия мер на основе этих обновлений, а также без необходимости обновления приложения A. В отличие от очередей, где отправляющее приложение явно добавляет сообщения в каждую очередь, шина сообщений использует модель публикации/подписки. Сообщения публикуются в шине, и любое приложение, подписавшееся на такое сообщение, получит его. Этот подход позволяет приложениям следовать принципу "открыто/закрыто", поскольку они становятся открытыми для будущих изменений, оставаясь закрытыми для дополнительных изменений.
Я вижу это так, что очередь сообщений создает шину сообщений. Клиенты (т. е. узлы) могут прослушивать шину сообщений. Это особенно верно для случая, когда у вас есть MQ широковещательные сообщения через UDP, другими словами, он отправляет сообщения на широковещательный/многоадресный адрес, не зная или не заботясь, кто будет получать их. Для более подробного описания этого сценария вы можете проверить в этой статье.