A Direct csere létrehozásakor az üzenetet a hozzá kötött várólistára irányítja.
Ok Julio, de ha 2 várólista van ezen a cserén?
Jó kérdés barátom! 😉
Ebben az esetben a Routing Key lép életbe.
A Routing Key egy olyan attribútum, amely azért felelős, hogy tájékoztassa a cserét, hogy az üzenetet melyik sorba kell irányítani.
Megjegyzés: A központ csak olyan várólistákra irányítja a fogadott üzenetet, amelyeknek az útválasztási kulcsa pontosan megegyezik.
Megjegyzés 2: Ha a kötött várólistáknak ugyanaz az útválasztási kulcsa, akkor ez az üzenet párhuzamosan ezekre a várólistákra irányul.
Fanout
A Direct típussal ellentétben a Fanoutban nincs meg az útválasztási kulcs ábra.
Amikor egy Fanout csere üzenetet kap, ennek az üzenetnek a másolatát elküldi az összes hozzá kötött sorba.
Topic
Képzeljük el, hogy a Topic típus a Direct típus, de különlegességgel, az útválasztási kulcsok mintái.
A Topicban lehetőség van az útválasztási kulcsok mintáinak használatára.
Ezeket a mintákat a * és # karakterekkel lehet létrehozni.
Mikor # karakterrel hozunk létre egy útválasztási kulcsmintát, azt mondjuk a központnak, hogy ez a # 0 vagy n szóval helyettesíthető.
Mikor a * karaktert használjuk, azt mondjuk a központnak, hogy a * csak 1 szóval helyettesíthető.
Ezért, amikor egy Topic típusú központ üzenetet kap, ellenőrzi az üzenet útválasztási kulcsát, összehasonlítja a sorok útválasztási kulcsaival, és elküldi az üzenet másolatát minden olyan sorba, amelyben az útválasztási kulcsok (üzenet és sor) egyesülnek.
Példa:
Üzenet Routing Key: routing.key.test
A fenti esetben az üzenet az 1, 3 és 4 sorba kerül. A 2-be nem kerül elküldésre, mert a minta megköveteli, hogy a “routing.” után csak egy szó szerepeljen, és a mi esetünkben 2 van.
Headers
Mielőtt ezt a cserét elmagyaráznánk, szükséges tájékoztatni, hogy lehetőség van az üzenet fejlécében lévő attribútumok elküldésére (hasonlóan a HTTP fejlécéhez)
A Headers csere hasonló a Topic-hoz, de az útválasztási kulcs összehasonlítása helyett az üzenet fejlécében lévő attribútumokat hasonlítja össze a sorba kötéskor meghatározott argumentumokban lévő attribútumokkal a cserében.
Elkészíthetünk egy szabályt ehhez az érvényesítéshez.
A szabály létrehozásához az “x-match” kulcsú argumentumot használjuk 2 lehetséges értékkel: any és all.
A bármelyik a || feltételhez hasonlítható, az összes pedig a &&-hez.
Példa:
Ha egy üzenetet küldünk a {“kulcs1” argumentummal: “value1”} a fejlécében, akkor ez az üzenet csak a “headers.queue1” várólistára kerül, mert ott van az attribútum {“key1”: “
A “headers.queue2” várólista esetében a központ ellenőrzi, hogy az üzenet fejléce tartalmazza-e a 2 argumentumot, mivel az “x-match” értéke all. Ezért a csere nem fogja megtalálni a {“key2”: “value2”} argumentumot az üzenet fejlécében, és nem fogja az üzenet másolatát az adott várólistára irányítani.
Remélem, hogy ez a gyors magyarázat segíthet a RabbitMQ Exchanges megértésében.
Ha többet szeretne tudni: https://www.rabbitmq.com/tutorials/amqp-concepts.html
Lépjen be a Slack közösségünkbe és olvassa el a heti Faun témákat ⬇
.