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

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?

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.

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.

5 Główne różnice między Kafką a RabbitMQ, klientem, który ich używa:

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 ”

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.

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).

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

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.

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.

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

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.

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.

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.

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.

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.

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.

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.