Úvod do ActiveMQ vs Kafka
Apache ActiveMQ je open-source, multi-protokol, Java-based messaging server. Implementuje API JMS (Java Message Service) API a je schopný podporovať rôzne protokoly správ vrátane AMQP, STOMP a MQTT. Zvyčajne sa používa na odosielanie správ medzi aplikáciami / službami. V tejto téme sa dozvieme viac o ActiveMQ vs Kafka.
Na druhú stranu, Apache Kafka je open-source softvér na spracovanie toku vyvinutý spoločnosťou LinkedIn (a neskôr darovaný spoločnosti Apache) na efektívnu správu rastúcich údajov a prechod na spracovanie v reálnom čase z dávkového spracovania. Je napísaný v programoch Scala a Java a je založený na modeli odosielania a odberu správ.
Porovnanie vzájomných vzťahov medzi ActiveMQ a Kafkou (infografika)
Nižšie sú uvedené hlavné rozdiely medzi ActiveMQ a Kafkou
Kľúčové rozdiely medzi ActiveMQ a Kafkou
ActiveMQ a Kafka sú navrhnuté na rôzne účely. Nasledujú kľúčové rozdiely:
Kafka je distribuovaná streamovacia platforma, ktorá ponúka vysokú horizontálnu škálovateľnosť. Poskytuje tiež vysokú priepustnosť, a preto sa používa na spracovanie údajov v reálnom čase. ActiveMQ je univerzálne riešenie správ, ktoré podporuje rôzne protokoly správ. Kafka je oveľa rýchlejšia ako ActiveMQ. Dokáže spracovať milióny správ za sekundu.
ActiveMQ podporuje fronty správ a publikuje / predplatí systémy zasielania správ. Na druhej strane je spoločnosť Kafka založená na publikovaní / prihlásení na odber, má však určité výhody frontov správ.
ActiveMQ zaručuje, že správa bude doručená, ale s Kafkou existuje pravdepodobnosť (akokoľvek nízka), že správa nebude doručená.
Strata správ v Kafka sa môže vyskytnúť v nasledujúcom prípade:
- Môže sa to stať pri súčasnom náročnom prijímaní správ. Zvážte situáciu, keď spotrebiteľom prídu 2 správy: X a Y. Tieto dve správy sa spracúvajú súbežne. Počas spracovania správ bol Y úspešný a potvrdil posun. Pri manipulácii so správou však X spôsobil chybu. Vzhľadom na to, že správa B má väčší ofset, Kafka uloží posledný ofset a správa A sa k spotrebiteľovi už nikdy nevráti.
Je pomerne ľahšie implementovať doručovanie správ v ActiveMQ presne ako v Kafke. K duplicitnému doručovaniu správ v službe Kafka môže dôjsť v nasledujúcom prípade:
- Spotrebiteľ správy úspešne skonzumoval a potom ich zaviazal do svojho miestneho obchodu, ale havaroval a nemohol vykonať kompenzáciu voči Kafke skôr, ako došlo k jej zlyhaniu. Po reštarte zákazníka Kafka doručí správy z posledného ofsetu.
V Kafke je správa v podstate párom kľúč - hodnota. Užitočné zaťaženie správy je hodnota. Na druhej strane, kľúč sa všeobecne používa na účely rozdelenia na oddiely a musí obsahovať kľúč špecifický pre podnikanie, aby mohol umiestniť súvisiace správy na ten istý oddiel.
V ActiveMQ sa správa skladá z metadát (hlavičky a vlastnosti) a tela (čo je užitočné zaťaženie).
Porovnávacia tabuľka ActiveMQ vs Kafka
Poďme diskutovať o 10 najväčších rozdieloch medzi ActiveMQ a Kafkou
ActiveMQ | Kafka |
Je to tradičný systém správ, ktorý sa zaoberá malým množstvom údajov. Má nasledujúce prípady použitia:
| Je to distribuovaný systém určený na spracovanie obrovského množstva údajov. Má nasledujúce prípady použitia:
|
Má podporu transakcií. Podporujú sa dve úrovne transakcií:
TransactionStore používa na spracovanie transakcií. TransactionStore bude ukladať do vyrovnávacej pamäte všetky správy a ACKS, kým nedôjde k potvrdeniu alebo zrušeniu. | Kafka spočiatku nepodporovala transakcie, ale od svojho vydania 0, 11 podporuje transakcie do istej miery. |
Zachováva stav doručenia každej správy, čo vedie k nižšej priepustnosti. | Výrobcovia Kafky nečakajú na uznanie od sprostredkovateľov. Makléri teda môžu písať správy veľmi vysokou rýchlosťou, čo má za následok vyššiu priepustnosť |
V rámci ActiveMQ sú výrobcovia zodpovední za zabezpečenie doručovania správ. | V spoločnosti Kafka sú zodpovednosťou spotrebiteľov konzumovať všetky správy, ktoré majú konzumovať. |
Nemôže zabezpečiť, aby boli správy prijímané v rovnakom poradí, v akom boli odoslané. | Môže zabezpečiť, aby sa správy prijímali v poradí, v akom boli odoslané na úrovni oddielu. |
Existuje niečo, čo sa nazýva selektor správ JMS API, ktorý umožňuje spotrebiteľovi určiť správy, o ktoré sa zaujíma. Práca filtrovania správ je teda na JMS a nie na aplikáciách. | Kafka nemá žiadnu koncepciu filtrov u maklérov, ktorá by zabezpečila, že správy, ktoré vyzdvihnú zákazníci, zodpovedajú určitému kritériu. Filtrovanie sa musí vykonať spotrebiteľmi alebo aplikáciami. |
Je to platforma zasielania správ typu push, kde poskytovatelia zasielajú správy zákazníkom. | Je to platforma na zasielanie správ typu pull, kde zákazníci sťahujú správy od maklérov. |
Nie je možné škálovať vodorovne. Neexistuje ani koncepcia replikácie. | Je vysoko škálovateľná. Vďaka replikáciám oddielov ponúka aj vyššiu dostupnosť. |
Výkonnosť frontu aj témy klesá s rastúcim počtom spotrebiteľov. | To sa nespomalí s pridaním nových spotrebiteľov. |
Neposkytuje kontrolné súčty na zistenie poškodenia správ po vybalení. | Obsahuje kontrolné súčty na zistenie poškodenia správ v úložisku a obsahuje komplexnú sadu bezpečnostných funkcií. |
záver
Videli sme, že Kafka a ActiveMQ majú rôzne prípady použitia. Spoločnosť pôjde na spoločnosť Kafka, ak musí spracovať obrovské množstvo údajov v reálnom čase a do istej miery môže utrpieť stratu správy. Zatiaľ čo ActiveMQ by bola správna voľba, ak by sa zaujímala o jednorazové doručovanie a správy boli hodnotné (napríklad pri finančných transakciách).
Odporúčaný článok
Toto je sprievodca ActiveMQ verzus Kafka. Tu diskutujeme kľúčové rozdiely ActiveMQ vs Kafka s informačnými a porovnávacími tabuľkami. Ďalšie informácie nájdete aj v nasledujúcich článkoch -
- Kafka vs Spark
- Prasa verzus iskra
- Hadoop vs Apache Spark
- Apache Storm vs Kafka: 9 najlepších rozdielov, ktoré musíte vedieť