Phenquestions
Kedykoľvek chceme do našej aplikácie integrovať sprostredkovateľov správ, čo nám umožňuje jednoduché škálovanie a pripojenie nášho systému asynchrónnym spôsobom, existuje veľa sprostredkovateľov správ, ktorí si môžu vytvoriť zoznam, z ktorého ste vybratí, napríklad:
- RabbitMQ
- Apache Kafka
- ActiveMQ
- AWS SQS
- Redis
Každý z týchto sprostredkovateľov správ má svoj vlastný zoznam výhod a nevýhod, ale najnáročnejšie možnosti sú prvé dva, RabbitMQ a Apache Kafka. V tejto lekcii uvedieme zoznam bodov, ktoré môžu pomôcť zúžiť rozhodnutie ísť s jedným nad druhým. Na záver stojí za to poukázať na to, že žiaden z nich nie je vo všetkých prípadoch použitia lepší ako iný a úplne záleží na tom, čo chcete dosiahnuť, takže neexistuje jedna správna odpoveď!
Začneme jednoduchým zavedením týchto nástrojov.
Apache Kafka
Ako sme si povedali v tejto lekcii, Apache Kafka je distribuovaný protokol odolný voči chybám, horizontálne škálovateľný. To znamená, že Kafka dokáže veľmi dobre rozdeliť a riadiť výraz, dokáže replikovať vaše dáta, aby zabezpečila dostupnosť, a je vysoko škálovateľná v tom zmysle, že za behu môžete zahrnúť nové servery, aby ste zvýšili svoju kapacitu na správu ďalších správ.
Výrobca a spotrebiteľ spoločnosti Kafka
RabbitMQ
RabbitMQ je všeobecnejší a jednoduchšie použiteľný sprostredkovateľ správ, ktorý sám vedie záznamy o tom, aké správy klient spotreboval, a pretrváva v tom druhom. Aj keď z nejakého dôvodu server RabbitMQ vypadne, môžete si byť istí, že správy, ktoré sa momentálne nachádzajú vo frontoch, boli uložené v súborovom systéme, takže keď sa server RabbitMQ znova vráti, môžu byť tieto správy konzistentne spracované spotrebiteľmi.
RabbitMQ pracuje
Veľmoc: Apache Kafka
Kafkova hlavná superveľmoc spočíva v tom, že sa dá použiť ako systém radov, ale to nie je obmedzené na. Kafka je niečo viac kruhový nárazník ktorý sa môže zväčšiť rovnako ako disk na stroji v klastri, a tak nám umožní znovu čítať správy. To môže urobiť klient bez toho, aby musel závisieť od kafkovského klastra, pretože je úplne na klientovi, aby si všimol metadáta správy, ktoré práve číta, a môže neskôr v stanovenom intervale znova navštíviť Kafku a prečítať si tú istú správu znova.
Upozorňujeme, že čas, v ktorom je možné túto správu znova prečítať, je obmedzený a je možné ho nakonfigurovať v konfigurácii Kafka. Akonáhle teda ten čas uplynie, neexistuje spôsob, ako by si klient mohol prečítať staršiu správu znova.
Veľmoc: RabbitMQ
Hlavnou superveľmocou RabbitMQ je, že je jednoducho škálovateľná, je to vysoko výkonný systém radenia do frontu, ktorý má veľmi dobre definované pravidlá konzistencie a schopnosť vytvárať mnoho typov modelov výmeny správ. Existujú napríklad tri typy výmeny, ktoré môžete vytvoriť v RabbitMQ:
- Priama výmena: Individuálna výmena tém
- Výmena tém: A téma je definované, na ktorom môžu rôzni producenti zverejniť správu a rôzni spotrebitelia sa môžu zaviazať, že budú počúvať túto tému, takže každý z nich dostane správu, ktorá sa na túto tému pošle.
- Výmena fanout: Je to prísnejšie ako výmena tém, pretože keď je správa zverejnená na výmene fanout, správu dostanú všetci zákazníci, ktorí sú pripojení k frontom, ktoré sa viažu na výmenu fanout.
Už som si všimol rozdiel medzi RabbitMQ a Kafkou? Rozdiel je v tom, že ak spotrebiteľ nie je v čase zverejnenia správy pripojený k výmennej stanici v RabbitMQ, stratí sa to, pretože správu spotrebovali iní spotrebitelia, čo sa však v Apache Kafka nestane, pretože každý spotrebiteľ si môže prečítať ktorúkoľvek správu ako udržiavajú svoj vlastný kurzor.
RabbitMQ je zameraný na sprostredkovateľa
Dobrý sprostredkovateľ je niekto, kto zaručuje prácu, ktorá sa berie na seba, a v tom je RabbitMQ dobrý. Je naklonený k záruky doručenia medzi výrobcami a spotrebiteľmi, pričom pred trvalými správami sa uprednostňuje prechodný jav.
RabbitMQ používa samotného sprostredkovateľa na správu stavu správy a na zabezpečenie toho, aby bola každá správa doručená každému oprávnenému spotrebiteľovi.
RabbitMQ predpokladá, že spotrebitelia sú väčšinou online.
Kafka je zameraný na výrobcu
Apache Kafka je zameraný na výrobcu, pretože je úplne založený na rozdelení a prúde paketov udalostí obsahujúcich údaje a ich transformácii na trvalých sprostredkovateľov správ pomocou kurzorov, podpory dávkových spotrebiteľov, ktorí môžu byť offline, alebo online spotrebiteľov, ktorí chcú správy s nízkou latenciou.
Kafka zaisťuje, že správa zostane bezpečná až do stanoveného časového obdobia, a to replikáciou správy na jej uzloch v klastri a udržiavaním konzistentného stavu.
Takže, Kafka nie predpokladať, že ktorýkoľvek z jej spotrebiteľov je väčšinou online, a to ho nezaujíma.
Objednávanie správ
U RabbitMQ objednávka publikačná činnosť je riadená dôsledne a spotrebitelia dostanú správu v samotnom zverejnenom poradí. Na druhej strane to Kafka nerobí, pretože predpokladá, že zverejnené správy majú ťažký charakter, takže spotrebitelia sú pomalí a môžu správy odosielať v ľubovoľnom poradí, takže objednávku nezvláda tiež. Môžeme však nastaviť podobnú topológiu na spravovanie objednávky v Kafke pomocou dôsledná výmena hash alebo sharding plugin., alebo ešte viac druhov topológií.
Úplnou úlohou, ktorú riadi Apache Kafka, je pôsobiť ako „tlmič nárazov“ medzi nepretržitým tokom udalostí a spotrebiteľmi, z ktorých sú niektorí online a iní môžu byť offline - iba hromadná konzumácia každú hodinu alebo dokonca každý deň.
Záver
V tejto lekcii sme študovali hlavné rozdiely (a tiež podobnosti) medzi Apache Kafkou a RabbitMQ. V niektorých prostrediach oba vykazovali mimoriadny výkon, napríklad RabbitMQ spotrebuje milióny správ za sekundu a Kafka spotrebuje niekoľko miliónov správ za sekundu. Hlavný architektonický rozdiel je v tom, že RabbitMQ spravuje svoje správy takmer v pamäti, a preto používa veľký klaster (viac ako 30 uzlov), zatiaľ čo Kafka v skutočnosti využíva právomoci postupných I / O operácií na disku a vyžaduje menej hardvéru.
Opäť platí, že použitie každého z nich stále úplne závisí od prípadu použitia aplikácie. Šťastné správy !
