🥇RabbitMQ. 2. rész. Az Exchanges elemzése

Exchange — váltó vagy váltóhely. Ide érkeznek az üzenetek. Exchange elosztja az üzenetet egy vagy több sorba. Az irányítja az üzeneteket a sorba a létrehozott kapcsolatok (kötések) a közöttük és a sor között.

Exchange nem Erlang-folyamat. Skálázhatósági szempontokból exchange — ez egy sor (hivatkozás a kódmodulra, ahol a routing logika található) az beépített adatbázisban mnesia. 1000 váltó mindössze 1 MB memóriát fog fogyasztani.

Tartalomjegyzék

RabbitMQ. 1. rész. Bevezetés. Erlang, AMQP és RPC
RabbitMQ. 2. rész. Az Exchanges részletezése
RabbitMQ. 3. rész. Queues és Bindings megértése
RabbitMQ. 4. rész. Nézzük meg, hogy mik azok az üzenetek és keretek
RabbitMQ. 5. rész. Az üzenetek közzétételi és fogyasztási teljesítménye
RabbitMQ. 6. rész. A Federation és Shovel modulok áttekintése
RabbitMQ. 7. rész. Részletesen a Kapcsolatról és csatornáról
RabbitMQ. 8. rész. RabbitMQ .NET környezetben
RabbitMQ. 9. rész. Monitoring

Direct Exchange

Direct exchange — akkor használatos, amikor üzenetet kell eljuttatni bizonyos sorokhoz. Az üzenet egy adott routing kulccsal kerül közzétételre a váltón, és elérkezik minden olyan sorhoz, amely ehhez a váltóhoz hasonló routing kulccsal kapcsolódik. A routing kulcs egy sor. Az egyezőség keresése a sorok egyezőségének ellenőrzésével történik.

A üzenetfolyam grafikus megjelenítése:

A rabbitmq létezik fogalom alapértelmezett váltó. Ez egy direct exchange név nélkül. Amikor az alapértelmezett váltót alkalmazzák, az üzenet azonosító néven fog kerülni a sorba, amely megegyezik az üzenet routing kulcsával.

Topic Exchange

Topic exchange – hasonlóan direct exchange lehetővé teszi a szelektív rutálást a routing kulcs összehasonlításával. De ebben az esetben a kulcs egy sablon alapján van megadva. A sablon létrehozásakor 0 vagy több szót (betűk AZ és az és számok 0-9), amelyeket pont választ el, valamint karakterek * és #.

* — pontosan 1 a "replica" szót (például az snd_ctl_add_slave() függvény helyett az snd_ctl_add_replica() lett használva), ami
# — helyettesíthető 0 vagy több szót

A üzenetfolyam grafikus megjelenítése:

A verziótól RabbitMQ 2.4.0 routing algoritmus a topic exchange korábban legalább amit 145 sokkal gyorsabban. Ezt a megközelítés bevezetésével érték el, trie implementation, amely a sablonokat fa struktúrában képviseli. Például a sablonok a.b.c, a.*.b.c, a.#.c és b.b.c a következő struktúrában lesznek reprezentálva:

A sablonhoz való egyezőséget gyökérből kezdve és fentről lefelé haladva keresik.

Jellemzők:

a váltó alkalmazása jó választás lehet az esetlegesen jövőbeli alkalmazásfejlesztéshez , mivel a sablonok mindig beállíthatók úgy, hogy az üzenetek közzététele hasonlóan történjenfanout exchange direct exchange vagy sablonok, amelyek használatban vannak
, mint a sablonok, amelyek használatban vannak * : a lépések sorrendje a következő:Fanout Exchange #.
topic exchange lassabban direct exchange

Fanout exchange

minden üzenetet minden sorhoz eljuttat – még akkor is, ha az üzenethez routing kulcsot rendelnek. nem működik routing kulcsokkal és sablonokkal

Jellemzők:

RabbitMQ ami kedvezően hat a teljesítményre. Ez a leggyorsabb ami pozitívan hat a teljesítményre. Ez a leggyorsabb exchange;
Minden felhasználónak képesnek kell lennie minden üzenetet feldolgozni;

A üzenetfolyam grafikus megjelenítése:

Fejlécek cseréje

Fejlécek cseréje — üzeneteket irányít a kapcsolt sorokhoz a kulcs-érték pár (property) összehasonlításának alapján fejlécek kötések és az üzenet hasonló property-jéhez. fejlécek jelentése Dictionary<kulcs, érték>.

Ha a szótárhoz egy speciális kulcsot adunk hozzá x-match az értékkel bármely, akkor az üzenet részleges kulcs-érték pár egyezés esetén kerül irányításra. Ez a viselkedés hasonló az vagy.

var bindingArguments = new Dictinary<String, Object>();
bindingArguments.add("x-match", "bármely");

Alapértelmezés szerint a kulcs x-match tartalmazza az értéket mind. Ez azt jelenti, hogy az üzenet teljes kulcs-érték pár egyezés esetén kerül irányításra. Ez a viselkedés hasonló az és.

A üzenetfolyam grafikus megjelenítése:

Jellemzők:

további rugalmasság
további számítási költségek. Az összes pár (kulcs, érték) attribútumot fejlécek kulcsmégnevezés szerint kell rendezni az üzenetirányítási értékek számítása előtt. Lassabb, mint más típusú cserék.

Konzisztens hash-elési csere

Ez a csere plugin és nem beépített be. RabbitMQ.

Konzisztens-hashelési csere (csere konzisztens hasheléssel) – akkor használatos, amikor több sor van, amelyek potenciális üzenetfogadók, és szükséges az elosztásük egyensúlyának biztosítása. Az üzenet kapcsolata a sorhoz súly alapú (kondicionális karakterlánc érték a 0 - n).

Az egyenértékű sorok súlya azt jelzi, hogy minden sor körülbelül azonos számú üzenetet fog kapni (minden egyes üzenet csak egy sorba kerülhet). A teljes egyenletes eloszlás garanciája nem létezik Hash.

A üzenetfolyam grafikus megjelenítése:

számítása a routing kulcs vagy az üzenet property alapján történik. Ha minden közzétett üzenet különböző routing kulccsal rendelkezett, vagy , akkor az eloszlás a súly alapján történik. Ellenkező esetben a routing kulcsot vagy fejlécek Segítenie kell, amikor a fogyasztó átbocsátó képessége olyan növekedésre szorul, amely meghaladja a megoldást, ahol több fogyasztó osztozik egy soron. fejlécekExchange-ek (E2E) kombinálása fejlécek.

Minden exchange viselkedése kombinálható az

Exchange-to-Exchange

(exchange-ek kombinálása nem tartozik a specifikáció . Ez a protokoll kiterjesztése A AMQPE2E RabbitMQ).

A üzenetfolyam grafikus megjelenítése:

segítségével megtalálhatjuk a megfelelő méretezhető konfigurációt, amely megfelel a jelenlegi és a növekvő igényeknek. E2E segítségével megtalálhatjuk a megfelelő méretezhető konfigurációt, amely megfelel a jelenlegi és a növekvő igényeknek.

Exchange létrehozása

Az Exchange létrehozása szinkron módszerrel történik RPC lekéréssel a szerverhez. A kérés a következő metódussal történik: Exchange.Declare, az alábbi paraméterekkel:

az exchange neve
exchange típusa
egyéb paraméterek

Létrehozási példa exchange a RabbitMQ.Client:

//...
channel.ExchangeDeclare(
    exchange: "my_exchange",
    type: "direct",
    durable: "false",
    autoDelete: "false",
    arguments: null
);
//...

exchange — az exchange neve, amit létre akarunk hozni. A névnek egyedinek kell lennie
type — az exchange típusa
durable — ha beállítja, igaz, akkor exchange állandó lesz. A lemezre menthető és túlélheti a szerver/broker újraindítását. Ha az érték hamis, akkor exchange ideiglenes, akkor törlésre kerül, amikor a szerver/broker újraindul
autoDelete — automatikus törlés. Exchange törölve lesz, amikor az összes hozzá kapcsolódó sor törlésre kerül
— választható argumentumok. Részletesebben lásd alább. — opcionális argumentumok. Leggyakrabban az argumentumokon keresztül adjuk meg alternatív exchange (alternatív exchange). Ha az üzenet nem tud átjutni az eredeti útvonalon, akkor az alternatív exchange-be irányítható másik úton.

Létrehozás esetén exchange lehetséges, a szerver szinkronikus RPC választ fog küldeni az ügyfélnek Exchange.DeclareOk. Ha a létrehozás lehetetlen (kérelmezés során hiba történt Exchange.Declare), akkor a csatorna le fog zárulni a szerver által aszinkron parancs segítségével Channel.Close parancs segítségével és az ügyfél kivételt kap OperationInterruptedException, amely tartalmazni fog egy hiba kódot és annak leírását.

Az exchange-nek létrejönnie kell az üzenetek publikálása előtt. Ha üzenetet publikál egy nem létező exchange-ben — RabbitMQ csendben törölni fogja.

Exchange létrehozása grafikus felületen

Belépünk az adminisztrátori panelre RabbitMQ a felhasználóval guest (felhasználónév: guest és jelszó: guest). Kérjük, vegye figyelembe, hogy a felhasználó guest csak a helyi gépről csatlakozhat. Most térjünk át a Cserék fülre és kattintsunk a Új exchange hozzáadása. Töltse ki a tulajdonságokat:

A legtöbb jellemzőt fentebb leírtuk. Itt említjük meg, hogy ha beállítja, Belső, akkor az exchange csak E2E. Producer nem tud üzeneteket küldeni egy ilyen exchange-re.

Zárás

A rendszer fejlesztése során kényelmes a topológia leírása irányítási grafikon segítségével. De mielőtt elkezdené felépíteni a grafikont, érdemes kiemelni a nagy forgalmú útvonalakat, mivel ezek igénylik magasabb áteresztő képességet (teljesítmény). Ezután a forgalom osztályozható. Majd előre lehet haladni az építkezéssel.

Ha a felépített grafikonban véges routing kulcsok száma létezik, érdemes több , amelyek 1:1 arányban kapcsolódnak a routing kulcshoz. Ne feledjük, hogy sablonok, amelyek használatban vannaka leggyorsabb. sablonok, amelyek használatban vannak Ha az útvonalak száma

a végtelenhez közelít, érdemes figyelembe venni vagy, ha nem szükséges a minta, akkor válassza adirect exchange topic exchange , mivel az gyorsabb Különböző kombinációkmeg kell, hogy találja a megfelelő topic exchange.

skálázható konfigurációt exchange , amely megfelel a rendszert jelenleg és a növekvő igényeinek is. és a sorok száma minimális kell, hogy legyen az útvonalak számához képest.A következő cikkben kezdjük el részletesebben megérteni a Queues-t és Bindings-ot.

Mennyiség exchange és a soroknak minimálisnak kell lenniük a szálak számához képest.

A következő cikkben részletesebben megvizsgáljuk a Queues és Bindings fogalmát.