Въведение в протокола 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 връзката, вместо просто да я изключва.
Канал
Мрежовият канал е лека връзка, изградена върху Connection. Почти всички операции се извършват в канали, които са канали за четене и записване на съобщения, а клиентите могат да създават двойки за всеки канал, всеки от които представлява сесийна задача.
Ако връзката се сравни с оптичен кабел, тогава каналният канал се сравнява с едно от влакната в оптичен кабел. Може да се създаде произволен брой канали на една връзка.
Повечето от нашите бизнес операции се извършват в интерфейса Channel, включително:
- queueDeclare
- ExchangeDeclare за превключвателя
- queueBind queueBind queueBind
- Публикувай съобщението basicПубликувай
- Потребителски новини BasicConsume и др.
Брокер
Приемете връзката на клиента, за да имплементирате AMQP услуги за обекти, като rabbitmq.
VirtualHost (уеб хостинг)
Виртуален хостинг, използван за логическа изолация, виртуален хост може да има няколко обмена и опашки, а един и същ виртуален хост не може да има обменни станции със същото име.
За да се реализират множество изолирани среди (потребители, потребителски групи, суичове, опашки и др.) върху един прокси, AMQP предоставя концепцията за виртуални хостове (виртуални хостове - vhosts). Това е много подобно на концепцията за уеб хостинг на уеб сървъри, която осигурява напълно изолирана среда за AMQP обекти. Когато връзката се установи, AMQP клиентът определя кой виртуален хост да използва.
Обмяна
Суичът приема съобщения и изпраща съобщения към свързаната опашка въз основа на ключа за маршрутизиране (без възможности за съхранение на съобщения).
Суичът е AMQP единица, използвана за изпращане на съобщения. След като комутаторът получи съобщение, го маршрутизира към една или нула опашки. Алгоритъмът за маршрутизиране, който използва, се определя от типа на превключвателя и правилата за свързване.
Тип превключвател:
- Директен обмен
- Размяна на размяна на размяна
- Обмен на теми
- Размяна на глави
Свойства на суита:
- Име: Името на превключвателя
- Издръжливост: Флаг за запазване, който показва дали този превключвател е запазен или не
- Автоматично изтриване: Флаг за изтриване, който показваКогато всички опашки са завършени чрез тази размяна, дали те се изтриват
- Аргументи: Зависи от самия агент
Статус на превключвателя:
Постоянните суичове ще съществуват след рестартиране на брокера, докато staging суичовете няма (те ще трябва да бъдат декларирани отново след като брокерът е онлайн).
Стандартен превключвател
Стандартната борса всъщност е директна борса, която е предварително декларирана от брокера на съобщения и няма име (името е празен низ).
Можете да мислите за стандартния ключ като за специален директно свързан превключвател.
Име на превключвателя по подразбиране: Null низ (AMQP по подразбиране)
Тип превключвател по подразбиране: Директно свързан ключ
При създаване на опашка, докато не е посочен превключвател, който трябва да бъде обвързан, той автоматично ще бъде обвързан с подразбиращия суич, а името на маршрутизиращия ключ на binding ще бъде същото като името на опашката.
Директна връзка към суича
Директно свързан комутатор доставя съобщения до опашка от съответни свързващи ключове, базирани на маршрутизиращия ключ, пренасян от съобщението. Уникаст маршрутизацията, използвана от директния комутатор за обработка на съобщението.
При създаване на опашка, ако е обвързана с директен суич, не е необходимо да се посочва името на маршрутизиращия ключ, защото ще има име на ключ за маршрутизиране по подразбиране, което е същото като името на опашките.
Опашка от директно свързани суичове обикновено разпределя задачите към множество потребители в цикъл (наричаме това polling).
Работен процес:
- При свързване на опашка към превключвател, дайте му ключ за свързване, при условие че R;
- Когато съобщение с Routing Key се изпрати към директно свързан комутатор, суичът го насочва към опашка с Routing Key.
Вентилаторни превключватели
Вентилаторният превключвател насочва съобщения към всички опашки, свързани с него, независимо от свързания маршрутизиращ ключ.
Ако N опашки са обвързани със секторен превключвател, когато съобщение бъде изпратено към този секторен превключвател, превключвателят изпраща копие на съобщението към всички N опашки отделно. Вентилаторните превключватели обикновено се използват за обработка на маршрутизиране на съобщения чрез излъчване.
Сценарии на приложение:
излъчване на съобщения;
Функция за групов чат.
Смяна на темата
Превключвателят на темата изпраща съобщения до една или повече опашки според маршрутизиращия ключ и типа на Exchange, и често го използваме за реализиране на различни абонаменти за публикуване/абониране, тоест за публикуване.
Правилата за маршрутизиране при директно свързани суичове са строго съгласувани, което означава, че ключът за маршрутизиране трябва да съвпада с ключа за свързване, преди да изпрати съобщение към опашката.
Правилата за маршрутизиране на темата са неясни съвпадения, които могат да се постигнат чрез изпълнение на някои от правилата чрез уайлдкарди.
Той гласи:
- Могат да има два специални знака * и # в свързващия клавиш за неясно съвпадение. където * се използва за съвпадение на дума, #用于匹配多个单词 (може да бъде нула)
- Ключът за маршрутизиране е низ с точково разделение (наричаме всяка отделна линия, разделена с точка с точка, дума)
- Когато производителят изпрати съобщението Routing Key=A.A.A.A, само A.*.* е удовлетворен и то ще бъде насочено само към queue1.
- Когато производителят изпрати съобщението Routing Key=A.B.A, удовлетворяващо A.*.* и *.B.*, ще бъде насочено към queue1 и queue2.
- Когато производителят изпрати съобщението Routing Key=A.B.C, тогава A.*.* и *.B.* и *.* са удовлетворени. C се маршрутизира към queue1, queue2, queue3.
Сценарии на приложение:
- новинарски актуализации, свързани с категории или тагове;
- Фонови задачи, изпълнявани от множество работници, всеки от които отговаря за определени конкретни задачи.
Превключвател на главата
Превключвателите на заглавията не разчитат на правилата за съвпадение на маршрутизиращия ключ за свързване на ключове към маршрутизираните съобщения, а по-скоро съвпадат според атрибута на заглавието в съдържанието на изпратеното съобщение.
Главните превключватели могат да се разглеждат като друго проявление на директно свързан превключвател. Въпреки това, ключът за маршрутизиране на директен превключвател трябва да е низ, а стойностите на атрибутите на заглавието не са ограничени от това, те могат дори да бъдат цели числа или хеш стойности (речници) и др. Повече гъвкавост (но на практика рядко използваме главни превключватели).
Работен процес:
- Когато опашката е свързана с header switch, няколко заглавия се свързват едновременно за съвпадение.
- Входящите съобщения носят заглавие и параметър "x-match". Когато "x-match" е зададено на "any", всяка стойност на заглавието може да бъде съвпадана, а когато "x-match" е зададено на "всички", всички стойности на заглавието трябва да се съвпаднат.
Резюме на Switch
Подвързване
Виртуална връзка между Exchange и Queue.
BindingKey е описание на правило за Exchange и Queue bindings. Свързващият ключ определя какъв тип маршрутизиращ ключ ще бъде присвоен на текущо обвързаната опашка под текущата централа.
Ключ за маршрутизиране
Правила за маршрутизиране, които виртуалната машина може да използва, за да определи как да маршрутизира определено съобщение.
Свързващ ключ срещу маршрутизиращ ключ
- Ключът за свързване е ключът за свързване между опашката и превключвателя;
- Ключът за маршрутизиране е информация, изпратена от производителя към суича;
- Когато свързващият ключ и ключът за маршрутизиране съвпадат, поставете съобщението в съответната опашка.
Свързващият ключ е описание на правилото за свързване на Exchange и Queue, което се използва за парсинг, когато Exchange получи съобщение, съобщението, получено от Exchange, ще има поле за Routing Key и Exchange съпоставя този Routing Key с всички свързващи ключове на текущата Exchange, и ако изискванията са изпълнени, той ще бъде изпратен към Binding Ключът е свързан с опашката за изпращане на съобщението.
Свързващ ключ срещу маршрутизиращ ключ в различни суичове
Стандартен превключвател: Binding Key е името на опашката, което не може да бъде персонализирано. Ключът за маршрутизиране е и името на опашката преди да може успешно да бъде насочен към нея
Директен превключвател на връзката: Binding Key е името на Queue, което може да бъде персонализирано. Ключовете за маршрутизиране могат да бъдат успешно насочени към опашката само когато ключът за свързване е същият
Вентилаторен превключвател: Няма клавиш за свързване; Разбира се, няма Routing Key. Автоматично се маршрутизира към всички опашки, свързани с комутатора
Смяна на темата: персонализиран свързващ ключ; Персонализирайте ключа за маршрутизация. Routing Key==Свързващ ключ, а fuzzy match трябва успешно да бъде насочен към опашката
Главният превключвател: без клавиш за свързване; Разбира се, няма Routing Key. Съвпадения, базирани на атрибута на заглавието в съдържанието на изпратеното съобщение
Опашка
Съхранява съобщения, които са на път да бъдат погълнати от приложението.
Свойства на опашките:
- Име: Името на опашката
- Издръжливост: Опашката все още съществува след рестартиране на брокера за съобщения
- Ексклузивно: Използва се само от една връзка, а опашката се изтрива, когато връзката е затворена
- Автоматично изтриване: Изтрито, когато последният потребител се отпише
- Аргументи: Някои брокери на съобщения го използват за допълнителни функции, подобни на TTL
Създаване на опашка:
Опашките могат да се използват само след като са обявени. Ако опашка все още не съществува, обявяването на опашка я създава. Ако декларираната опашка вече съществува и атрибутите са идентични, декларацията няма ефект върху оригиналната опашка. Ако атрибутите в декларацията се различават от тези в съществуващата опашка, се хвърля изключение на ниво канал с код за грешка 406.
Запазване на опашката:
Опашката за запазване се съхранява на диска и остава там, когато брокерът се рестартира. Опашките, които не се запазват, се наричат преходни опашки. Не всички сценарии и случаи изискват устойчивост на опашките.
Запазващата опашка не прави съобщенията, насочени към нея, постоянни. Ако агентът за съобщения прекъсне и бъде рестартиран, опашката за запазване ще бъде декларирана отново по време на рестарта и във всеки случай могат да бъдат възстановени само запазените съобщения.
Потребител
Новини за потребителската консумация. В AMQP има два начина потребителите да получават чакащи съобщения:
Междинният софтуер за съобщения доставя съобщения на потребителите (push API)
Потребителите активно получават съобщения (изтегляне на 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 ч.
|
|
|
|
