Redis Vs RabbitMQ en tant que courtier de données/système de messagerie entre Logstash et elasticsearch
nous sommes en train de définir une architecture pour collecter des informations de journalisation par les expéditeurs Logstash qui sont installés dans diverses machines et indexer les données dans un serveur elasticsearch central et utiliser Kibana comme couche graphique. Nous avons besoin d'un système de messagerie fiable entre les expéditeurs Logstash et elasticsearch pour garantir la livraison. Quels sont les facteurs à prendre en considération lors de la sélection de Redis au-dessus de RabbitMQ en tant que système de messagerie/courtier de données entre les expéditeurs Logstash et elasticsearch ou inversement?
5 réponses
après avoir évalué Redis et RabbitMQ, j'ai choisi RabbitMQ comme courtier pour les raisons suivantes:
- RabbitMQ vous permet d'utiliser une couche de sécurité intégrée en utilisant des certificats SSL pour chiffrer les données que vous envoyez au courtier et cela signifie que personne ne reniflera vos données et avoir accès à vos données organisationnelles vitales.
- RabbitMQ est un produit très stable qui peut traiter de grandes quantités d'événements par seconde et de nombreuses connexions sans le col de la bouteille.
- dans notre organisation, nous avons déjà utilisé RabbitMQ et nous avions une bonne connaissance interne de son utilisation et une intégration déjà préparée avec chef.
en ce qui concerne la mise à l'échelle, RabbitMQ dispose d'une implémentation cluster intégrée que vous pouvez utiliser en plus d'un équilibreur de charge afin de mettre en œuvre un environnement broker redondant.
Est mon RabbitMQ cluster Actif Actif ou passif actif?
maintenant au point le plus faible D'utiliser RabbitMQ:
- la plupart des expéditeurs de Logstash n'appuient pas RabbitMQ, mais d'un autre côté, le meilleur, nommé Beaver, a une mise en œuvre qui permettra d'envoyer des données à RabbitMQ sans problème.
- la mise en œuvre que Beaver a avec RabbitMQ dans sa version actuelle est un peu lente sur la performance (pour mes besoins) et n'a pas été en mesure de gérer le taux de 3000 événements / sec à partir d'un serveur et de temps en temps le service s'est écrasé.
- en ce moment je travaille sur un correctif qui résoudra le problème de performance pour RabbitMQ et rendra L'expéditeur de castor plus stable. La première solution consiste à ajouter plus de processus pouvant fonctionner simultanément et donnera plus de pouvoir au chargeur. La deuxième solution consiste à remplacer Beaver pour envoyer des données à RabbitMQ de façon asynchrone, ce qui théoriquement devrait être beaucoup plus rapide. J'espère que je vais finir mettre en œuvre les deux solutions d'ici la fin de la semaine.
, Vous pouvez suivre la question ici: https://github.com/josegonzalez/python-beaver/issues/323
et vérifier la demande de traction ici: https://github.com/josegonzalez/python-beaver/pull/324
si vous avez d'autres questions, n'hésitez pas à laisser un commentaire.
Redis est créé comme un stockage de données de valeur clé malgré avoir certaines capacités de base courtier de messages.
RabbitMQ est créé comme un courtier de messages. Il a beaucoup de capacités de courtier de message naturellement.
j'ai fait quelques recherches sur ce sujet. Si la performance est importante et la persistance pas, RabbitMQ est un choix parfait. Redis est une technologie développée avec une intention différente.
voici ma liste d'avantages pour utiliser RabbitMQ au lieu de Redis:
- RabbitMQ utilise le protocole AMQP qui peut être configuré pour utiliser SSL, couche supplémentaire de sécurité.
- RabbitMQ prend environ 75% du temps que prend Redis pour accepter les messages.
- RabbitMQ soutient les priorités pour les messages, qui peuvent être utilisés par les travailleurs pour consommer des messages de haute priorité en premier.
- il n'y a aucune chance de perdre le message si un travailleur tombe en panne après avoir consommé le message, ce qui n'est pas le cas avec Redis.
- RabbitMQ a un bon système de routage pour diriger les messages vers les différentes files d'attente.
quelques inconvénients pour utiliser RabbitMQ:
- RabbitMQ pourrait être un peu difficile à maintenir, difficile de déboguer les accidents.
- les fluctuations de nom de noeud ou d'ip de noeud peuvent causer des pertes de données, mais si elles sont bien gérées, les messages durables peuvent résoudre le problème.
je me demande la même chose. Recommandations antérieures des gens de Logstash recommandent Redis sur RabbitMQ ( http://logstash.net/docs/1.1.1/tutorials/getting-started-centralized ), cependant cette section des notes n'existe plus dans la documentation actuelle bien qu'il y ait des notes génériques sur l'utilisation d'un courtier pour traiter avec les transitoires ici https://www.elastic.co/guide/en/logstash/current/deploying-and-scaling.html .
bien que J'utilise aussi RabbitMQ avec beaucoup de plaisir, je suis en train d'explorer un courtier Redis, puisque le protocole AMQP est probablement excessif pour mon cas d'utilisation de l'exploitation forestière.
Quick questions à se poser:
- pourquoi avez-vous besoin d'un courtier? Si vous utilisez logstash ou logstash-forwarder pour lire les fichiers de ces serveurs, ils ralentiront tous les deux si le pipeline est congestionné.
- avez-vous déjà administré du lapin ou du redis? Toutes choses étant égales par ailleurs, l'outil que vous savez utiliser est le meilleur.
dans le domaine des opinions, j'ai couru redis comme un courtier, et il détestait. Bien sûr, cela aurait pu être mon inexpérience avec redis (pas un problème avec le produit lui-même), mais c'était le maillon le plus faible dans le pipeline et toujours échoué quand nous en avions le plus besoin.