Przy tworzeniu wymiany Direct, wiadomość zostanie skierowana do kolejki, która jest z nią związana.
Ok Julio, ale jeśli mam 2 kolejki na tej wymianie?
Dobre pytanie mój przyjacielu! 😉
W tym przypadku Routing Key nabiera mocy.
Routing Key jest atrybutem odpowiedzialnym za informowanie giełdy, do której kolejki powinien być skierowany komunikat.
Uwaga: Wymiana skieruje otrzymany komunikat tylko do kolejek, które mają dokładnie taki sam klucz routingu.
Uwaga 2: Jeżeli kolejki związane mają taki sam klucz routingu, to komunikat jest kierowany do tych kolejek równolegle.
Fanout
W przeciwieństwie do typu Direct, w fanout nie mamy postaci Routing Key.
Kiedy wymiana Fanout otrzymuje wiadomość, kopia tej wiadomości jest wysyłana do wszystkich kolejek z nią związanych.
Topic
Wyobraźmy sobie, że typ Topic jest typem Direct, ale ze szczególnym uwzględnieniem wzorców Routing Keys.
W Topic możliwe jest użycie wzorców dla kluczy routingu.
Wzorce te mogą być tworzone przy użyciu znaków * i #.
Gdy tworzymy wzorzec klucza routingu za pomocą #, mówimy giełdzie, że ten # może być zastąpiony przez 0 lub n słów.
Gdy używamy *, mówimy giełdzie, że * może być zastąpiony tylko przez 1 słowo.
Więc, gdy wymiana typu Topic otrzyma wiadomość, sprawdzi klucz routingu wiadomości, porówna z kluczami routingu kolejek i wyśle kopię tej wiadomości do wszystkich kolejek, w których klucze routingu (wiadomości i kolejki) łączą się.
Przykład:
Message Routing Key: routing.key.test
W powyższym przypadku wiadomość zostanie wysłana do kolejki 1, 3 i 4. Nie zostanie wysłana do 2, ponieważ wzorzec wymaga, aby po „routing.” było tylko jedno słowo, a w naszym przypadku są 2.
Headers
Przed wyjaśnieniem tej wymiany należy poinformować, że możliwe jest wysyłanie atrybutów w nagłówku wiadomości (podobnie jak w nagłówku HTTP)
Wymiana Headers jest podobna do Topic, ale zamiast porównywać Routing Key, porównuje atrybuty obecne w nagłówku wiadomości z atrybutami obecnymi w argumentach zdefiniowanych, gdy wiążemy kolejkę w wymianie.
Możliwe jest stworzenie reguły dla tej walidacji.
Aby stworzyć taką regułę, używamy argumentu z kluczem „x-match” z 2 możliwymi wartościami: any i all.
Any jest porównywalne z || warunku, a all jest porównywalne z &&.
Przykład:
Gdy wysyłamy wiadomość z argumentem {„key1”: „value1”} w jego nagłówku, wiadomość ta zostanie skierowana tylko do kolejki „headers.queue1”, ponieważ w jej nagłówku znajduje się atrybut {„key1”: „value1”} w argumentach dla tej kolejki.
W przypadku kolejki „headers.queue2”, wymiana zweryfikuje, czy nagłówek wiadomości zawiera 2 argumenty, ponieważ „x-match” jest ustawiony na all. Dlatego też giełda nie znajdzie argumentu {„key2”: „value2”} argumentu w nagłówku wiadomości i nie skieruje kopii tej wiadomości do tej kolejki.
Mam nadzieję, że to szybkie wyjaśnienie może pomóc Ci zrozumieć RabbitMQ Exchanges.
Aby dowiedzieć się więcej: https://www.rabbitmq.com/tutorials/amqp-concepts.html
Dołącz do naszej społeczności Slack i czytaj nasze cotygodniowe tematy Faun ⬇
.