Redis Vs RabbitMQ jako broker danych / system przesyłania wiadomości między Logstash a elastycznym wyszukiwaniem


90

Definiujemy architekturę do zbierania informacji z logów przez spedytorów Logstash, które są instalowane na różnych maszynach i indeksują dane centralnie na jednym serwerze Flexiblesearch i wykorzystują Kibana jako warstwę graficzną. Potrzebujemy niezawodnego systemu przesyłania wiadomości między nadawcami Logstash a elastycznym wyszukiwaniem, aby zapewnić dostawę. Jakie czynniki należy wziąć pod uwagę przy wyborze Redis zamiast RabbitMQ jako brokera danych / systemu przesyłania wiadomości pomiędzy dostawcami Logstash a elastycznym wyszukiwaniem lub odwrotnie?

Odpowiedzi:


94

Po ocenie zarówno Redis, jak i RabbitMQ wybrałem RabbitMQ jako naszego brokera z następujących powodów:

  1. RabbitMQ pozwala na korzystanie z wbudowanej warstwy bezpieczeństwa poprzez używanie certyfikatów SSL do szyfrowania danych, które wysyłasz do brokera, a to oznacza, że ​​nikt nie będzie podsłuchiwał Twoich danych i nie będzie miał dostępu do ważnych danych organizacyjnych.
  2. RabbitMQ to bardzo stabilny produkt, który może obsługiwać dużą liczbę zdarzeń na sekundę i wiele połączeń, nie będąc szyjką butelki.
  3. W naszej organizacji korzystaliśmy już z RabbitMQ i mieliśmy dobrą wewnętrzną wiedzę na temat korzystania z niego oraz przygotowaną już integrację z szefem kuchni.

Jeśli chodzi o skalowanie, RabbitMQ ma wbudowaną implementację klastra, której można użyć oprócz modułu równoważenia obciążenia w celu zaimplementowania nadmiarowego środowiska brokera.

Czy mój klaster RabbitMQ jest aktywny, czy aktywny pasywny?

A teraz do słabszego punktu korzystania z RabbitMQ:

  1. Większość spedytorów Logstash nie obsługuje RabbitMQ, ale z drugiej strony najlepszy, o nazwie Beaver, ma implementację, która bez problemu wyśle ​​dane do RabbitMQ.
  2. Implementacja, którą Beaver ma z RabbitMQ w swojej aktualnej wersji, jest trochę wolna pod względem wydajności (do moich celów) i nie była w stanie obsłużyć szybkości 3000 zdarzeń na sekundę z jednego serwera i od czasu do czasu usługa ulegała awarii.
  3. Obecnie pracuję nad poprawką, która rozwiąże problem z wydajnością RabbitMQ i sprawi, że spedytor Beaver będzie bardziej stabilny. Pierwszym rozwiązaniem jest dodanie większej liczby procesów, które mogą działać jednocześnie i dadzą spedytorowi większą moc. Drugim rozwiązaniem jest zmiana Beavera na wysyłanie danych do RabbitMQ asynchronicznie, co teoretycznie powinno być znacznie szybsze. Mam nadzieję, że zakończę wdrażanie obu rozwiązań do końca tego tygodnia.

Możesz śledzić problem tutaj: https://github.com/josegonzalez/python-beaver/issues/323

I sprawdź żądanie ściągnięcia tutaj: https://github.com/josegonzalez/python-beaver/pull/324

Jeśli masz więcej pytań, zostaw komentarz.


3
Czy Redis ma jakieś mocniejsze strony w porównaniu z RabbitMQ? Redis wydaje się łatwiejszy do skonfigurowania. A jeśli nie potrzebujesz dużej przepustowości, a bezpieczeństwo jest obsługiwane w inny sposób, RabbitMQ może nie być konieczny. Proszę popraw mnie jeżeli się mylę.
Ricardo MS,

Masz rację, ale aby mieć pewność, musisz porównać wyniki obu produktów
Tom Kregenbild.

4
„RabbitMQ to bardzo stabilny produkt, który może obsługiwać dużą liczbę zdarzeń na sekundę i wiele połączeń, nie będąc szyjką butelki”. - Jestem pewien, że to prawda, dotyczy to również Reddis. Więc NIE jest to przewaga rabbitmq nad Redditem
Martin Thoma

„RabbitMQ umożliwia korzystanie z wbudowanej warstwy zabezpieczeń przy użyciu protokołu SSL” - czy reddis nie pozwala również na szyfrowanie warstwy transportowej?
Martin Thoma,

2
2019 nadal redis nie ma wbudowanego protokołu TLS
jjxtra

55

Redis jest tworzony jako magazyn danych o kluczowej wartości, pomimo posiadania pewnych podstawowych funkcji brokera komunikatów.

RabbitMQ jest tworzony jako broker komunikatów. Naturalnie ma wiele funkcji brokera wiadomości.


1
Twoje oświadczenie na temat Redis nie jest bardziej dokładne po wprowadzeniu Stream w Redis 5. RabbitMQ jest zdecydowanie lepszym wyborem dla scenariuszy na dużą skalę. W przypadku scenariuszy o małej lub średniej skali (takich jak większość projektów na świecie), Redis jest niezawodną, ​​szybką i łatwą w konfiguracji alternatywą.
Reza

Dzięki za zaangażowanie, dobrze by było, gdyby ktoś opisał tutaj swoje doświadczenia z nowymi funkcjami Redisa.
Ferhat

44

Zrobiłem pewne badania na ten temat. Jeśli wydajność jest ważna, a wytrwałość nie, RabbitMQ jest idealnym wyborem. Redis to technologia opracowana w innym celu.

Poniżej znajduje się lista zalet korzystania z RabbitMQ zamiast Redis:

  • RabbitMQ używa zaawansowanego protokołu kolejkowania wiadomości (AMQP), który można skonfigurować do korzystania z protokołu SSL, dodatkowej warstwy zabezpieczeń.
  • RabbitMQ zajmuje około 75% czasu Redis akceptowania wiadomości.
  • RabbitMQ obsługuje priorytety dla komunikatów, które mogą być używane przez pracowników do korzystania w pierwszej kolejności z wiadomości o wysokim priorytecie.
  • Nie ma szans na utratę wiadomości, jeśli którykolwiek z pracowników ulegnie awarii po jej wykorzystaniu, co nie ma miejsca w przypadku Redis.
  • RabbitMQ ma dobry system routingu do kierowania wiadomości do różnych kolejek.

Kilka wad korzystania z RabbitMQ:

  • RabbitMQ może być trochę trudny w utrzymaniu, trudny do debugowania awarii.
  • Wahania nazwy węzła lub adresu IP węzła mogą powodować utratę danych, ale jeśli są dobrze zarządzane, trwałe komunikaty mogą rozwiązać problem.

3
Redis Sorted Setspozwala na priorytetowe interakcje podobne do kolejki. Redis można również łączyć w klastry / fragmentować, aby nawet wysyłać różne komunikaty do różnych kolejek na różnych serwerach. Nie jestem pewien co do SSL bezpośrednio dla Redis, ale patrzę na AWS Elasticache i ich Redis 3.2.6 pozwala na szyfrowanie w stanie spoczynku i podczas przesyłania. Uwaga: wcale nie mówię, że Redis jest lepszy w tym przypadku; tylko wskazanie, że mogą to nie być powody, aby wybrać RabbitMQ zamiast Redis.
dwanderson

1
Nie zapominaj również, że Redis jest jednowątkowy, więc jeśli masz wielu wydawców / konsumentów, może to stanowić problem.
Kedare

5

Zastanawiałem się nad tym samym. Wcześniejsze zalecenia ludzi z Logstash zalecały Redis zamiast RabbitMQ ( http://logstash.net/docs/1.1.1/tutorials/getting-started-centralized ), jednak ta sekcja uwag nie istnieje już w bieżącej dokumentacji, chociaż istnieją ogólne uwagi na temat korzystania z brokera do radzenia sobie ze skokami tutaj https://www.elastic.co/guide/en/logstash/current/deploying-and-scaling.html .

Chociaż całkiem szczęśliwie używam RabbitMQ, obecnie badam brokera Redis, ponieważ protokół AMQP jest prawdopodobnie przesadzony w moim przypadku użycia logowania.


2

Szybkie pytania do zadania:

  1. dlaczego potrzebujesz brokera? Jeśli używasz logstash lub logstash-forwarder do odczytywania plików z tych serwerów, oba spowolnią, jeśli potok zostanie przeciążony.
  2. czy masz jakieś doświadczenie w podawaniu królików lub redis? Jeśli wszystko jest równe, narzędzie, którego wiesz, jest lepszym narzędziem.

Jeśli chodzi o opinie, prowadziłem Redis jako broker i nienawidziłem tego. Oczywiście mógł to być mój brak doświadczenia z redisem (nie był to problem z samym produktem), ale było to najsłabsze ogniwo w rurociągu i zawsze zawodziło, gdy tego najbardziej potrzebowaliśmy.

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.