Вступ до протоколу AMQP
AMQP (Advanced Message Queuing Protocol) — це стандартний протокол прикладного рівня, який надає уніфіковані сервіси обміну повідомленнями, і є відкритим стандартом для протоколів на рівні додатків, розроблених для повідомленого проміжного програмного забезпечення. AMQP — це мережевий протокол для передачі асинхронних повідомлень між процесами.
Клієнти та проміжне програмне забезпечення на основі цього протоколу можуть доставляти повідомлення без обмежень різними продуктами клієнта/проміжного програмного забезпечення, різними мовами розробки тощо.
Основні характеристики AMQP — орієнтація на повідомлення, чергу, маршрутизація (включаючи peer-to-peer та публікацію/підписку), надійність і безпека. AMQP контролює поведінку постачальників повідомлень і клієнтів, забезпечуючи справжню сумісність між різними постачальниками.
AMQP та JMS
JMS була спробою стандартизувати раннє проміжне програмне забезпечення повідомлень, вона була стандартизована лише на рівні API і була далека від створення взаємодії.
На відміну від JMS, AMQP — це протокол на рівні дроту, який описує формат даних, що передаються через мережу, що передаються байтами. Відповідно, будь-який інструмент, що відповідає цьому формату даних, який створює та інтерпретує повідомлення, сумісний з іншими сумісними інструментами.
Склад ядра AMQP
Продюсер
Новини виробництва.
ConnectionFactory
Фабрика, що виробляє Connection.
Підключення
З'єднання, мережеве підключення до додатків за допомогою Broker TCP/IP/Triple Handshake та Quad Wave.
AMQP-з'єднання зазвичай довгі. AMQP — це протокол прикладного рівня, який використовує TCP для забезпечення надійної доставки. AMQP використовує механізми автентифікації та забезпечує захист TLS (SSL). Коли додаток більше не потребує підключення до AMQP-проксі, він повинен плавно відпустити AMQP-з'єднання, а не просто вимикати TCP-з'єднання.
Канал
Мережевий канал — це легке з'єднання, побудоване поверх Connection. Майже всі операції виконуються в каналах — каналах для читання та написання повідомлень, і клієнти можуть створювати пари для кожного каналу, кожна з яких представляє сесійне завдання.
Якщо порівнювати з'єднання з волоконно-оптичним кабелем, то канал каналу порівнюють з одним із волокон у волоконно-оптичному кабелі. На одному з'єднанні можна створити будь-яку кількість каналів.
Більшість наших бізнес-операцій здійснюється через інтерфейс Channel, зокрема:
- queueОголосити
- Обмін Декларувати для комутатора
- queueBind queueBind queueBind
- Опублікувати повідомлення basicОпублікувати
- Споживчі новини, BasicConconsume тощо.
Брокер
Прийняти підключення клієнта для реалізації сервісів сутності AMQP, таких як rabbitmq.
VirtualHost (веб-хостинг)
У віртуальному хостингу, який використовується для логічної ізоляції, віртуальний хост може мати кілька обмінів і черг, і один і той самий віртуальний хост не може мати біржі з однаковою назвою.
Для реалізації кількох ізольованих середовищ (користувачів, груп користувачів, комутаторів, черг тощо) на одному проксі, AMQP пропонує концепцію віртуальних хостів (віртуальних хостів — vhosts). Це дуже схоже на концепцію веб-хостингу веб-серверів, яка забезпечує повністю ізольоване середовище для AMQP-об'єктів. Коли з'єднання встановлено, клієнт AMQP визначає, який віртуальний хост використовувати.
Біржа
Комутатор приймає повідомлення і надсилає повідомлення до зв'язаної черги на основі ключа маршрутизації (без можливості зберігання повідомлень).
Комутатор — це AMQP-суб'єкт, який використовується для надсилання повідомлень. Після отримання повідомлення комутатор маршрутизує його до однієї або жодної черги. Алгоритм маршрутизації, який він використовує, визначається типом комутатора та правилами зв'язування.
Тип перемикача:
- Прямий обмін
- Обмін фанаутами
- Обмін темами
- Обмін заголовками
Властивості комутатора:
- Назва: Назва комутатора
- Довговічність: Прапорець збереження, який показує, чи зберігається цей перемикач
- Автоматичне видалення: Прапорець видалення, що вказуєКоли всі черги завершені за допомогою цього обміну, чи видаляються вони
- Аргументи: Залежить від самого агента
Стан перемикача:
Постійні комутатори з'являться після перезапуску брокера, тоді як стаджингові комутатори — ні (їх потрібно буде повторно декларувати після повернення брокера в онлайн).
Стандартний перемикач
Стандартний обмін фактично є прямим обміном, який попередньо оголошений брокером повідомлень і не має імені (ім'я є порожнім рядком).
Можна уявити собі стандартний вимикач як спеціальний прямий підключений вимикач.
Назва перемикача за замовчуванням: Null string (AMQP за замовчуванням)
Тип перемикача за замовчуванням: Перемикач з прямим підключенням
При створенні черги, якщо комутатор не вказаний, він автоматично прив'язується до стандартного комутатора, а ім'я ключа маршрутизації зв'язку буде таким самим, як ім'я черги.
Пряме підключення до комутатора
Безпосередньо підключений комутатор доставляє повідомлення до черги відповідних ключів зв'язування на основі ключа маршрутизації, який несе повідомлення. Унікаст-маршрутизація, яку використовує прямий комутатор для обробки повідомлення.
При створенні Черги, якщо вона прив'язана до прямого комутатора, їй не потрібно вказувати ім'я ключа маршрутизації, оскільки вона матиме ім'я ключа маршрутизації за замовчуванням, яке збігається з ім'ям Черги.
Черга безпосередньо підключених комутаторів зазвичай розподіляє завдання між кількома споживачами в циклі (ми називаємо це опитуванням).
Робочий процес:
- При зв'язуванні черги з комутатором дайте їй ключ зв'язування, припускаючи, що R;
- Коли повідомлення з ключем маршрутизації надсилається комутатору, підключеному безпосередньо комутатору, комутатор направляє його в чергу з ключем маршрутизації.
Вимикачі вентиляторів
Вентиляторний комутатор маршрутизує повідомлення до всіх черг, пов'язаних із ним, незалежно від ключа маршрутизації.
Якщо N черг прив'язані до секторного комутатора, коли повідомлення надсилається цьому комутатору, комутатор надсилає копію повідомлення всім N чергам окремо. Перемикачі вентиляторів зазвичай використовуються для обробки маршрутизації повідомлень через трансляцію.
Сценарії застосування:
трансляції повідомлень;
Функція групового чату.
Зміна теми
Перемикач теми надсилає повідомлення в одну або кілька черг відповідно до ключа маршрутизації та типу Exchange, і ми часто використовуємо його для реалізації різних підписок публікації/підписки, тобто публікації.
Правила маршрутизації для комутаторів, підключених напряму, суворо узгоджені, тобто ключ маршрутизації повинен відповідати ключу зв'язування перед тим, як надіслати повідомлення в чергу.
Правила маршрутизації у Theme Switch — це нечіткі матчі, які можна реалізувати, виконавши деякі правила через wildcards.
Він передбачає:
- У клавіші зв'язку для нечіткого співпадіння можуть бути два спеціальні символи * і #. де * використовується для відповідності слову, #用于匹配多个单词 (може дорівнювати нулю)
- Ключ маршрутизації — це рядок, розділений крапками (ми називаємо кожен окремий рядок, розділений крапкою, словом)
- Коли виробник надсилає повідомлення Routing Key=A.A.A.A, задовольняється лише A.*.*, і він буде маршрутизований лише до queue1.
- Коли виробник надсилає повідомлення Routing Key=A.B.A, що задовольняє A.*.* і *.B.*, буде маршрутизовано до черги1 і черги2.
- Коли виробник надсилає повідомлення Routing Key=A.B.C, тоді A.*.*, *.B.* і *.* задовольняються. C маршрутизується до queue1, queue2, queue3.
Сценарії застосування:
- новинні оновлення, пов'язані з категоріями або тегами;
- Фонові завдання, виконані кількома працівниками, кожен з яких відповідає за виконання певних конкретних завдань.
Головний перемикач
Комутатори заголовків не покладаються на правила відповідності маршрутизуючого ключа для зв'язування ключів із маршрутизацією повідомлень, а радше відповідають на основі атрибута заголовка у вмісті надісланого повідомлення.
Головні перемикачі можна розглядати як ще один прояв безпосередньо підключеного комутатора. Однак ключ маршрутизації прямого комутатора має бути рядком, і значення атрибутів заголовка не обмежуються цим, вони можуть бути цілими числами або хеш-значеннями (словники) тощо. Більше гнучкості (але на практиці ми рідко використовуємо головні перемикачі).
Робочий процес:
- Коли черга прив'язана до перемикача заголовка, одночасно прив'язуються кілька заголовків для відповідності.
- Вхідні повідомлення мають заголовок і параметр «x-match». Коли «x-match» встановлено на «any», можна зіставити будь-яке значення заголовка, а коли «x-match» встановлено на «all», усі значення заголовка мають бути збігані.
Короткий підсумок перемикача
Обов'язковим
Віртуальне з'єднання між Exchange і Queue.
BindingKey — це опис правил для зв'язків Exchange та Queue. Ключ зв'язування визначає, який тип маршрутизувального ключа буде призначений поточній зв'язаній черзі в поточній біржі.
Ключ маршрутизації
Правила маршрутизації, які віртуальна машина може використовувати для визначення маршрутизації певного повідомлення.
Ключ зв'язку проти ключа маршрутизації
- Ключ зв'язку — це ключ зв'язку між чергою та комутатором;
- Ключ маршрутизації — це інформація, яку виробник надсилає комутатору;
- Коли ключ зв'язку і ключ маршрутизації співпадають, помістіть повідомлення у відповідну чергу.
Ключ зв'язування — це опис правила зв'язування Exchange і черги, який використовується для розбору, коли Exchange отримує повідомлення, повідомлення, отримане Exchange, має поле Ключ маршрутизації, і Exchange співставляє цей ключ маршрутизації з усіма ключами зв'язування поточної Біржі, і якщо вимоги виконані, він буде переданий до Binding Ключ прив'язаний до Черги для надсилання повідомлення.
Ключ зв'язку проти ключа маршрутизації в різних комутаторах
Стандартний перемикач: Ключ зв'язування — це ім'я черги, яке не можна налаштовувати. Ключ маршрутизації також є назвою черги, перш ніж його можна буде успішно передати в чергу
Прямий комутатор з'єднання: Ключ зв'язку — це ім'я черги, яке можна налаштовувати. Ключі маршрутизації можна успішно передати до черги лише тоді, коли ключ зв'язку однаковий
Вимикач вентилятора: без клавіші зв'язку; Звісно, Routing Key не існує. Автоматично маршрутизується до всіх черг, прив'язаних до комутатора.
Перемикання теми: кастомний ключ зв'язування; Налаштуйте ключ маршрутизації. Ключ маршрутизації==Ключ зв'язування, і нечітке збігання має бути успішно маршрутизоване до черги
Головний перемикач: без клавіші зв'язку; Звісно, Routing Key не існує. Збіги на основі атрибута заголовка у вмісті надісланого повідомлення
Черга
Зберігає повідомлення, які ось-ось будуть поглинуті додатком.
Властивості черги:
- Назва: Назва черги
- Довготривалість: Черга залишається після перезапуску брокера повідомлень
- Ексклюзив: використовується лише одним з'єднанням, і черга видаляється при закритті з'єднання
- Автоматичне видалення: Видалено, коли останній користувач відписався
- Аргументи: Деякі брокери повідомлень використовують його для виконання додаткових функцій, подібних до TTL
Створення черги:
Черги можна використовувати лише після їх оголошення. Якщо черга ще не існує, оголошення черги створює її. Якщо оголошена черга вже існує і атрибути ідентичні, оголошення не впливає на початкову чергу. Якщо атрибути в оголошенні відрізняються від тих, що в існуючій черзі, викидається виключення на рівні каналу з кодом помилки 406.
Збереження черги:
Черга збереження зберігається на диску і залишається там після перезавантаження брокера. Черги, які не зберігаються, називаються тимчасовими чергами. Не всі сценарії та випадки потребують збереження черги.
Збережена черга не робить повідомлення, спрямовані на неї, постійними. Якщо агент повідомлення завершить слухавку і перезавантажується, черга збереження буде повторно оголошена під час перезавантаження, і в будь-якому разі можна відновити лише збережені повідомлення.
Споживач
Новини споживчого споживання. В AMQP існує два способи для споживачів отримувати очікувані повідомлення:
Посереднє програмне забезпечення для повідомлень доставляє повідомлення споживачам (push API)
Споживачі активно отримують повідомлення (pull API)
Примітка: Коли кілька споживачів слухають одну й ту ж чергу, повідомлення в черзі споживає лише один із споживачів (не один раз на кожного споживача)
Повідомлення
Дані, що передаються між повідомленнями, сервісами та додатками, складаються з властивостей і тіл.
Атрибути змінюють повідомлення, такі як пріоритет повідомлення, затримка та інші розширені функції, а основна частина — це зміст тіла повідомлення.
Властивості повідомлення:
- Тип контенту
- Кодування контенту
- Ключ маршрутизації
- Режим доставки (постійний чи ні)
- Режим доставки (постійний або непостійний)
- Пріоритет повідомлення
- Часова мітка публікації повідомлення
- Термін дії
- Ідентифікатор застосунку видавця
Основна частина повідомлення:
Окрім атрибутів, AMQP-повідомлення також містять корисне навантаження (дані, які повідомлення фактично несе), яке AMQP-проксі розглядає як непрозорий масив байтів.
Брокер повідомлень не перевіряє і не змінює корисне навантаження. Повідомлення можуть містити лише атрибути без використання корисного навантаження. Зазвичай він використовує дані у серіалізованому форматі, наприклад JSON, і для економії грошей буфери протоколу та MessagePack серіалізують структуровані дані для публікації як корисне навантаження повідомлень. AMQP та його колеги зазвичай використовують поля «content-type» та «content-encoding» для спілкування з повідомленнями з метою ідентифікації корисних навантажень, але це базується лише на конвенціях.
Збереження повідомлення:
Повідомлення публікуються у постійному форматі, а агент AMQP зберігає це повідомлення на диску. Якщо сервер перезавантажується, система підтверджує, що отримане повідомлення про збереження не втрачено.
Просте надсилання повідомлення на постійний комутатор або маршрутизація його до збереженої черги не робить повідомлення постійним: збереження повідомлення повністю залежить від режиму збереження самого повідомлення.
Постійне публікування повідомлень може впливати на продуктивність.
Робочий процес AMQP
Видавець публікує повідомлення через біржу.
Комутатор розподіляє вхідні повідомлення до черги, прив'язаної до комутатора, відповідно до правил маршрутизації.
Нарешті, агент AMQP передає повідомлення споживачу, який підписався на цю чергу, або споживач отримає його самостійно за потреби.
Механізм обміну повідомленнями AMQP
Підтвердження повідомлення
Споживачі іноді не обробляють повідомлення або іноді зазнають прямих збоїв. А мережеві причини також можуть спричиняти різні проблеми.
Це ставить нас перед питанням, коли правильний час для агентів AMQP видаляти повідомлення.
Два режими підтвердження повідомлень AMQP:
Режим автопідтвердження: Видаляйте повідомлення, щойно воно надіслано споживачу через посереднє програмне забезпечення. (Використовуючи метод AMQP: basic.deliver або basic.get-ok)
Режим явного підтвердження: Чекайте, поки споживач надішле підтвердження, перш ніж видаляти повідомлення. (За методом AMQP: basic.ack)
Якщо споживач кладе слухавку, не надіславши підтверджувальний чек, агент AMQP передає повідомлення іншому споживачу. Якщо в цей момент немає доступних споживачів, брокер повідомлень чекає, поки наступний споживач зареєструється в цій черзі, і намагається знову доставити.
Відхилити повідомлення
Коли споживач отримує повідомлення, процес обробки може бути успішним або невдалим. Споживач може повідомити брокеру повідомлень (проміжне програмне забезпечення повідомлень), що повідомлення не було оброблене (або не завершене на цьому етапі) через «відхилене повідомлення».
Коли повідомлення відхиляють, споживач може сказати брокеру, що робити з ним — знищити його або поставити назад у чергу.
Коли в цій черзі лише один споживач, переконайтеся, що ви не відхиляєте повідомлення і обираєте повернення в чергу, через що повідомлення буде безстроково повторюватися на тому ж споживачі.
У AMQP метод basic.reject використовується для виконання операції відхилення повідомлень. Однак basic.reject має обмеження: ви не можете використовувати його для відхилення кількох повідомлень із підтвердженнями. Але якщо ви використовуєте RabbitMQ, ви можете використати розширення AMQP 0-9-1, яке називається негативними підтвердженнями (також називаються nacks), щоб вирішити цю проблему.
Оригінальний:Вхід за гіперпосиланням видно.
|
Опубліковано 14.08.2022 23:22:55
|
|
|
|
