Czy jest jakiś powód, aby używać RabbitMQ zamiast Kafki?


332

Poproszono mnie o ocenę RabbitMQ zamiast Kafki, ale trudno mi było znaleźć powód, dla którego robi coś lepszego niż Kafka. Czy ktoś wie, czy naprawdę jest lepszy pod względem przepustowości, trwałości, opóźnień lub łatwości użytkowania?


7
oparte głównie na opiniach, wiele dobrych pytań generuje pewien stopień opinii na podstawie doświadczenia ekspertów, ale odpowiedzi na to pytanie będą zwykle prawie w całości oparte na opiniach, a nie faktach, referencjach lub konkretnej wiedzy specjalistycznej.
VdeX,

2
@Guillaume To niekoniecznie prawda. Istnieją klienci dla wielu języków dla Kafka: cwiki.apache.org/confluence/display/KAFKA/Clients Ponadto Confluent oferuje wielu wydajnych klientów Kafka typu open source w innych językach. Sprawdź ofertę „Confluent Open Source”: confluent.io/product/compare
Matthias J. Sax

3
@ MatthiasJ.Sax Zarówno RabbitMQ, jak i kafka mają mnóstwo klientów w wielu językach, ale moja uwaga dotyczyła klientów oficjalnych. W podanym linku jest napisane czarno na białym: utrzymujemy wszystko oprócz klienta Jvm poza główną bazą kodu . Jeśli chodzi o konfluent, jestem wprawdzie dużym użytkownikiem, ale dodatkowi klienci korzystają z interfejsu API agnostic rest, który, mimo że całkiem niesamowity, nie ma takiej samej przepustowości, jak oficjalny klient Java.
Guillaume,

2
@Guillaume Dla „losowych” klientów open source ze społeczności Zgadzam się; nie wszystkie mają wysoką wydajność (ciężko jest napisać dobrego klienta) - dlatego dodałem „To niekoniecznie prawda”. ;) Jednak dostarczone przez Confluent klienty C / C ++ i Python są bardzo wydajne i tak samo wydajne jak klienci AK Java ...
Matthias J. Sax 10'17

Polecam przeczytanie tego bloga: jack-vanlightly.com/blog/2017/12/4/…
roottraveller

Odpowiedzi:


467

RabbitMQ to solidny, uniwersalny broker komunikatów, który obsługuje kilka protokołów, takich jak AMQP, MQTT, STOMP itp. Może obsługiwać wysoką przepustowość. Częstym przypadkiem użycia RabbitMQ jest obsługa zadań w tle lub zadań długotrwałych, takich jak skanowanie plików , skalowanie obrazów lub konwersja PDF. RabbitMQ jest również używany między mikrousługami, gdzie służy jako środek komunikacji między aplikacjami, unikając wąskich gardeł w przekazywaniu wiadomości.

Kafka to szyna komunikatów zoptymalizowana pod kątem strumieni danych o wysokim stopniu wejścia i odtwarzania. Korzystaj z Kafka, gdy potrzebujesz przenieść dużą ilość danych, przetwarzać dane w czasie rzeczywistym lub analizować dane w pewnym okresie czasu. Innymi słowy, gdzie dane muszą być gromadzone, przechowywane i przetwarzane. Przykładem może być śledzenie aktywności użytkownika w sklepie internetowym i generowanie sugerowanych produktów do kupienia. Innym przykładem jest analiza danych w celu śledzenia, przyjmowania, rejestrowania lub bezpieczeństwa.

Kafka może być postrzegana jako trwały broker komunikatów, w którym aplikacje mogą przetwarzać i ponownie przetwarzać przesyłane strumieniowo dane na dysku. Kafka ma bardzo proste podejście do routingu. RabbitMQ ma lepsze opcje, jeśli chcesz kierować wiadomości w skomplikowany sposób do swoich klientów. Skorzystaj z Kafka, jeśli chcesz obsługiwać odbiorców wsadowych, którzy mogą być offline, lub klientów, którzy chcą wiadomości o niskim opóźnieniu. 

Aby zrozumieć, jak czytać dane z Kafki, najpierw musimy zrozumieć jej konsumentów i grupy konsumentów. Partycje umożliwiają zrównoleglenie tematu przez podzielenie danych na wiele węzłów. Każdy rekord w partycji jest przypisywany i identyfikowany przez jego unikalne przesunięcie. To przesunięcie wskazuje na rekord w partycji. W najnowszej wersji Kafki Kafka utrzymuje numeryczne przesunięcie dla każdego rekordu w partycji. Konsument w Kafce może albo okresowo automatycznie dokonywać przesunięć, albo może ręcznie kontrolować tę zatwierdzoną pozycję. RabbitMQ zachowa wszystkie stany dotyczące zużytych / potwierdzonych / niepotwierdzonych wiadomości. Uważam, że Kafka jest bardziej skomplikowany do zrozumienia niż przypadek RabbitMQ, w którym wiadomość jest po prostu usuwana z kolejki po jej potwierdzeniu.

Kolejki RabbitMQ są najszybsze, gdy są puste, a Kafka zatrzymuje duże ilości danych przy bardzo niewielkim obciążeniu - Kafka jest przeznaczony do przechowywania i dystrybucji dużych ilości wiadomości. (Jeśli planujesz mieć bardzo długie kolejki w RabbitMQ, możesz rzucić okiem na leniwe kolejki .)

Kafka jest budowana od podstaw z myślą o skalowaniu poziomym (skalowanie poprzez dodawanie większej liczby maszyn), podczas gdy RabbitMQ jest głównie przeznaczony do skalowania pionowego (skalowanie poprzez dodawanie większej mocy).

RabbitMQ ma wbudowany przyjazny dla użytkownika interfejs, który pozwala monitorować i obsługiwać serwer RabbitMQ z poziomu przeglądarki internetowej. Między innymi kolejki, połączenia, kanały, wymiany, użytkownicy i uprawnienia użytkowników mogą być obsługiwane - tworzone, usuwane i wyświetlane w przeglądarce, a także można monitorować szybkość wiadomości i ręcznie wysyłać / odbierać wiadomości. Kafka ma wiele narzędzi typu open source, a także kilka komercyjnych , oferujących funkcje administracji i monitorowania. Powiedziałbym, że łatwiej / robi się szybciej, aby dobrze zrozumieć RabbitMQ.

Więcej informacji na temat czytania i niektóre dane porównawcze można znaleźć tutaj: https://www.cloudamqp.com/blog/2019-12-12-when-to-use-rabbitmq-or-apache-kafka.html

Polecając także artykuł branżowy: „Kafka kontra RabbitMQ: Badanie porównawcze dwóch referencji branżowych dotyczących implementacji publikowania / subskrypcji”: http://dl.acm.org/citation.cfm?id=3093908

Pracuję w firmie świadczącej usługi Apache Kafka i RabbitMQ.


31
Co oznacza „wysoki stopień wejścia”?
Martin Thoma,

23
high-ingress = przetwarzanie o dużej przepustowości
jbustamovej

6
Mam wątpliwości dotyczące RabbitMQ „głównie zaprojektowanego do skalowania pionowego”. Jak to ...
Ryan.Bartsch

17
Skalowanie w poziomie (skalowanie przez dodanie większej liczby maszyn) nie zapewnia lepszej wydajności w RabbitMQ. Najlepszą wydajność uzyskuje się podczas skalowania w pionie (skalowanie poprzez dodanie większej mocy). Wiem to, ponieważ od wielu lat pracuję z tysiącami klastrów RabbitMQ. Możesz zrobić skalowanie w poziomie w Rabbit, ale to oznacza, że ​​skonfigurowałeś także klastrowanie między swoimi węzłami, co spowolni twoją konfigurację. Napisałem przewodnik na temat najlepszych praktyk w zakresie wysokiej wydajności vs wysokiej dostępności w RabbitMQ
Lovisa Johansson

4
„... podczas gdy Kafka tego nie robi, zakłada, że ​​konsument śledzi, co zostało zużyte, a nie”. To jest niepoprawne. Kafka śledzi wiadomości konsumowane przez każdego konsumenta.
jucardi

36

Słyszę to pytanie co tydzień ... Podczas gdy RabbitMQ (jak IBM MQ lub JMS lub ogólnie inne rozwiązania do przesyłania wiadomości) jest używany do tradycyjnego przesyłania wiadomości, Apache Kafka jest używany jako platforma przesyłania strumieniowego (przesyłanie wiadomości + rozproszone przechowywanie + przetwarzanie danych). Oba są zbudowane dla różnych przypadków użycia.

Możesz użyć Kafki do „tradycyjnego przesyłania wiadomości”, ale nie możesz używać MQ dla scenariuszy specyficznych dla Kafki.

Artykuł „ Apache Kafka vs. Enterprise Service Bus (ESB) - przyjaciele, wrogowie czy wrogowie? ( https://www.confluent.io/blog/apache-kafka-vs-enterprise-service-bus-esb-friends-en wrogów (w tym RabbitMQ) i jak zintegrować oba.


30

5 Główne różnice między Kafką a RabbitMQ, klientem, który ich używa: wprowadź opis zdjęcia tutaj

Który system przesyłania komunikatów wybrać, czy też powinniśmy zmienić nasz istniejący system przesyłania komunikatów?

Nie ma jednej odpowiedzi na powyższe pytanie. Jednym z możliwych podejście do przeglądu kiedy trzeba zdecydować, jaki system wiadomości lub należy zmienić istniejącego systemu jest „ Ocenić zakres i koszty


5
Gdzie jest twoje źródło tych informacji? Nie zgadzam się z twoją odpowiedzią dotyczącą wydajności w RabbitMQ - która zależy od liczby kolejek, połączeń itp.
Lovisa Johansson

Poprawny. Ale średni zakres wariancji jest podobny jak podano powyżej. Istnieją scenariusze, w których robi to lepiej lub gorzej niż wyżej wymieniony zakres. Zobacz blog Rabbitmq. Najnowsze punkty danych mogły ulec zmianie rabbitmq.com/blog/2012/04/25/…
Shishir

@Shishir - Czy możesz udostępnić więcej szczegółów / linków wyjaśniających różne typy wymiany wiadomości - bezpośrednie, fan out, pub / sub itp? Brzmi to jako pomocne w określeniu właściwej platformy przesyłania wiadomości dla danych wymagań. Dzięki
Andy Dufresne

@Shishir link z 2012 roku mógł ulec zmianie, tak.
Lovisa Johansson

@AndyDufresne, nieco spóźniony, ale oto link: cloudamqp.com/blog/…
Lovisa Johansson

28

Jedną z kluczowych różnic, o której zapomnieliście, jest to, że RabbitMQ to system przesyłania wiadomości oparty na push, podczas gdy Kafka to system przesyłania wiadomości oparty na pull. Jest to ważne w scenariuszu, w którym system przesyłania wiadomości musi zaspokajać różne typy konsumentów o różnych możliwościach przetwarzania. Dzięki systemowi opartemu na Pull konsument może konsumować w oparciu o swoje możliwości, w których systemy push będą wypychać wiadomości niezależnie od stanu konsumenta, narażając w ten sposób konsumenta na wysokie ryzyko.


3
Z RabbitMQ możesz osiągnąć zarówno pull, jak i push
Nikolas

16

RabbitMQ to tradycyjny broker komunikatów ogólnego przeznaczenia. Umożliwia serwerom internetowym szybkie reagowanie na żądania i dostarczanie wiadomości do wielu usług. Wydawcy mogą publikować wiadomości i udostępniać je w kolejkach, aby konsumenci mogli je pobrać. Komunikacja może być asynchroniczna lub synchroniczna.


Z drugiej strony Apache Kafka to nie tylko pośrednik wiadomości. Został pierwotnie zaprojektowany i wdrożony przez LinkedIn, aby służył jako kolejka wiadomości. Od 2011 r. Kafka została otwarta i szybko przekształciła się w rozproszoną platformę przesyłania strumieniowego, która służy do wdrażania potoków danych w czasie rzeczywistym i aplikacji do przesyłania strumieniowego.

Jest skalowalny w poziomie, odporny na uszkodzenia, szybko zły i działa w produkcji w tysiącach firm.

Nowoczesne organizacje mają różne potoki danych, które ułatwiają komunikację między systemami lub usługami. Sprawy stają się nieco bardziej skomplikowane, gdy rozsądna liczba usług musi komunikować się ze sobą w czasie rzeczywistym.

Architektura staje się złożona, ponieważ wymagane są różne integracje, aby umożliwić wzajemną komunikację tych usług. Mówiąc ściślej, dla architektury obejmującej m usługi źródłowe i n docelowe należy napisać odrębne integracje nxm. Ponadto każda integracja ma inną specyfikację, co oznacza, że ​​można wymagać innego protokołu (HTTP, TCP, JDBC itp.) Lub innej reprezentacji danych (Binary, Apache Avro, JSON itp.), Co sprawia, że ​​jest to jeszcze trudniejsze . Ponadto usługi źródłowe mogą rozwiązać zwiększone obciążenie połączeń, które może potencjalnie wpłynąć na opóźnienia.

Apache Kafka prowadzi do prostszych i łatwiejszych w zarządzaniu architektur poprzez oddzielenie potoków danych. Kafka działa jako rozproszony system o wysokiej przepustowości, w którym usługi źródłowe przekazują strumienie danych, udostępniając je usługom docelowym w celu pobierania ich w czasie rzeczywistym.

Ponadto dostępnych jest teraz wiele interfejsów użytkownika na poziomie korporacyjnym do zarządzania klastrami Kafka. Więcej informacji można znaleźć w moich artykułach Przegląd narzędzi do monitorowania interfejsu użytkownika dla klastrów Apache Kafka i Dlaczego Apache Kafka?


Decyzja, czy wybrać RabbitMQ, czy Kafkę, zależy od wymagań twojego projektu. Ogólnie rzecz biorąc, jeśli chcesz mieć prostego / tradycyjnego brokera wiadomości pub-sub, wybierz RabbitMQ. Jeśli chcesz zbudować architekturę opartą na zdarzeniach, na podstawie której Twoja organizacja będzie działała na wydarzeniach w czasie rzeczywistym, wybierz Apache Kafka, ponieważ zapewnia on więcej funkcji dla tego typu architektury (na przykład Strumienie Kafka lub ksqlDB).


15

Wiem, że jest trochę późno i może już to pośrednio powiedziałeś, ale znowu, Kafka wcale nie jest kolejką, to dziennik (jak ktoś powiedział powyżej, oparty na ankiecie).

Aby to uprościć, najbardziej oczywistym przypadkiem użycia, w którym powinieneś preferować RabbitMQ (lub dowolne kolejkowe techno) niż Kafka, jest:

Wielu klientów korzysta z kolejki i ilekroć w kolejce pojawi się nowa wiadomość i dostępny konsument, chcesz, aby ta wiadomość została przetworzona. Jeśli przyjrzysz się bliżej działaniu Kafki, zauważysz, że nie wie, jak to zrobić, ponieważ ze względu na skalowanie partycji będziesz mieć konsumenta poświęconego partycji i wpadniesz w problem głodu. Problem, którego można łatwo uniknąć, korzystając z prostej kolejki techno. Możesz pomyśleć o użyciu wątku, który rozsyła różne wiadomości z tej samej partycji, ale znowu, Kafka nie ma żadnych mechanizmów selektywnego potwierdzania.

Możesz zrobić tylko tych facetów i spróbować przekształcić Kafkę w kolejkę: https://github.com/softwaremill/kmq

Yannick


10

Użyj RabbitMQ, gdy:

  • Nie musisz obsługiwać Bigdata i wolisz wygodny wbudowany interfejs użytkownika do monitorowania
  • Nie ma potrzeby automatycznie replikowanych kolejek
  • Brak wielu subskrybentów dla wiadomości - Ponieważ w przeciwieństwie do Kafki, która jest dziennikiem, RabbitMQ jest kolejką, a wiadomości są usuwane po zużyciu i przychodzi potwierdzenie
  • Jeśli masz wymagania dotyczące używania symboli wieloznacznych i wyrażeń regularnych dla wiadomości
  • Jeśli zdefiniowanie priorytetu wiadomości jest ważne

W skrócie: RabbitMQ nadaje się do prostych zastosowań, z niskim ruchem danych, z korzyścią dla kolejki priorytetowej i elastycznych opcji routingu. Do ogromnych danych i dużej przepustowości użyj Kafka.


Wielu subskrybentów jest obsługiwanych dobrze, nie w jednej kolejce, ale rozkłada się na wiele i potencjalnie dynamicznych kolejek. Królik jest z pewnością nie tylko dla „prostych przypadków użycia”, ale dla zupełnie innych paragdimów, ale nie mniej złożony niż duże zbiory danych, które wymagają przechowywania przez długi czas. Czy możesz rozwinąć część z priorytetem wiadomości?
Owen

9

Podam obiektywną odpowiedź na podstawie mojego doświadczenia z obydwoma, pominę teorię, zakładając, że już ją znasz i / lub inne odpowiedzi już dostarczyły.

RabbitMQ : Wybrałbym ten, jeśli moje wymagania są wystarczająco proste, aby poradzić sobie z komunikacją systemu za pośrednictwem kanałów / kolejek, przechowywanie i przesyłanie strumieniowe nie jest wymagane. Na przykład, gdy system produkcyjny zbudował zasób, powiadamia system umów o skonfigurowaniu umów i tak dalej.

Kafka : Wymóg pozyskiwania zdarzeń głównie, gdy może być konieczne radzenie sobie ze strumieniami (czasami nieskończonymi), ogromną ilością danych jednocześnie odpowiednio zbalansowanymi, odtwarzaniem przesunięć w celu zapewnienia określonego stanu i tak dalej. Należy pamiętać, że ta architektura również powoduje większą złożoność, ponieważ obejmuje pojęcia takie jak tematy / partycje / brokerzy / wiadomości nagrobkowe itp. Jako pierwszorzędne znaczenie.


4

Jedyną korzyścią, jaką mogę wymyślić, jest funkcja transakcyjna, resztę można zrobić za pomocą Kafki


2
Kafka ma transakcje
OneCricketeer

2

Skalowanie obu jest trudne w sposób rozproszony, odporny na uszkodzenia, ale sprawiłbym, że przy RabbitMQ jest znacznie trudniej na masową skalę. Rozumienie Łopaty, Federacji, Dublowanych Msgów, ACK, Memów, Tollerance itp. Nie jest trywialne. Nie oznacza to, że nie będziesz mieć szczególnych problemów z Zookeeperem itp. Na Kafce, ale jest mniej ruchomych części do zarządzania. To powiedziawszy, dostajesz giełdę Polyglot z RMQ, której nie kupisz z Kafką. Jeśli chcesz streamować, użyj Kafka. Jeśli chcesz prostego dostarczania IoT lub podobnego pakietu o dużej objętości, skorzystaj z Kafki. Chodzi o inteligentnych konsumentów. Jeśli chcesz elastyczności msg i większej niezawodności przy wyższych kosztach i być może złożoności, skorzystaj z RMQ.


Nie zgadzam się z tym, jak wnioskujesz, że RMQ ma „pewną złożoność”, jakby chciał powiedzieć, że Kafka ma mniej złożoność.
Cory Robinson

1

Jeśli masz skomplikowane potrzeby routingu i chcesz, aby wbudowany interfejs GUI monitorował brokera, RabbitMQ może być najlepszym rozwiązaniem dla Twojej aplikacji. W przeciwnym razie, jeśli szukasz brokera wiadomości do obsługi wysokiej przepustowości i zapewnienia dostępu do historii transmisji, Kafka jest prawdopodobnie lepszym wyborem.


[+1] Dobre wyjaśnienie, jestem pewien, że używałeś ich w swoich projektach, czy mógłbyś wymienić tych, którzy używali jednego z nich do montowania systemów komunikatów aplikacji?
GingerHead

@GingerHead Współpracowaliśmy z firmą radiową, która używała RabbitMQ do obsługi GUI i łatwości konfiguracji. Świetnie było dla programistów łatwo sprawdzić status swoich mikrousług. Ta sama firma używała również Kafki do strumieni danych o dużej objętości, które musiały mieć czas przechowywania ponad trzy dni. Jeśli chcesz przeczytać więcej o różnicach między tymi dwiema technologiami, oto artykuł, który napisałem na ten temat: artykuł Kafka vs. RabbitMQ .
Maria Hatfield

0

Apache Kafka jest popularnym wyborem do zasilania potoków danych. Apache kafka dodał strumień kafka do obsługi popularnych przypadków użycia etl. KSQL ułatwia przekształcanie danych w potoku, przygotowując komunikaty do czystego lądowania w innym systemie. KSQL to silnik SQL przesyłania strumieniowego dla Apache Kafka. Zapewnia łatwy w użyciu, ale potężny interaktywny interfejs SQL do przetwarzania strumieniowego na Kafce, bez potrzeby pisania kodu w języku programowania, takim jak Java lub Python. KSQL jest skalowalny, elastyczny, odporny na uszkodzenia i działający w czasie rzeczywistym. Obsługuje szeroki zakres operacji przesyłania strumieniowego, w tym filtrowanie danych, transformacje, agregacje, łączenia, okienkowanie i sesjonowanie.

https://docs.confluent.io/current/ksql/docs/index.html

Rabbitmq nie jest popularnym wyborem dla systemów etl, a raczej dla tych systemów, w których wymaga prostych systemów przesyłania wiadomości o mniejszej przepustowości.


0

Zdaję sobie sprawę, że to stare pytanie, ale jednym ze scenariuszy, w których RabbitMQ może być lepszym wyborem, jest zajmowanie się redakcją danych.

W RabbitMQ domyślnie po zużyciu wiadomość jest usuwana. W Kafce domyślnie wiadomości są przechowywane przez tydzień. Często ustawia się to na znacznie dłuższy czas, a nawet nigdy ich nie usuwa.

Chociaż oba produkty można skonfigurować tak, aby zachowywały (lub nie zachowywały) wiadomości, jeśli problem dotyczy zgodności z CCPA lub RODO, wybrałbym RabbitMQ.


0

Kafka jest lepszy od RabbitMQ pod względem przepustowości, trwałości, opóźnień. Jeśli oczekujesz transakcji mniejszych niż 10 000 kb / s, możesz wybrać RabbitMQ, ale to również zależy od Twojej implementacji.

Zaimplementowałem Kafkę w naszym produkcie, w którym zajmowaliśmy się transakcjami przekraczającymi 70 000 kb / s, a opóźnienie wynosiło średnio 15 ms, a kilka skoków sięgało do 40 ms. Rozmiar tematu wynosił 100 KB.

Więcej punktów danych PFB na temat KAFKA i RabbitMQ: Apache Kafka zawiera samego brokera, który jest właściwie najlepiej znaną i najpopularniejszą jego częścią, i został zaprojektowany i promowany w scenariuszach przetwarzania strumieniowego. Oprócz tego Apache Kafka niedawno dodał strumienie Kafka, które pozycjonują się jako alternatywa dla platform strumieniowych takich jak Apache Spark, Apache Flink, Apache Beam / Google Cloud Data Flow i Spring Cloud Data Flow. Dokumentacja dobrze sprawdza się w omawianiu popularnych przypadków użycia, takich jak śledzenie aktywności w witrynie, metryki, agregacja dzienników, przetwarzanie strumieniowe, pozyskiwanie zdarzeń i dzienniki zatwierdzania. Jednym z opisywanych przypadków użycia jest przesyłanie wiadomości, które może powodować pewne zamieszanie. Rozpakujmy to trochę i dowiedzmy się, które scenariusze przesyłania wiadomości są najlepsze dla Kafki, na przykład:

Strumieniowanie od A do B bez skomplikowanego routingu, z maksymalną przepustowością (100k / s +), dostarczane co najmniej raz w kolejności podzielonej na partycje. Gdy aplikacja potrzebuje dostępu do historii transmisji, dostarczana co najmniej raz w kolejności podzielonej na partycje. Kafka to trwały magazyn wiadomości, a klienci mogą uzyskać „powtórkę” strumienia zdarzeń na żądanie, w przeciwieństwie do bardziej tradycyjnych brokerów wiadomości, w których po dostarczeniu wiadomość jest usuwana z kolejki. Przetwarzanie zdarzeń - pozyskiwanie zdarzeń RabbitMQ to rozwiązanie do przesyłania wiadomości ogólnego przeznaczenia, często stosowane w celu umożliwienia serwerom internetowym szybkiego reagowania na żądania zamiast zmuszania ich do wykonywania procedur obciążających zasoby, gdy użytkownik czeka na wynik. Jest także dobry do dystrybucji wiadomości do wielu odbiorców w celu konsumpcji lub do równoważenia obciążeń między pracownikami o dużym obciążeniu (20k + / s). Gdy Twoje wymagania wykraczają poza przepustowość, RabbitMQ ma wiele do zaoferowania: funkcje niezawodnego dostarczania, routingu, federacji, HA, bezpieczeństwa, narzędzia do zarządzania i inne funkcje. Przeanalizujmy najlepsze scenariusze dla RabbitMQ, takie jak:

Twoja aplikacja musi współpracować z dowolną kombinacją istniejących protokołów, takich jak AMQP 0-9-1, STOMP, MQTT, AMQP 1.0. Potrzebujesz dokładniejszej kontroli spójności / gwarancji dla poszczególnych wiadomości (kolejki niedostarczonych wiadomości itp.) Jednak ostatnio Kafka dodała lepszą obsługę transakcji. Twoja aplikacja potrzebuje różnorodności w punktach, żądaniach / odpowiedziach oraz publikowaniu / subskrybowaniu wiadomości Złożone routing do klientów, integracja wielu usług / aplikacji z nietrywialną logiką routingu RabbitMQ może również skutecznie rozwiązać kilka powyższych przypadków silnego użycia Kafki, ale z pomoc dodatkowego oprogramowania. RabbitMQ jest często używany z Apache Cassandra, gdy aplikacja potrzebuje dostępu do historii transmisji, lub z wtyczką LevelDB dla aplikacji, które wymagają „nieskończonej” kolejki, ale żadna z funkcji nie jest dostarczana z samym RabbitMQ.


0

Krótka odpowiedź to „potwierdzenia wiadomości”. RabbitMQ można skonfigurować tak, aby wymagał potwierdzenia wiadomości. Jeśli odbiornik ulegnie awarii, komunikat wraca do kolejki i inny odbiorca może spróbować ponownie. Chociaż możesz to zrobić w Kafce za pomocą własnego kodu, działa on z RabbitMQ od razu po wyjęciu z pudełka.

Z mojego doświadczenia wynika, że ​​jeśli masz aplikację, która ma wymagania do zapytania o strumień informacji, Kafka i KSql są najlepszym rozwiązaniem. Jeśli chcesz system kolejkowania, lepiej skorzystać z RabbitMQ.


0

Najczęściej głosowana odpowiedź obejmuje większość, ale chciałbym zwrócić uwagę na przypadek użycia w świetle. Czy kafka może zrobić to, co królik może zrobić, odpowiedź brzmi tak, ale czy królik może zrobić wszystko, co robi kafka, odpowiedź brzmi nie. Więc to, czego nie może zrobić Rabbit Mq, powoduje, że Kafka jest osobno, czyli rozproszone przetwarzanie wiadomości. Dzięki temu przeczytaj ponownie najczęściej głosowaną odpowiedź, która będzie miała więcej sensu. Aby to rozwinąć, weź przypadek użycia, w którym musisz utworzyć system przesyłania wiadomości, który ma bardzo wysoką przepustowość, na przykład „polubienia” na Facebooku i wybrałeś do tego królika mq. Utworzyłeś giełdę i kolejkę oraz konsumenta, w którym wszyscy wydawcy (w tym przypadku użytkownicy FB) mogą publikować wiadomości „polubienia”. Ponieważ twoja przepustowość jest wysoka, utworzysz wiele wątków w konsumentach, aby przetwarzać wiadomości równolegle, ale nadal jesteś ograniczony możliwościami sprzętowymi komputera, na którym działa konsument. Zakładając, że jeden konsument nie wystarczy do przetworzenia wszystkich wiadomości - co byś zrobił? Czy możesz dodać jeszcze jednego konsumenta do kolejki - nie, nie możesz tego zrobić. Czy możesz utworzyć nową kolejkę i powiązać tę kolejkę do wymiany, która publikuje wiadomość „polubienia”, odpowiedź nie jest żadna, ponieważ wiadomości będą przetwarzane dwukrotnie. To jest podstawowy problem, który rozwiązuje Kafka. Pozwala tworzyć rozproszone partycje (kolejka w króliczym mq) i rozproszonych konsumentów, którzy ze sobą rozmawiają. Dzięki temu wiadomości w temacie są przetwarzane przez konsumentów rozproszonych w różnych węzłach (komputerach). Brokerzy Kafka dbają o to, aby wiadomości były równoważone pod względem obciążenia na wszystkich partiach tego tematu. Grupa konsumentów upewnij się, że wszyscy konsumenci rozmawiają ze sobą, a wiadomość nie zostanie przetworzona dwukrotnie. Ale w prawdziwym życiu nie będziesz mieć do czynienia z tym problemem, chyba że Twój wkład będzie poważnie wysoki, ponieważ królik mq może również bardzo szybko przetwarzać dane nawet z jednym konsumentem.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.