Redis Vs RabbitMQ en tant que courtier de données / système de messagerie entre Logstash et elasticsearch

90

Nous définissons une architecture pour collecter les informations de journal par les expéditeurs Logstash qui sont installés dans diverses machines et indexent les données dans un serveur elasticsearch de manière centralisée et utilisent 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 facteurs doivent être pris en compte lors de la sélection de Redis sur RabbitMQ en tant que courtier de données / système de messagerie entre les expéditeurs Logstash et elasticsearch ou vice versa?

Salindaw
la source

Réponses:

94

Après avoir évalué Redis et RabbitMQ, j'ai choisi RabbitMQ comme courtier pour les raisons suivantes:

  1. RabbitMQ vous permet d'utiliser une couche de sécurité intégrée en utilisant des certificats SSL pour crypter les données que vous envoyez au courtier et cela signifie que personne ne reniflera vos données et n'aura accès à vos données organisationnelles vitales.
  2. RabbitMQ est un produit très stable qui peut gérer de grandes quantités d'événements par seconde et de nombreuses connexions sans être le goulot de la bouteille.
  3. Dans notre organisation, nous utilisions déjà RabbitMQ et avions de bonnes connaissances internes sur son utilisation et une intégration déjà préparée avec le chef.

En ce qui concerne la mise à l'échelle, RabbitMQ dispose d'une implémentation de cluster intégrée que vous pouvez utiliser en plus d'un équilibreur de charge afin d'implémenter un environnement de courtier redondant.

Mon cluster RabbitMQ est-il actif actif ou actif passif?

Passons maintenant au point le plus faible de l'utilisation de RabbitMQ:

  1. la plupart des expéditeurs Logstash ne prennent pas en charge RabbitMQ mais d'un autre côté, le meilleur, nommé Beaver, a une implémentation qui enverra les données à RabbitMQ sans problème.
  2. L'implémentation que Beaver a avec RabbitMQ dans sa version actuelle est un peu lente sur les performances (pour mes besoins) et n'a pas été en mesure de gérer le taux de 3000 événements / s à partir d'un serveur et de temps en temps le service a planté.
  3. En ce moment, je travaille sur un correctif qui résoudra le problème de performance de RabbitMQ et rendra l'expéditeur Beaver plus stable. La première solution est d'ajouter plus de processus qui peuvent s'exécuter simultanément et donneront plus de puissance à l'expéditeur. La deuxième solution consiste à changer Beaver pour envoyer des données à RabbitMQ de manière asynchrone, ce qui devrait théoriquement être beaucoup plus rapide. J'espère que je terminerai la mise en œuvre des deux solutions d'ici la fin de cette semaine.

Vous pouvez suivre le problème ici: https://github.com/josegonzalez/python-beaver/issues/323

Et vérifiez la demande d'extraction ici: https://github.com/josegonzalez/python-beaver/pull/324

Si vous avez d'autres questions, n'hésitez pas à laisser un commentaire.

Tom Kregenbild
la source
3
Redis a-t-il des points plus forts par rapport à RabbitMQ? Redis semble plus facile à configurer. Et si vous n'avez pas besoin d'un débit énorme et que la sécurité est gérée par d'autres moyens, RabbitMQ peut ne pas être nécessaire. Corrigez-moi si j'ai tort, s'il-vous plait.
Ricardo MS le
Vous avez raison, mais pour être sûr, vous devrez comparer les performances entre les deux produits
Tom Kregenbild
4
"RabbitMQ est un produit très stable qui peut gérer de grandes quantités d'événements par seconde et de nombreuses connexions sans être le goulot de la bouteille." - Je suis à peu près sûr que c'est vrai aussi Reddis. Donc ce n'est PAS un avantage de rabbitmq sur Reddit
Martin Thoma
"RabbitMQ vous permet d'utiliser une couche de sécurité intégrée en utilisant SSL" - Reddis n'autorise-t-il pas également le cryptage de la couche de transport?
Martin Thoma
2
2019 Redis n'a toujours pas intégré TLS
jjxtra
55

Redis est créé en tant que magasin de données à valeur clé malgré certaines fonctionnalités de base de courtier de messages.

RabbitMQ est créé en tant que courtier de messages. Il a naturellement beaucoup de capacités de courtier de messages.

Ferhat
la source
1
Votre déclaration sur Redis n'est pas plus précise avec l'introduction de Stream dans Redis 5. RabbitMQ est certainement un meilleur choix pour les scénarios à grande échelle. Pour un scénario de petite à moyenne échelle (ce que sont la plupart des projets dans le monde), Redis est une alternative fiable, rapide et facile à configurer.
Reza
Merci pour l'engagement, ce serait bien si quelqu'un écrit ici son expérience sur les nouvelles fonctionnalités de Redis.
Ferhat
44

J'ai fait des recherches sur ce sujet. Si les performances sont importantes et que la persistance ne l'est pas, RabbitMQ est un choix parfait. Redis est une technologie développée avec une intention différente.

Voici une liste des avantages de l'utilisation de RabbitMQ sur Redis:

  • RabbitMQ utilise le protocole AMQP (Advanced Message Queuing Protocol) qui peut être configuré pour utiliser SSL, une couche de sécurité supplémentaire.
  • RabbitMQ prend environ 75% du temps que Redis prend pour accepter les messages.
  • RabbitMQ prend en charge les priorités pour les messages, qui peuvent être utilisées par les travailleurs pour consommer d'abord les messages de haute priorité.
  • Il n'y a aucune chance de perdre le message si un travailleur se bloque après avoir consommé le message, ce qui n'est pas le cas avec Redis.
  • RabbitMQ dispose d'un bon système de routage pour diriger les messages vers différentes files d'attente.

Quelques inconvénients pour l'utilisation de RabbitMQ:

  • RabbitMQ peut être un peu difficile à maintenir, difficile à déboguer des plantages.
  • Les fluctuations de nom de nœud ou d'adresse de nœud peuvent entraîner des pertes de données, mais si elles sont bien gérées, les messages durables peuvent résoudre le problème.
Arun Reddy
la source
3
Redis a Sorted Setsce qui permet des interactions de type file d'attente prioritaires. Redis peut également être mis en cluster / partitionné pour envoyer différents messages à différentes files d'attente sur différents serveurs même. Je ne suis pas sûr de SSL directement pour Redis, mais je regarde AWS Elasticache et leur Redis 3.2.6 permet le chiffrement au repos et en transit. Remarque: ne pas dire du tout que Redis est meilleur pour ce cas; soulignant simplement que ce n'est peut-être pas des raisons pour choisir RabbitMQ plutôt que Redis.
dwanderson le
1
N'oubliez pas non plus que Redis est monothread, donc si vous avez beaucoup d'éditeurs / consommateurs, cela peut être un problème.
Kedare
5

Je me suis demandé la même chose. Les recommandations antérieures des gens de Logstash recommandent Redis plutôt que RabbitMQ ( http://logstash.net/docs/1.1.1/tutorials/getting-started-centralized ), mais cette section des notes n'existe plus dans la documentation actuelle bien qu'il existe notes génériques sur l'utilisation d'un courtier pour traiter les pics ici https://www.elastic.co/guide/en/logstash/current/deploying-and-scaling.html .

Bien que j'utilise également RabbitMQ avec bonheur, j'explore actuellement un courtier Redis, car le protocole AMQP est probablement excessif pour mon cas d'utilisation de journalisation.

opennomad
la source
2

Questions rapides à poser:

  1. 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 encombré.
  2. avez-vous une expérience de l'administration de lapin ou de redis? Toutes choses étant égales par ailleurs, l'outil que vous savez utiliser est le meilleur outil.

Dans le domaine des opinions, j'ai dirigé Redis en tant que courtier et je l'ai détesté. 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 du pipeline et a toujours échoué lorsque nous en avions le plus besoin.

Alain Collins
la source