Redis
 sql >> Base de données >  >> NoSQL >> Redis

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

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 d'étranglement.
  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 des 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/sec 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 performances de RabbitMQ et rendra l'expéditeur Beaver plus stable. La première solution consiste à ajouter plus de processus qui peuvent s'exécuter simultanément et donneront plus de pouvoir à 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 j'aurai terminé 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.