Einführung in das AMQP-Protokoll
AMQP (Advanced Message Queuing Protocol) ist ein Standardprotokoll auf Anwendungsebene, das einheitliche Messaging-Dienste bereitstellt und ein offener Standard für Anwendungsschichtprotokolle ist, die für nachrichtenorientierte Middleware entwickelt wurden. AMQP ist ein Netzwerkprotokoll zum Übermitteln asynchroner Nachrichten zwischen Prozessen.
Clients und Nachrichten-Middleware, die auf diesem Protokoll basieren, können Nachrichten zustellen, ohne durch verschiedene Client-/Middleware-Produkte, unterschiedliche Entwicklungssprachen usw. eingeschränkt zu sein.
Die Hauptmerkmale von AMQP sind nachrichtenorientiert, warteschlangenorientiert, Routing (einschließlich Peer-to-Peer und Publish/Subscribe), Zuverlässigkeit und Sicherheit. AMQP setzt das Verhalten von Nachrichtenanbietern und Kunden durch und ermöglicht so echte Interoperabilität zwischen verschiedenen Anbietern.
AMQP und JMS
JMS war ein Versuch, die frühe Nachrichten-Middleware zu standardisieren, war jedoch nur auf API-Ebene standardisiert und war weit davon entfernt, Interoperabilität zu schaffen.
Im Gegensatz zu JMS ist AMQP ein drahtgebundenes Protokoll, das das Format der über ein Netzwerk übertragenen Daten in Bytes beschreibt. Daher ist jedes Werkzeug, das diesem Datenformat folgt und Nachrichten erstellt und interpretiert, mit anderen kompatiblen Werkzeugen interoperabel.
AMQP-Kernzusammensetzung
Produzent
Produktionsneuigkeiten.
ConnectionFactory
Die Fabrik, die Connection herstellt.
Verbindung
Verbindung, Anwendungsnetzwerkverbindung mit Broker TCP/IP/Triple Handshake und Quad Wave.
AMQP-Verbindungen sind in der Regel lange Verbindungen. AMQP ist ein Anwendungsprotokoll, das TCP nutzt, um eine zuverlässige Auslieferung zu gewährleisten. AMQP verwendet Authentifizierungsmechanismen und bietet TLS-(SSL)-Schutz. Wenn eine Anwendung keine Verbindung mehr zum AMQP-Proxy benötigt, muss sie die AMQP-Verbindung elegant freigeben, anstatt einfach die TCP-Verbindung abzuschalten.
Kanal
Der Netzwerkkanal ist eine leichte Verbindung, die auf der Verbindung aufgebaut ist. Fast alle Operationen werden in Kanälen durchgeführt, also Kanälen zum Lesen und Schreiben von Nachrichten, und Clients können für jeden Kanal Paare einrichten, von denen jeder eine Sitzungsaufgabe darstellt.
Wenn die Verbindung mit einem Glasfaserkabel verglichen wird, wird der Kanalkanal mit einer der Glasfasern in einem Glasfaserkabel verglichen. Beliebig viele Kanäle können auf einer Verbindung erstellt werden.
Die meisten unserer Geschäftsabläufe finden über die Channel-Schnittstelle statt, darunter:
- queueDeklarieren
- Die ExchangeDeclare für den Switch
- queueBind queueBind
- Veröffentlichen Sie die Nachricht basicPublish
- Consumer newsbasicConsume usw.
Makler
Akzeptieren Sie die Verbindung des Clients, um AMQP-Entitätsdienste wie rabbitmq zu implementieren.
VirtualHost (Webhosting)
Virtuelles Hosting, das zur logischen Isolation verwendet wird, ein virtueller Host kann mehrere Vermittlungsstellen und Warteschlangen haben, und derselbe virtuelle Wirt kann keine Vermittlungen mit demselben Namen haben.
Um mehrere isolierte Umgebungen (Benutzer, Benutzergruppen, Switches, Warteschlangen usw.) auf einem einzigen Proxy zu implementieren, bietet AMQP das Konzept der virtuellen Hosts (virtuelle Hosts – vhosts). Dies ähnelt sehr dem Webserver-Webhosting-Konzept, das eine vollständig isolierte Umgebung für AMQP-Entitäten bietet. Wenn die Verbindung hergestellt ist, gibt der AMQP-Client an, welchen virtuellen Host verwendet werden soll.
Umtausch
Der Switch akzeptiert Nachrichten und sendet Nachrichten basierend auf dem Routing-Schlüssel an die gebundene Warteschlange (ohne Nachrichtenspeicherfunktionen).
Ein Switch ist eine AMQP-Entität, die zum Senden von Nachrichten verwendet wird. Nachdem der Switch eine Nachricht erhält, leitet er diese an eine oder keine Warteschlangen weiter. Der verwendete Routing-Algorithmus wird durch den Schaltertyp und die Bindungsregeln bestimmt.
Schaltertyp:
- Direkter Austausch
- Fanout-Austausch
- Themenaustausch
- Header-Austausch
Eigenschaften des Schalters:
- Name: Der Name des Schalters
- Haltbarkeit: Ein Persistenz-Flag, das anzeigt, ob dieser Wechsel erhalten bleibt oder nicht
- Auto-Löschen: Lösch-Flag, das auf hinweistWenn alle Warteschlangen über diesen Austausch abgeschlossen sind, ob sie gelöscht werden
- Argumente: Abhängig vom Agenten selbst
Wechselstatus:
Persistente Switches werden nach dem Neustart des Brokers existieren, während Staging Switches nicht mehr existieren (sie müssen neu deklariert werden, nachdem der Broker wieder online ist).
Standardschalter
Der Standardaustausch ist tatsächlich ein Direktaustausch, der vom Nachrichtenbroker vorab deklariert wurde und keinen Namen hat (der Name ist eine leere Zeichenkette).
Man kann sich den Standardschalter als speziellen direkt angeschlossenen Schalter vorstellen.
Standard-Switch-Name: Null-String (AMQP-Standard)
Standard-Schaltertyp: Direkt angeschlossener Schalter
Beim Erstellen einer Warteschlange, solange der zu bindende Switch nicht angegeben ist, wird er automatisch an den Standard-Switch gebunden, und der Routing-Schlüssel der Bindung ist derselbe wie der Name der Warteschlange.
Direkte Verbindung zum Schalter
Ein direkt angeschlossener Switch liefert Nachrichten an eine Warteschlange entsprechender Bindeschlüssel, basierend auf dem von der Nachricht übertragenen Routing-Schlüssel. Das Unicast-Routing, das vom Direktschalter zur Bearbeitung der Nachricht verwendet wird.
Beim Erstellen einer Warteschlange, die an einen direkten Switch gebunden ist, muss der Name des Routing-Schlüssels nicht angegeben werden, da dieser einen Standard-Routing-Schlüssel-Namen hat, der mit dem Warteschlangennamen identisch ist.
Eine Warteschlange von direkt angeschlossenen Switches verteilt typischerweise Aufgaben in einer Schleife an mehrere Konsumenten (wir nennen dies Abfragen).
Arbeitsablauf:
- Beim Binden einer Warteschlange an einen Schalter gib ihr eine Bindetaste, wobei R angenommen wird;
- Wenn eine Nachricht mit einem Routing-Schlüssel an einen direkt angeschlossenen Switch gesendet wird, leitet der Switch sie an eine Warteschlange mit einem Routing-Schlüssel weiter.
Lüfterschalter
Der Lüfterschalter leitet Nachrichten an alle an ihn gebundenen Warteschlangen weiter, unabhängig vom gebundenen Routing-Key.
Wenn N Warteschlangen an einen Sektorschalter gebunden sind, sendet der Schalter eine Kopie der Nachricht an alle N Warteschlangen einzeln, wenn eine Nachricht an diesen Sektorschalter gesendet wird. Lüfterschalter werden im Allgemeinen verwendet, um das Broadcast-Routing von Nachrichten zu verarbeiten.
Anwendungsszenarien:
Sendebotschaften;
Gruppenchat-Funktion.
Themenwechsel
Der Themenwechsel sendet Nachrichten an eine oder mehrere Warteschlangen entsprechend dem Routing-Schlüssel und dem Austauschtyp, und wir verwenden ihn oft, um verschiedene Publish/Subscribes, also Publish-Abonnements, zu implementieren.
Die Routing-Regeln für direkt angeschlossene Switches sind streng abgestimmt, was bedeutet, dass der Routing-Schlüssel mit dem Bindungsschlüssel übereinstimmen muss, bevor eine Nachricht an die Warteschlange gesendet wird.
Die Routing-Regeln des Topic-Wechsels sind unscharfe Übereinstimmungen, die durch die Erfüllung einiger Regeln durch Wildcards geliefert werden können.
Er schreibt vor:
- Es können zwei Sonderzeichen * und # in der Bindetaste für das unscharfe Matching sein. wobei * verwendet wird, um ein Wort zu übereinstimmen, #用于匹配多个单词 (kann null sein)
- Ein Routing-Schlüssel ist eine punkt-getrennte Zeichenkette (wir nennen jede einzelne Zeichenkette, die durch eine Punktmarkierung getrennt ist, ein Wort)
- Wenn der Produzent die Nachricht Routing Key=A.A.A sendet, ist nur A.*.* erfüllt und wird nur an Queue1 weitergeleitet.
- Wenn der Produzent die Nachricht "Routing Key=A.B.A" sendet, werden die Erfüllung von A.*.* und *.B.* an queue1 und queue2 weitergeleitet.
- Wenn der Produzent die Nachricht Routing Key=A.B.C. sendet, dann sind A.*.* und *.B.* und *.* erfüllt. C wird an Warteschlange1, Warteschlange2, Warteschlange3 geleitet.
Anwendungsszenarien:
- Nachrichten-Updates zu Kategorien oder Tags;
- Hintergrundaufgaben, die von mehreren Mitarbeitern erledigt werden, von denen jeder für bestimmte Aufgaben verantwortlich ist.
Kopfschalter
Header-Switches verlassen sich nicht auf die Abstimmungsregeln des Routing-Schlüssels zur Bindung von Schlüsseln zur Weiterleitung von Nachrichten, sondern stimmen stattdessen basierend auf dem Header-Attribut im Inhalt der gesendeten Nachricht an.
Kopfschalter können als weitere Manifestation eines direkt angeschlossenen Schalters betrachtet werden. Allerdings muss der Routing-Schlüssel eines direkten Switches eine Zeichenkette sein, und die Header-Attributwerte sind dadurch nicht eingeschränkt; sie können sogar ganze Zahlen oder Hash-Werte (Wörterbücher) usw. sein. Mehr Flexibilität (aber in der Praxis nutzen wir selten Kopfschalter).
Arbeitsablauf:
- Wenn eine Warteschlange an einen Header-Switch gebunden ist, sind mehrere Header gleichzeitig für das Matching gebunden.
- Eingehende Nachrichten tragen einen Header und einen "x-match"-Parameter. Wenn "x-match" auf "beliebige" gesetzt ist, kann jeder Wert des Headers abgeglichen werden, und wenn "x-match" auf "all" gesetzt ist, müssen alle Werte des Headers abgestimmt werden.
Schalter-Zusammenfassung
Verbindlich
Virtuelle Verbindung zwischen Exchange und Warteschlange.
BindingKey ist eine Regelbeschreibung für Exchange- und Warteschlangenbindungen. Der Bindungsschlüssel legt an, welche Art von Routing-Schlüssel der aktuell gebundenen Warteschlange unter der aktuellen Vermittlung zugewiesen wird.
Routing-Schlüssel
Routing-Regeln, die die virtuelle Maschine verwenden kann, um zu bestimmen, wie eine bestimmte Nachricht weitergeleitet wird.
Bindeschlüssel vs. Routing-Schlüssel
- Die Bindetaste ist die Bindetaste zwischen der Warteschlange und dem Schalter;
- Der Routing-Schlüssel ist ein Informationsstück, das vom Produzenten an den Switch gesendet wird;
- Wenn Bindungsschlüssel und Routing-Schlüssel übereinstimmen, legen Sie die Nachricht in die entsprechende Warteschlange.
Binding Key ist die Regelbeschreibung von Exchange und Warteschlangenbindung, die verwendet wird, um zu analysieren, wenn Exchange eine Nachricht empfängt; die vom Exchange empfangene Nachricht enthält ein Routing-Key-Feld, und Exchange passt diesen Routing-Schlüssel mit allen Binding Keys des aktuellen Exchange ab, und wenn die Anforderungen erfüllt sind, wird er an Binding gesendet Key ist an die Warteschlange gebunden, um die Nachricht zu senden.
Bindenschlüssel vs. Routing-Schlüssel in verschiedenen Switches
Standardschalter: Die Bindungstaste ist der Warteschlangenname, der nicht angepasst werden kann. Der Routing-Schlüssel ist auch der Name der Warteschlange, bevor er erfolgreich zur Warteschlange weitergeleitet werden kann
Direktverbindungsschalter: Binding Key ist der Name der Warteschlange, der angepasst werden kann. Routing-Schlüssel können nur dann erfolgreich zur Warteschlange weitergeleitet werden, wenn der Binding-Schlüssel derselbe ist
Lüfterschalter: Keine Bindetaste; Natürlich gibt es keinen Routing-Schlüssel. Automatisch an alle an den Switch gebundenen Warteschlangen weitergeleitet
Thema-Wechsel: benutzerdefinierte Bindungstaste; Passe den Routing-Schlüssel an. Routing-Schlüssel==Binde-Schlüssel, und die Fuzzy-Übereinstimmung muss erfolgreich an die Warteschlange weitergeleitet werden
Kopfschalter: kein Tastenzug; Natürlich gibt es keinen Routing-Schlüssel. Übereinstimmungen basieren auf dem Header-Attribut im Inhalt der gesendeten Nachricht
Schlange
Speichert Nachrichten, die gleich von der App konsumiert werden.
Warteschlangeneigenschaften:
- Name: Der Name der Warteschlange
- Dauerhaft: Die Warteschlange existiert noch, nachdem der Nachrichtenbroker neu gestartet wurde
- Exklusiv: Wird nur von einer Verbindung genutzt, und die Warteschlange wird gelöscht, wenn die Verbindung geschlossen wird
- Auto-Löschung: Gelöscht, wenn der letzte Verbraucher das Abonnement kündigt
- Argumente: Einige Nachrichtenbroker nutzen es, um zusätzliche Funktionen ähnlich wie TTL auszuführen
Warteschlangenerstellung:
Warteschlangen können nur nach ihrer Deklaration genutzt werden. Wenn eine Warteschlange noch nicht existiert, erzeugt die Deklaration einer Warteschlange sie. Wenn die deklarierte Warteschlange bereits existiert und die Attribute identisch sind, hat die Deklaration keinen Einfluss auf die ursprüngliche Warteschlange. Wenn die Attribute in der Deklaration von denen in der bestehenden Warteschlange abweichen, wird eine Kanal-Ausnahme mit dem Fehlercode 406 geworfen.
Warteschlangenpersistenz:
Die Persistenz-Warteschlange wird auf der Festplatte gespeichert und bleibt dort, wenn der Broker neu gestartet wird. Warteschlangen, die nicht aufrechterhalten werden, werden transienten Warteschlangen genannt. Nicht alle Szenarien und Fälle erfordern Warteschlangenpersistenz.
Eine persistierte Warteschlange macht Nachrichten, die an sie weitergeleitet werden, nicht persistent. Wenn der Nachrichtenagent auflegt und neu gestartet wird, wird die Persistenz-Warteschlange während des Neustarts neu deklariert, und in jedem Fall können nur gespeicherte Nachrichten wiederhergestellt werden.
Verbraucher
Nachrichten zum Verbraucherkonsum. In AMQP gibt es zwei Möglichkeiten, wie Verbraucher ausstehende Nachrichten erhalten können:
Nachrichten-Middleware liefert Nachrichten an Verbraucher (Push-API)
Konsumenten erhalten aktiv Nachrichten (Pull API)
Hinweis: Wenn mehrere Konsumenten dieselbe Warteschlange hören, werden die Nachrichten in der Warteschlange nur von einem der Konsumenten konsumiert (nicht einmal pro Konsument)
Nachricht
Die zwischen Nachrichten, Diensten und Anwendungen übertragenen Daten bestehen aus Eigenschaften und Körpern.
Attribute ändern Nachrichten, wie Nachrichtenpriorität, Verzögerung und andere erweiterte Funktionen, und der Hauptkörper ist der Inhalt des Nachrichtenkörpers.
Nachrichteneigenschaften:
- Inhaltstyp
- Inhaltskodierung
- Routing-Schlüssel
- Liefermodus (persistent oder nicht)
- Liefermodus (persistent oder nicht-persistent)
- Nachrichtenpriorität
- Zeitstempel der Nachrichtenveröffentlichung
- Verfallsdauer
- Publisher-Anwendungs-ID
Nachrichtentext:
Zusätzlich zu den Attributen enthalten AMQP-Nachrichten auch eine Nutzlast (die Daten, die die Nachricht tatsächlich enthält), die vom AMQP-Proxy als undurchsichtiges Byte-Array behandelt wird.
Der Nachrichtenbroker inspiziert oder verändert die Nutzlast nicht. Nachrichten können nur Attribute enthalten, ohne eine Nutzlast zu tragen. Es verwendet die Daten typischerweise in einem serialisierten Format wie JSON, und um Geld zu sparen, serialisieren Protokollpuffer und MessagePacks die strukturierten Daten zur Veröffentlichung als Nutzlast von Nachrichten. AMQP und seine Kollegen verwenden typischerweise die Felder "Inhaltstyp" und "Inhaltscodierung", um mit Nachrichten zu kommunizieren und Nutzlasten zu identifizieren, dies basiert jedoch ausschließlich auf Konventionen.
Botschaftspersistenz:
Nachrichten werden persistent veröffentlicht, und der AMQP-Agent speichert diese Nachricht auf der Festplatte. Wenn der Server neu gestartet wird, bestätigt das System, dass die empfangene Persistenznachricht nicht verloren gegangen ist.
Das blosse Senden einer Nachricht an einen persistenten Switch oder das Weiterleiten an eine persistierte Warteschlange macht die Nachricht nicht persistent: Die Persistenz der Nachricht hängt vollständig vom Persistenzmodus der Nachricht selbst ab.
Das dauerhafte Veröffentlichen von Nachrichten kann Auswirkungen auf die Performance haben.
Arbeitsprozess des AMQP
Der Verlag veröffentlicht eine Botschaft über den Exchange.
Der Switch verteilt die eingehenden Nachrichten gemäß den Routing-Regeln an die an den Switch gebundene Warteschlange.
Schließlich übermittelt der AMQP-Agent die Nachricht an den Verbraucher, der diese Warteschlange abonniert hat, oder der Verbraucher erhält sie bei Bedarf selbst.
AMQP-Messaging-Mechanismus
Bestätigung der Nachricht
Konsumenten verarbeiten Nachrichten gelegentlich nicht oder stürzen manchmal direkt ab. Und Netzwerkgründe können ebenfalls verschiedene Probleme verursachen.
Dies stellt uns die Frage, wann der richtige Zeitpunkt für AMQP-Agenten ist, Nachrichten zu löschen.
Die beiden Nachrichtenbestätigungsmodi von AMQP:
Automatischer Bestätigungsmodus: Löschen Sie die Nachricht, sobald sie vom Nachrichten-Middleware an den Verbraucher gesendet wird. (Mit der AMQP-Methode: basic.deliver oder basic.get-ok)
Expliziter Bestätigungsmodus: Warten Sie, bis der Verbraucher eine Bestätigung sendet, bevor Sie die Nachricht löschen. (Mit der AMQP-Methode: basic.ack)
Wenn ein Verbraucher auflegt, ohne eine Bestätigungsbestätigung zu senden, übergibt der AMQP-Agent die Nachricht erneut an einen anderen Verbraucher. Wenn zu diesem Zeitpunkt keine Konsumenten verfügbar sind, wartet der Nachrichtenvermittler darauf, dass der nächste Verbraucher sich in dieser Warteschlange registriert, und versucht dann erneut, auszuliefern.
Nachrichten ablehnen
Wenn ein Konsument eine Nachricht erhält, kann der Verarbeitungsprozess erfolgreich sein oder scheitern. Der Verbraucher kann dem Nachrichtenbroker (Message Middleware) mitteilen, dass die Nachricht aufgrund einer "abgelehnten Nachricht" nicht verarbeitet wurde (oder zu diesem Zeitpunkt nicht abgeschlossen wurde).
Wenn eine Nachricht abgelehnt wird, kann der Verbraucher dem Nachrichtenvermittler sagen, was er mit der Nachricht tun soll – sie zu vernichten oder zurück in die Warteschlange zu legen.
Wenn sich nur ein Konsument in dieser Warteschlange befindet, stellen Sie sicher, dass Sie die Nachricht nicht ablehnen und sie nicht zurück in die Warteschlange legen, wodurch die Nachricht auf demselben Konsumenten unbegrenzt in Schleife läuft.
In AMQP wird die Methode basic.reject verwendet, um die Operation des Ablehnens von Nachrichten durchzuführen. Allerdings hat basic.reject eine Einschränkung: Du kannst es nicht verwenden, um mehrere Nachrichten mit Bestätigungen abzulehnen. Aber wenn du RabbitMQ verwendest, kannst du die AMQP 0-9-1-Erweiterung namens negative Bestätigungen (auch Nacks genannt) verwenden, um dieses Problem zu lösen.
Original:Der Hyperlink-Login ist sichtbar.
|
Veröffentlicht am 14.08.2022 23:22:55
|
|
|
|
