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

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?

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.

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.

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.

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.

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.