🥇RabbitMQ. Partea 2. Înțelegem Exchanges

Exchange — schimb valutar sau punct de schimb. Mesajele sunt trimise în acesta. Exchange distribuie mesajul în una sau mai multe cozi. El rutează mesajele către coadă pe baza legăturilor create (bindings) între el și coadă.

Exchange nu este un proces Erlang. Din motive de scalabilitate exchange — aceasta este o linie (link către modulul cu codul unde se află logica de rutare) în baza de date încorporată mnesia. 1.000 de schimburi vor consuma doar 1MB de memorie.

Cuprins

RabbitMQ. Partea 1. Introducere. Erlang, AMQP și RPC
RabbitMQ. Partea 2. Să înțelegem schimburile
RabbitMQ. Partea 3. Înțelegem Queues și Bindings
RabbitMQ. Partea 4. Înțelegem ce reprezintă mesajele și cadrele
RabbitMQ. Partea 5. Performanța publicării și consumului de mesaje
RabbitMQ. Partea 6. Prezentarea modulelor Federation și Shovel
RabbitMQ. Partea 7. Detalii despre Conexiune și Canal
RabbitMQ. Partea 8. RabbitMQ în .NET
RabbitMQ. Partea 9. Monitorizare

Direct Exchange

Direct exchange — este utilizat când este necesar să livrăm un mesaj în cozi specifice. Mesajul este publicat în schimbul cu un anumit cheie de rutare și ajunge în toate cozile legate de acest schimb cu o cheie de rutare similară. Cheia de rutare este o linie. Căutarea corespondenței se face prin verificarea echivalenței liniilor.

Reprezentarea grafică a fluxului de mesaje:

În rabbitmq există un concept de schimb implicit. Aceasta direct exchange fără nume. Dacă se utilizează un schimb implicit, atunci mesajul va fi rutat către coada cu numele egal cu cheia de rutare a mesajului.

Topic Exchange

Topic exchange – similar direct exchange oferă posibilitatea de a realiza rutare selectivă prin compararea cheii de rutare. Dar, în acest caz, cheia este definită după un model. La crearea modelului se utilizează 0 una sau mai multe cuvinte (litere AZ și az și cifre 0-9), separate prin punct, precum și simboluri * și #.

* — poate fi înlocuit cu exact 1 cuvânt
# — poate fi înlocuit cu 0 una sau mai multe cuvinte

Reprezentarea grafică a fluxului de mesaje:

Începând cu versiunea RabbitMQ 2.4.0 algoritmul de rutare pentru topic exchange a început să funcționeze de 145 de ă ori mai repede. Acest lucru a fost realizat prin implementarea metodei trie implementation, care implică reprezentarea modelelor sub formă de structură de arbore. De exemplu, modelele a.b.c, a.*.b.c, a.#.c și b.b.c vor fi reprezentate de următoarea structură:

Căutarea corespondenței cu modelul se realizează, începând de la rădăcină și mergând de sus în jos.

Caracteristici:

aplicarea acestui schimb poate fi o alegere bună pentru o posibilă dezvoltare viitoare a aplicației, deoarece modelele pot fi întotdeauna configurate astfel încât mesajul să fie publicat similar direct exchange sau fanout exchange
modele care folosesc * este mult mai rapid, decât modelele care folosesc #.
topic exchange mai lent direct exchange

Fanout Exchange

Fanout exchange – toate mesajele sunt livrate în toate cozile chiar dacă în mesaj se specifică o cheie de rutare.

Caracteristici:

RabbitMQ nu funcționează cu chei de rutare și modele ceea ce influențează pozitiv performanța. Acesta este cel mai rapid exchange;
toți consumatorii ar trebui să aibă capacitatea de a procesa toate mesajele;

Reprezentarea grafică a fluxului de mesaje:

Headers Exchange

Headers exchange — direcționează mesajele în cozi conexe pe baza comparației perechilor (cheie, valoare) a proprietății headers întreținerii și a proprietății similare a mesajului. headers reprezintă Dictionary.

Dacă se adaugă o cheie specială în dicționar x-match cu valoarea any, atunci mesajul este rutat la o potrivire parțială a perechilor (cheie, valoare). Acest comportament este similar cu operatorul sau.

var bindingArguments = new Dictinary();
bindingArguments.add("x-match", "any");

În mod implicit, cheia x-match conține valoarea all. Aceasta înseamnă că mesajul este rutat la o potrivire completă a perechilor (cheie, valoare). Acest comportament este similar cu operatorul și.

Reprezentarea grafică a fluxului de mesaje:

Caracteristici:

flexibilitate suplimentară
costuri suplimentare de calcul. Toate perechile (cheie, valoare) ale atributului headers trebuie sortate după numele cheii înainte de a calcula valorile de rutare ale mesajului. Mai lent decât alte tipuri de exchange.

Consistent-Hashing Exchange

Această interschimbare este un plugin și nu este integrat în RabbitMQ.

Consistent-hashing exchange (exchange cu hash consistent) – este folosit atunci când există mai multe cozi care sunt potențiali destinatari ai mesajului și când trebuie să echilibrăm carga între ele. Relația mesajului cu coada se face pe greutate (o valoare de tip șir condiționată de la 0 - n).

Greutatea echivalentă a cozilor – indică faptul că în fiecare coadă va ajunge aproximativ aceeași cantitate de mesaje (fiecare mesaj va fi plasat doar într-o singură coadă). Nu există nicio garanție completă de distribuție uniformă a mesajelor.

Reprezentarea grafică a fluxului de mesaje:

Hash este calculat pe baza cheii de rutare sau a proprietății headers mesajului. Dacă toate mesajele publicate au avut chei de rutare diferite sau headers, atunci distribuția se va face pe greutate. În caz contrar, se va utiliza cheia de rutare sau headers.

Ar trebui să ajute atunci când capacitatea de procesare a consumatorului necesită o creștere mai mare decât soluția cu mai mulți consumatori folosind o singură coadă.

Combinarea exchange-urilor (E2E)

Comportamentul tuturor exchange-urilor poate fi combinat prin intermediul legăturii Exchange-to-Exchange (combinarea exchange-urilor nu este inclusă în specificație AMQP. Aceasta este o extensie a protocolului din partea RabbitMQ).

Reprezentarea grafică a fluxului de mesaje:

Prin E2E putem găsi configurația scalabilă potrivită, care îndeplinește atât cerințele actuale, cât și pe cele în creștere.

Crearea Exchange

Crearea unui exchanger se face printr-o RPC cerere sincronă la server. Cererea se face prin metoda Exchange.Declare, apelată cu următorii parametri:

numele exchanger-ului
tipul exchanger-ului
alte parametrii

Exemplu de creare exchange cu ajutorul RabbitMQ.Client:

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

exchange — numele exchanger-ului pe care dorim să-l creăm. Numele trebuie să fie unic.
type — tipul exchanger-ului
durabil — dacă se setează true, atunci exchange va fi permanent. Acesta va fi salvat pe disc și va putea supraviețui repornirii serverului/brokerului. Dacă valoarea false, atunci exchange este temporară și va fi ștearsă atunci când serverul/brokerul va fi repornit.
autoDelete — ștergere automată. Exchange va fi șters atunci când toate cozile asociate vor fi șterse.
arguments — argumente opționale. Cel mai adesea, prin argumente se definește alternative exchange (exchanger alternativ). Dacă mesajul nu poate urma ruta inițială, acesta poate fi trimis către exchanger-ul alternativ pentru a fi rutat pe o altă cale.

Dacă crearea exchange se poate, serverul va trimite clientului o cerere sincronă RPC răspuns Exchange.DeclareOk. Dacă crearea nu este posibil (s-a produs o eroare în cerere Exchange.Declare), atunci canalul se va închide de server printr-o comandă asincronă Channel.Close și clientul va primi o excepție OperationInterruptedException, care va conține codul de eroare și descrierea acesteia.

Exchanger-ul trebuie creat înainte de a publica mesaje. Dacă publicați un mesaj într-un exchanger inexistent — RabbitMQ îl va șterge în tăcere.

Crearea Exchange prin interfața grafică

Accesăm panoul de administrare RabbitMQ sub utilizatorul guest (username: guest și password: guest). Rețineți că utilizatorul guest se poate conecta doar de pe gazda locală. Acum să mergem la tab-ul Exchanges și să facem clic pe Adăugați un nou exchange. Completați proprietățile:

Majoritatea proprietăților au fost descrise mai sus. Aici menționăm că, dacă se setează Internal, atunci exchanger-ul poate fi utilizat doar pentru E2E. Producer nu va putea trimite mesaje către un astfel de exchanger.

Concluzie

Atunci când dezvoltați un sistem, este util să descrieți topologia rutării prin intermediul unui grafic. Dar înainte de a începe să construiți graficul, este bine să identificați căile cu un trafic mare, deoarece acestea necesită o lățime de bandă mai mare. (performanță). Apoi se poate clasifica traficul. Și abia apoi se poate începe construcția.

Dacă în graficul construit există un set final de chei de rutare, atunci este cazul să se ia în considerare mai multe fanout exchange, care sunt legate 1:1 de cheia de rutare. Să ne amintim că fanout exchange este cea mai rapidă.

Dacă numărul de rute tinde spre infinit, atunci este bine să ne concentrăm pe topic exchange sau, dacă șablonul nu este necesar, se poate alege direct exchange, deoarece este mai rapid topic exchange.

Combinarea diferitelor exchange ar trebui să ajute la găsirea configurației corecte scalabile, care răspunde atât cerințelor actuale, cât și celor în creștere ale sistemului.

Număr exchange iar cozii ar trebui să fie minime în comparație cu numărul de rute.

În articolul următor, vom începe să ne aprofundăm în Queues și Bindings.