А чи є такі? Для мене МБ знає як передплатників, так і видавців і виступає посередником, повідомляючи передплатникам про нові повідомлення (фактично модель "push"). З іншого боку, MQ - це швидше модель "витягування", коли споживачі витягують повідомлення з черги.
Я тут зовсім з дороги?
Відповіді:
Загалом, коли мова заходить про програмні продукти постачальників, вони використовуються як взаємозамінні, і вони не мають суттєвих відмінностей у термінах push або pull, як ви описуєте.
BUS проти ЧЕРЗІ дійсно кілька спадщини концепції, останнім часом , що випливає з систем , таких як IBM MQ і Tibco Rendezvous. Спочатку MQ була системою 1: 1, дійсно черга для роз’єднання різних систем.
Натомість Tibco був (продавався як) магістраллю обміну повідомленнями, де ви могли мати декількох видавців та передплатників на одні й ті самі теми.
Однак і ті, і інші (і новіші конкуруючі продукти) можуть грати в просторі один одного сьогодні. І те, і інше можна налаштувати на переривання, а також опитування нових повідомлень. Обидва опосередковують взаємодію між різними системами.
Однак фраза -черга повідомлення також використовується для внутрішніх внутрішньопотокових насосів повідомлень тощо, і в цьому контексті використання насправді інше. Якщо ви думаєте про класичний насос для повідомлень Windows, це дійсно більше модель витягування, яку ви описуєте, але насправді вона більше внутрішньопрограмна, ніж міжпрограмна або міжбудівна.
Шина повідомлень
Повідомлення Bus є обмін повідомленнями інфраструктури , щоб забезпечити різні системи для зв'язку через загальний набір інтерфейсів ( шини повідомлень ).
Джерело: EIP
Черга повідомлень
Основна ідея черги повідомлень проста:
Два (або більше) процеси можуть обмінюватися інформацією через доступ до загальної черги системних повідомлень .
Процес надсилання розміщує через деякий (ОС) модуль передачі повідомлень повідомлення в чергу, яку може прочитати інший процес
Джерело: Дейв Маршалл
Різниця
Черга повідомлень містить правило FIFO ( перший вхід - вихід ), тоді як у шині повідомлень - ні.
Висновок
Обидва ПОДАЮТЬСЯ, як виконувати один і той же вид роботи - передавати повідомлення між двома додатками або модулями, або інтерфейсами, або системами, або процесами , за винятком незначної різниці в FIFO
Між цими двома поняттями відбулося деяке розмиття рядків, оскільки деякі продукти тепер підтримують функції, які раніше належали лише до тієї чи іншої категорії (наприклад, Azure Service Bus підтримує обидва підходи).
Черга повідомлень отримує повідомлення від програми та робить їх доступними для однієї або кількох інших програм способом «перший у першому» (FIFO). У багатьох архітектурних сценаріях, якщо програмі A потрібно надсилати оновлення або команди програмам B і C, тоді для B і C. можуть бути встановлені окремі черги повідомлень. A писатиме окремі повідомлення в кожну чергу, і кожна залежна програма читатиме з її власна черга (повідомлення видаляється після скидання з черги). Ні B, ні C не повинні бути доступними, щоб A могла надсилати оновлення. Кожна черга повідомлень є постійною, тому, якщо додаток перезапуститься, воно почне витягуватись із своєї черги, як тільки буде знову в мережі. Це допомагає розірвати залежності між залежними системами і може забезпечити більшу масштабованість та відмовостійкість додатків.
Шина повідомлень або сервісна шина надає можливість одній (або декільком) програмам передавати повідомлення одній або декільком іншим програмам. Можливо, немає гарантій замовлення «перший у першому», і абоненти автобуса можуть приходити та їхати без відома відправників повідомлень. Таким чином, додаток A може бути написаний для повідомлення оновлення стану програми B за допомогою шини повідомлень. Пізніше написано додаток C, який також може отримати користь від цих оновлень. Додаток С може бути налаштований на прослуховування шини повідомлень та також вжиття заходів на основі цих оновлень, не вимагаючи жодного оновлення програми А. На відміну від черг, де надсилаюча програма явно додає повідомлення до кожної черги, шина повідомлень використовує публікацію / підписатися на модель. Повідомлення публікуються на шині, і будь-яка програма, яка підписалася на такий тип повідомлення, отримає їх.
Основна відмінність, про яку насправді явно не згадувалося в інших відповідях, полягає в тому, що шина повідомлень дозволяє кільком абонентам, тоді як черга буде виводити елементи по черзі на все, що прослуховує чергу. Якщо ви хотіли, щоб кілька слухачів бачили одні й ті самі елементи, що виходять з черги, вам доведеться впоратися з цим самостійно, сервісна шина зробить це нестандартно за вас.
Я бачу, що Черга повідомлень створює Шину повідомлень . Потім клієнти (тобто вузли) можуть слухати шину повідомлень. Це особливо вірно для випадку, коли у вас є MQ, що транслює повідомлення через UDP, іншими словами, це надсилання повідомлень на широкомовну / багатоадресну адресу, не знаючи і не турбуючись про те, хто їх отримуватиме. Для більш поглибленого опису цього сценарію ви можете ознайомитися з цією статтею .
Сервісна шина є більш загальним терміном, ніж Черга повідомлень.
MQ - це простий FIFO, але є більш складні способи реалізації сервісної шини, тобто концентратора подій, який є величезним "центром" для маніпулювання повідомленнями. Окрім функціональних можливостей, що надаються MQ, це дозволяє зберігати повідомлення (і, отже, використовувати декількох абонентів) тощо
Шина повідомлень - це модель розподілу 1-до-багатьох. Пункт призначення в цій моделі зазвичай називають темою чи темою. Те саме опубліковане повідомлення отримують усі споживачі-споживачі. Ви також можете назвати цю модель "трансляцією". Ви можете розглядати тему як еквівалент Теми в шаблоні проекту Observer для розподілених обчислень. Деякі постачальники шин повідомлень ефективно вирішують застосувати це як UDP замість TCP. Для теми темою повідомлення є "вистріли і забудь" - якщо ніхто не слухає, повідомлення просто зникає. Якщо це не те, що ви хочете, ви можете використовувати "довговічні підписки".
Черга повідомлень - це призначення 1 до 1 повідомлень. Повідомлення отримує лише один з приймаючих споживачів (будь ласка, зверніть увагу: послідовне використання абонентів для «клієнта теми» та приймачів для клієнта черги уникає плутанини). Повідомлення, надіслані в чергу, зберігаються на диску або в пам'яті до тих пір, поки хтось їх не забере або не закінчиться. Отже, черги (і довговічні підписки) потребують активного управління сховищем, потрібно думати про повільних споживачів.
У більшості середовищ, я б заперечив, теми є кращим вибором, тому що ви завжди можете додати додаткові компоненти, не змінюючи архітектуру. Доданими компонентами можуть бути моніторинг, реєстрація, аналітика тощо. На початку проекту ніколи не знаєш, якими будуть вимоги через 1 рік, 5 років, 10 років. Зміни неминучі, прийміть їх :-)