Når du opretter en Direct exchange, vil den sende meddelelsen til den kø, der er bundet til den.
Okay Julio, men hvis jeg har to køer på denne exchange?
Godt spørgsmål, min ven! 😉
I dette tilfælde træder Routing Key i kraft.
Routing Key er en attribut, der er ansvarlig for at informere udvekslingen om, til hvilken kø meddelelsen skal dirigeres.
Bemærkning: Udvekslingen vil kun dirigere den modtagne meddelelse til køer, der har de nøjagtigt samme routingnøgler.
Bemærkning 2: Hvis de bundne køer har den samme routingnøgle, dirigeres denne meddelelse parallelt til disse køer.
Fanout
I modsætning til Direct-typen har vi i Fanout ikke figuren Routing Key.
Når en Fanout-udveksling modtager en meddelelse, sendes en kopi af denne meddelelse til alle køer, der er bundet til den.
Topic
Forestil dig, at Topic-typen er Direct-typen, men med særlige kendetegn, Routing Keys-mønstre.
I Topic er det muligt at bruge mønstre til routing keys.
Disse mønstre kan oprettes ved hjælp af *- og #-tegnene.
Når vi opretter et mønster for routingnøgler med #, fortæller vi udvekslingen, at dette # kan erstattes af 0 eller n ord.
Når vi bruger *, siger vi til udvekslingen, at * kun kan erstattes af 1 ord.
Derfor, når en udveksling af typen Topic modtager en meddelelse, vil den kontrollere meddelelsens Routing Key, sammenligne med køernes Routing Keys og sende en kopi af denne meddelelse til alle køer, hvor Routing Keys (meddelelse og kø) kombineres.
Eksempel:
Message Routing Key: routing.key.test
I ovenstående tilfælde vil meddelelsen blive sendt til kø 1, 3 og 4. Den vil ikke blive sendt til 2, fordi mønsteret kræver, at der kun er ét ord efter “routing.”, og i vores tilfælde er der 2.
Headers
Hvor vi forklarer denne udveksling, er det nødvendigt at oplyse, at det er muligt at sende attributter i en meddelelses header (svarende til HTTP-header)
Headers-udveksling svarer til Topic, men i stedet for at sammenligne Routing Key sammenligner den de attributter, der findes i meddelelsens header, med de attributter, der findes i de argumenter, der er defineret, når vi binder en kø i udvekslingen.
Det er muligt at oprette en regel for denne validering.
For at oprette denne regel bruger vi argumentet med “x-match”-nøglen med 2 mulige værdier: any og all.
Any kan sammenlignes med || af en betingelse og all kan sammenlignes med &&.
Eksempel:
Når vi sender en meddelelse med argumentet {“key1”: “value1”} i dens header, vil denne meddelelse kun blive dirigeret til køen “headers.queue1”, fordi der er attributten {“key1”: “
I tilfælde af “headers.queue2”-køen vil udvekslingen validere, om meddelelsens header indeholder de 2 argumenter, da “x-match” er sat til all. Derfor vil udvekslingen ikke finde {“key2”: “
Jeg håber, at denne hurtige forklaring kan hjælpe dig til at forstå RabbitMQ Exchanges.
For at få mere at vide: https://www.rabbitmq.com/tutorials/amqp-concepts.html
Gå med i vores community Slack og læs vores ugentlige Faun-emner ⬇