Wenn ein Direct Exchange erstellt wird, wird die Nachricht an die Warteschlange weitergeleitet, die an ihn gebunden ist.
Ok Julio, aber wenn ich 2 Warteschlangen auf diesem Exchange habe?
Gute Frage mein Freund! 😉
In diesem Fall kommt der Routing Key zum Tragen.
Routing Key ist ein Attribut, das dafür verantwortlich ist, der Vermittlungsstelle mitzuteilen, zu welcher Warteschlange die Nachricht geleitet werden soll.
Hinweis: Die Vermittlungsstelle leitet die empfangene Nachricht nur an Warteschlangen weiter, die den gleichen Routing-Schlüssel haben.
Hinweis 2: Wenn die gebundenen Warteschlangen den gleichen Routing-Schlüssel haben, wird die Nachricht parallel an diese Warteschlangen geleitet.
Fanout
Im Gegensatz zum Typ Direct gibt es beim Fanout keinen Routing Key.
Wenn eine Fanout-Vermittlung eine Nachricht empfängt, wird eine Kopie dieser Nachricht an alle an sie gebundenen Warteschlangen gesendet.
Topic
Stellen Sie sich vor, dass der Topic-Typ der Direct-Typ ist, aber mit einer Besonderheit, den Routing Keys Patterns.
Im Topic ist es möglich, Muster für Routing Keys zu verwenden.
Diese Muster können mit den Zeichen * und # erstellt werden.
Wenn wir ein Routing-Schlüsselmuster mit # erstellen, sagen wir der Vermittlungsstelle, dass dieses # durch 0 oder n Wörter ersetzt werden kann.
Wenn wir * verwenden, sagen wir der Vermittlungsstelle, dass * nur durch 1 Wort ersetzt werden kann.
Wenn also eine Vermittlungsstelle vom Typ Topic eine Nachricht erhält, prüft sie den Routing-Schlüssel der Nachricht, vergleicht ihn mit den Routing-Schlüsseln der Warteschlangen und sendet eine Kopie dieser Nachricht an alle Warteschlangen, in denen die Routing-Schlüssel (Nachricht und Warteschlange) übereinstimmen.
Beispiel:
Nachrichten-Routing-Schlüssel: routing.key.test
Im obigen Fall wird die Nachricht an Warteschlange 1, 3 und 4 gesendet. Sie wird nicht an die Warteschlange 2 gesendet, da das Muster verlangt, dass nur ein Wort nach „routing.“ steht, und in unserem Fall sind es 2.
Headers
Vor der Erläuterung dieses Austauschs ist es notwendig, darauf hinzuweisen, dass es möglich ist, Attribute im Header einer Nachricht zu senden (ähnlich dem Header von HTTP)
Headers exchange ist ähnlich wie Topic, aber anstatt den Routing Key zu vergleichen, werden die Attribute im Header der Nachricht mit den Attributen verglichen, die in den Argumenten enthalten sind, die beim Binden einer Warteschlange im Austausch definiert wurden.
Es ist möglich, eine Regel für diese Überprüfung zu erstellen.
Um diese Regel zu erstellen, verwenden wir das Argument mit dem Schlüssel „x-match“ mit 2 möglichen Werten: any und all.
Any ist vergleichbar mit || einer Bedingung und all ist vergleichbar mit &&.
Beispiel:
Wenn wir eine Nachricht mit dem Argument {„key1“: „value1“} in der Kopfzeile, wird diese Nachricht nur an die „headers.queue1“-Warteschlange weitergeleitet, da das Attribut {„key1“: „value1“} in den Argumenten für diese Warteschlange enthalten ist.
Im Falle der „headers.queue2“-Warteschlange prüft die Vermittlungsstelle, ob der Nachrichtenkopf die beiden Argumente enthält, da „x-match“ auf „all“ gesetzt ist. Daher findet die Vermittlungsstelle das Argument {„key2“: „value2“} im Message-Header nicht finden und wird keine Kopie der Nachricht an diese Warteschlange leiten.
Ich hoffe, dass diese kurze Erklärung Ihnen helfen kann, RabbitMQ Exchanges zu verstehen.
Um mehr zu erfahren: https://www.rabbitmq.com/tutorials/amqp-concepts.html
Treten Sie unserer Community Slack bei und lesen Sie unsere wöchentlichen Faun-Themen ⬇