Deel 4: RabbitMQ Uitwisselingen, routing keys en bindingen

Wat is een uitwisseling? Wat zijn routing keys en bindings? Hoe zijn exchanges en queues met elkaar verbonden? Wanneer moet ik ze gebruiken en hoe? Dit artikel legt de verschillende soorten uitwisselingen in RabbitMQ uit en scenario’s voor het gebruik ervan.

Boodschappen worden niet direct gepubliceerd naar een wachtrij. In plaats daarvan, stuurt de producent berichten naar een uitwisseling. Exchanges zijn bericht routing agents, gedefinieerd door de virtuele host binnen RabbitMQ. Een exchange is verantwoordelijk voor het routeren van berichten naar verschillende wachtrijen met behulp van header attributen, bindingen, en routing keys.

Abinding is een “link” die je instelt om een wachtrij te binden aan een exchange.

Therouting key is een berichtattribuut waarnaar de exchange kijkt bij de beslissing hoe het bericht naar wachtrijen moet worden geleid (afhankelijk van het type exchange).

Exchanges, verbindingen en wachtrijen kunnen worden geconfigureerd met parameters zoals duurzaam, tijdelijk en automatisch verwijderen bij creatie. Duurzame uitwisselingen overleven server herstarts en blijven bestaan totdat ze expliciet worden verwijderd. Tijdelijke uitwisselingen blijven bestaan totdat RabbitMQ wordt afgesloten. Automatisch verwijderde uitwisselingen worden verwijderd zodra het laatste gebonden object is losgekoppeld van de uitwisseling.

In RabbitMQ, zijn er vier verschillende soorten uitwisselingen die het bericht anders routeren met behulp van verschillende parameters en bindings setups. Clients kunnen hun eigen exchanges maken of gebruik maken van de voorgedefinieerde standaard exchanges die worden aangemaakt wanneer de server voor de eerste keer start.

  1. De producent publiceert een bericht naar de exchange.
  2. De exchange ontvangt het bericht en is nu verantwoordelijk voor de routering van het bericht.
  3. Binding moet worden opgezet tussen de wachtrij en de exchange. In dit geval hebben we bindingen naar twee verschillende wachtrijen van de centrale. De exchange routeert het bericht naar de wachtrijen.
  4. De berichten blijven in de wachtrij totdat ze worden afgehandeld door een consument.
  5. De consument handelt het bericht af.

Als je niet bekend bent met RabbitMQ en message queueing, lees danRabbitMQ voor beginners – wat is RabbitMQ?voordat u leest over uitwisselingen, routing keys, headers, en bindings.

Directe uitwisseling

Een directe uitwisseling levert berichten aan wachtrijen op basis van een bericht routing sleutel. De routingsleutel is een berichtattribuut dat door de producent aan de berichtkop wordt toegevoegd. Een bericht gaat naar de wachtrij(en) met de bindingssleutel die precies overeenkomt met de routingsleutel van het bericht.

Het directe uitwisselingstype is nuttig om berichten te onderscheiden die aan dezelfde uitwisseling zijn gepubliceerd met behulp van een eenvoudige string-identifier.

De standaard uitwisseling AMQP brokers moeten bieden voor de directe uitwisseling is “amq.direct”.

Stel je voor dat wachtrij A (create_pdf_queue) in de afbeelding hieronder (Direct Exchange Figuur) is gebonden aan een directe uitwisseling (pdf_events) met de bindende keypdf_create.Wanneer een nieuw bericht met routing keypdf_create bij de directe uitwisseling aankomt, routeert de uitwisseling het naar de wachtrij waar de binding_key = routing_key, in dit geval naar wachtrij A (create_pdf_queue).

Scenario 1

  • Uitwisseling: pdf_events
  • Wachtrij A: create_pdf_queue
  • Bindende sleutel tussen uitwisseling (pdf_events) en wachtrij A (create_pdf_queue): pdf_create

Scenario 2

  • Uitwisseling: pdf_events
  • Queue B: pdf_log_queue
  • Bindende sleutel tussen uitwisseling (pdf_events) en Queue B (pdf_log_queue): pdf_log

Example

Example: Een bericht met routingsleutel pdf_log wordt naar de exchangepdf_events gestuurd.Het bericht wordt naar de pdf_log_queue gerouteerd omdat de routingsleutel (pdf_log) overeenkomt met de bindingssleutel (pdf_log).

Als de routingsleutel van het bericht niet overeenkomt met een bindingssleutel, wordt het bericht verworpen.

Directe uitwisseling: Een bericht gaat naar de wachtrijen waarvan de bindingssleutel precies overeenkomt met de routingsleutel van het bericht.

Default exchange

De default exchange is een vooraf gedeclareerde directe exchange zonder naam, meestal aangeduid met een lege tekenreeks. Wanneer u de standaard uitwisseling gebruikt, wordt uw bericht afgeleverd in de wachtrij met een naam die gelijk is aan de routingsleutel van het bericht. Elke wachtrij is automatisch gebonden aan de standaard uitwisseling met een routeringssleutel die gelijk is aan de wachtrijnaam.

Topic Exchange

Topic uitwisselingen routeren berichten naar wachtrijen op basis van wildcard overeenkomsten tussen de routeringssleutel en het routeringspatroon, dat wordt gespecificeerd door de wachtrijbinding. Berichten worden gerouteerd naar een of meer wachtrijen op basis van een match tussen een routingsleutel voor berichten en dit patroon.

De routingsleutel moet een lijst van woorden zijn, begrensd door een punt (.). Voorbeelden zijnagreements.usenagreements.eu.stockholm, die in dit geval overeenkomsten identificeert die zijn opgesteld voor een bedrijf met kantoren op veel verschillende locaties. De routeringspatronen kunnen een sterretje (“*”) bevatten om overeen te komen met een woord op een specifieke positie van de routeringssleutel (bijvoorbeeld, een routeringspatroon van “agreements.*.*.b.*” komt alleen overeen met routeringssleutels waarbij het eerste woord “agreements” is en het vierde woord “b” is). Een pond-symbool (“#”) geeft een overeenkomst van nul of meer woorden aan (bijv. een routeringspatroon van “agreements.eu.berlin.#” komt overeen met alle routeringssleutels die beginnen met “agreements.eu.berlin”).

De consumenten geven aan in welke onderwerpen zij geïnteresseerd zijn (zoals het abonneren op een feed voor een individuele tag). De consument creëert een wachtrij en stelt een binding op met een bepaald routeringspatroon naar de uitwisseling. Alle berichten met een routing key die overeenkomen met het routing patroon worden gerouteerd naar de wachtrij en blijven daar totdat de consument het bericht consumeert.

De standaard uitwisseling AMQP brokers moeten voorzien voor de topic uitwisseling is “amq.topic”.

Scenario 1

De afbeelding rechts toont een voorbeeld waarbij consument A geïnteresseerd is in alle overeenkomsten in Berlijn.

  • Exchange: agreements
  • Que A: berlin_agreements
  • Routingpatroon tussen exchange (agreements) en Queue A (berlin_agreements): agreements.eu.berlin.#
  • Voorbeeld van berichtrouteringssleutel die overeenkomt: agreements.eu.berlin en agreements.eu.berlin.headstore

Scenario 2

Consument B is geïnteresseerd in alle overeenkomsten.

  • Uitwisseling: overeenkomsten
  • Queue B: all_agreements
  • Routingspatroon tussen uitwisseling (overeenkomsten) en Queue B (all_agreements): overeenkomsten.#
  • Voorbeeld van berichtrouteringssleutel die overeenkomt: agreements.eu.berlin en agreements.us

Topic Exchange: Berichten worden gerouteerd naar een of meer wachtrijen op basis van een overeenkomst tussen een berichtroutingsleutel en het routingpatroon.

Scenario 3

Consument C is geïnteresseerd in alle overeenkomsten voor Europese hoofdvestigingen.

  • Uitwisseling: agreements
  • Queue C: headstore_agreements
  • Routingspatroon tussen uitwisseling (agreements) en Queue C (headstore_agreements): agreements.eu.*.headstore
  • Voorbeeld van routingsleutels voor berichten die overeenkomen: agreements.eu.berlin.headstore en agreements.eu.stockholm.headstore

Example

Een bericht met routingsleutel agreements.eu.berlinwordt verzonden naar de exchangeagreements.De berichten worden gerouteerd naar de queueberlin_agreementsomdat het routingpatroon van “agreements.eu.berlin.#” overeenkomt met de routingsleutels die beginnen met “agreements.eu.berlin”. Het bericht wordt ook naar de queueall_agreements gerouteerd omdat de routingsleutel (agreements.eu.berlin) overeenkomt met het routingpatroon (agreements.#).

Fanout Exchange

Een fanout exchange kopieert en routeert een ontvangen bericht naar alle wachtrijen die eraan gebonden zijn, ongeacht de routingsleutels of het overeenkomende patroon zoals bij direct en topic exchanges. De verstrekte sleutels worden gewoon genegeerd.

Fanout-uitwisselingen kunnen nuttig zijn wanneer hetzelfde bericht moet worden verzonden naar een of meer wachtrijen met consumenten die hetzelfde bericht op verschillende manieren kunnen verwerken.

De afbeelding rechts (Fanout-uitwisseling) toont een voorbeeld waarbij een door de uitwisseling ontvangen bericht wordt gekopieerd en gerouteerd naar alle drie wachtrijen die aan de uitwisseling zijn gebonden. Het kan bijvoorbeeld gaan om sport- of weerberichten die naar elk aangesloten mobiel apparaat moeten worden gestuurd als er iets gebeurt.

De standaard uitwisseling die AMQP-brokers moeten bieden voor de onderwerpuitwisseling is “amq.fanout”.

Fanout Exchange: Het ontvangen bericht wordt gerouteerd naar alle wachtrijen die aan de uitwisseling zijn gebonden.

Scenario 1

  • Uitwisseling: sport_news
  • Queue A: Mobile client queue A
  • Binding: Binding tussen de uitwisseling (sport_news) en Queue A (Mobile client queue A)

Example

Er wordt een bericht gestuurd naar de uitwisseling sport_news.Het bericht wordt gerouteerd naar alle wachtrijen (Queue A, Queue B, Queue C) omdat alle wachtrijen gebonden zijn aan de uitwisseling. Opgegeven routingsleutels worden genegeerd.

Headers Uitwisseling

Een headers uitwisseling routeert berichten op basis van argumenten die headers en optionele waarden bevatten. Headers uitwisselingen zijn zeer vergelijkbaar met topic uitwisselingen, maar route berichten op basis van header waarden in plaats van routing sleutels. Een bericht komt overeen als de waarde van de header gelijk is aan de waarde die bij de binding is opgegeven.

Een speciaal argument genaamd “x-match”, toegevoegd in de binding tussen exchange en queue, geeft aan of alle headers overeen moeten komen of slechts één. Ofwel elke gemeenschappelijke header tussen het bericht en de binding telt als een match, ofwel alle headers waarnaar verwezen wordt in de binding moeten aanwezig zijn in het bericht om het te laten matchen. De “x-match” eigenschap kan twee verschillende waarden hebben: “any” of “all”, waarbij “all” de standaardwaarde is. Een waarde van “all” betekent dat alle headerparen (key, value) moeten overeenkomen, terwijl een waarde van “any” betekent dat ten minste één van de headerparen moet overeenkomen. Headers kunnen worden geconstrueerd met een breder scala aan gegevenstypen, bijvoorbeeld integer of hash, in plaats van een string. Het uitwisselingstype headers (gebruikt met het bindingsargument “any”) is nuttig voor het sturen van berichten die een subset van bekende (ongeordende) criteria bevatten.

De standaard uitwisseling die AMQP-brokers moeten leveren voor de topic-uitwisseling is “amq.headers”.

Example

Scenario 3

Bericht 3 wordt gepubliceerd aan de uitwisseling met header-argumenten van (key = value): “format = zip”, “type = log”.

Het is de moeite waard op te merken dat in een header uitwisseling, de werkelijke volgorde van de key-value paren in het bericht irrelevant is.

Dead Letter Exchange

Als er geen passende wachtrij voor het bericht kan worden gevonden, wordt het bericht stilzwijgend gedropt. RabbitMQ biedt een AMQP-extensie die bekend staat als de “Dead Letter Exchange”, waarmee berichten kunnen worden opgevangen die niet kunnen worden afgeleverd.

E-mail ons [email protected] als u suggesties hebt over ontbrekende inhoud of andere feedback.

Guide – RabbitMQ voor beginners

Vindt u dit artikel leuk? Vergeet het niet te delen met anderen. 😉

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.