Po ocenie Redis i RabbitMQ wybrałem RabbitMQ na naszego brokera z następujących powodów:
- RabbitMQ umożliwia korzystanie z wbudowanej warstwy bezpieczeństwa za pomocą certyfikatów SSL do szyfrowania danych, które wysyłasz do brokera, a to oznacza, że nikt nie będzie sniffował Twoich danych i nie będzie miał dostępu do ważnych danych organizacyjnych.
- RabbitMQ to bardzo stabilny produkt, który może obsłużyć dużą liczbę zdarzeń na sekundę i wiele połączeń, nie będąc wąskim gardłem.
- W naszej organizacji korzystaliśmy już z RabbitMQ i mieliśmy dobrą wewnętrzną wiedzę na temat jego używania 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 systemu równoważenia obciążenia w celu zaimplementowania redundantnego środowiska brokera.
Czy mój klaster RabbitMQ jest aktywny, czy aktywny pasywny?
Przejdźmy teraz do słabszego punktu korzystania z RabbitMQ:
- większość nadawcó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.
- Implementacja, którą Beaver ma z RabbitMQ w jego obecnej wersji, jest trochę powolna (dla moich celów) i nie była w stanie obsłużyć szybkości 3000 zdarzeń/s z jednego serwera i od czasu do czasu usługa się zawieszała.
- W tej chwili pracuję nad poprawką, która rozwiąże problem z wydajnością RabbitMQ i sprawi, że Beaver shipper będzie bardziej stabilny. Pierwszym rozwiązaniem jest dodanie większej liczby procesów, które mogą działać jednocześnie i dadzą nadawcy 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 do końca tego tygodnia zakończę wdrażanie obu rozwiązań.
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ń, możesz zostawić komentarz.
