Тема JMS проти черг

Мені було цікаво, в чому різниця між чергою JMS та темою JMS.

На сторінці ActiveMQ йдеться

Теми

У JMS a Topic реалізує публікацію та підписку семантики. Коли ви публікуєте повідомлення, воно переходить до всіх зацікавлених передплатників - тому нуль багатьом підписникам отримає копію повідомлення. Тільки абоненти, які мали активну підписку на момент отримання брокера, отримають копію повідомлення.

Черги

Черга JMS реалізує семантику балансира навантаження . Одне повідомлення отримає рівно один споживач. Якщо на момент надсилання повідомлення немає споживачів, вони зберігатимуться, поки споживач не зможе обробити повідомлення. Якщо споживач отримує повідомлення і не підтверджує його перед закриттям, повідомлення буде перезавантажено іншому споживачеві. У черзі може бути багато споживачів, коли завантаження повідомлень збалансовано серед доступних споживачів.

Я хочу мати "щось", що надсилатиме копію повідомлення кожному абоненту в тій же послідовності, що і та, в якій повідомлення отримало брокер ActiveMQ.

Будь-які думки?

Це означає, що тема відповідна. Черга означає, що повідомлення переходить до одного і лише одного можливого абонента. Тема стосується кожного абонента.

Теми призначені для моделі видавця-підписника, тоді як черги - точкові.

JMS тема є тип призначення в моделі 1-к-многим розподілу. Те ж опубліковано повідомлення отримано всі споживають абонентами . Ви також можете назвати це моделлю "трансляція". Ви можете думати про тему як еквівалент Тематики в шаблоні проектування спостерігача для розподілених обчислень. Деякі постачальники JMS ефективно вирішують реалізувати це як UDP замість TCP. Щодо теми, повідомлення повідомляється як "пожежа-забудь" - якщо ніхто не слухає, повідомлення просто зникає. Якщо це не те, що ви хочете, ви можете використовувати "тривалі підписки".

Черга JMS є місцем 1-к-1 повідомлень. Повідомлення отримує лише один із приймаючих споживачів (будь ласка, зверніть увагу: послідовно використовуйте абонентів для "клієнта теми" та приймачів для клієнтів у черзі, щоб уникнути плутанини). Повідомлення, надіслані до черги, зберігаються на диску чи пам’яті, поки хтось не підбере її або не закінчиться. Тому черги (і довговічні підписки) потребують активного управління сховищем, потрібно думати про повільних споживачів.

У більшості середовищ, я заперечую, теми є кращим вибором, оскільки ви завжди можете додавати додаткові компоненти, не змінюючи архітектуру. Додані компоненти можуть бути моніторингом, веденням журналу, аналітикою тощо. На початку проекту ніколи не відомо, якими будуть вимоги через 1 рік, 5 років, 10 років. Зміни неминучі, сприймайте їх :-)

Це просто:

Черги = Вставка> Вивести (надіслати єдиному абоненту) 1: 1

Теми = Вставка> Трансляція (надіслати всім підписникам) 1: n

Щодо збереження замовлень, див. Цю сторінку ActiveMQ . Коротше кажучи: замовлення зберігається для одиноких споживачів, але для кількох споживачів порядок доставки не гарантується.

Черги

Плюси

• Простий шаблон обміну повідомленнями з прозорим потоком зв'язку
• Повідомлення можна відновити, поставивши їх назад у чергу

Мінуси

• Лише один споживач може отримати повідомлення
• Мається на увазі зв'язок між виробником і споживачем, оскільки це відношення один до одного

Теми

Плюси

• Кілька споживачів можуть отримати повідомлення
• Розв'язка між виробником та споживачами (модель публікації та підписки)

Мінуси

• Складніший комунікаційний потік
• Повідомлення неможливо відновити для одного слухача

Якщо у вас є N споживачів:

Теми JMS доставляють повідомлення до N з N Черги JMS доставляють повідомлення до 1 з N

Ви сказали, що "шукаєте" щось ", яке надішле копію повідомлення кожному абоненту в тій же послідовності, що і в тій, в якій повідомлення отримано брокером ActiveMQ."

Отже, ви хочете використовувати тему для того, щоб усі N підписників отримали копію повідомлення.

ТЕМА :: тема - це багато комунікацій ... (багатоточковий або опублікувати / підписатися) EX: - уявіть, що видавець публікує фільм у ютубі, тоді всі його підписники отримають сповіщення .... QUEVE :: queve - це один -один зв’язок ... Наприклад: -Коли опублікувати запит на поповнення, він перейде лише до одного qreciever ... завжди пам’ятайте, якщо запит перейшов до всіх приймачів, то відбулося багаторазове поповнення, тому розробляючи аналіз, який підходить для програми

Черга - об’єкт, керований JMS, який використовується для прийому повідомлень, які чекають, що споживачі споживають. Коли всі підписники споживають повідомлення, повідомлення буде видалено з черги.

Тема полягає в тому, що всі підписники теми отримують одне і те ж повідомлення при публікації повідомлення.