Les files d'attente de Rabbit résident en mémoire et seront donc beaucoup plus rapides que de les implémenter dans une base de données. Une (bonne) file d'attente de messages dédiée devrait également fournir des fonctionnalités essentielles liées à la file d'attente, telles que la limitation/le contrôle de flux, et la possibilité de choisir différents algorithmes de routage, pour n'en nommer que quelques-uns (lapin les fournit et plus encore). En fonction de la taille de votre projet, vous pouvez également souhaiter que le composant de transmission de messages soit séparé de votre base de données, de sorte que si un composant subit une charge importante, il n'entrave pas le fonctionnement de l'autre.
En ce qui concerne les problèmes que vous avez mentionnés :
-
interrogation gardant la base de données occupée et peu performante :En utilisant Rabbitmq, les producteurs peuvent pousser mises à jour aux consommateurs, ce qui est beaucoup plus performant que l'interrogation. Les données sont simplement envoyées au consommateur lorsqu'elles en ont besoin, éliminant ainsi le besoin de vérifications inutiles.
-
verrouillage de la table -> encore une fois peu performant : Il n'y a pas de table à verrouiller :P
-
des millions de lignes de tâche > encore une fois, l'interrogation est peu performante : Comme mentionné ci-dessus, Rabbitmq fonctionnera plus rapidement car il réside dans la RAM et fournit un contrôle de flux. Si nécessaire, il peut également utiliser le disque pour stocker temporairement des messages s'il manque de RAM. Après la version 2.0, Rabbit a considérablement amélioré son utilisation de la RAM. Des options de regroupement sont également disponibles.
En ce qui concerne AMQP, je dirais qu'une fonctionnalité vraiment intéressante est "l'échange", et la possibilité pour lui d'être acheminé vers d'autres échanges. Cela vous donne plus de flexibilité et vous permet de créer un large éventail de typologies de routage élaborées qui peuvent s'avérer très utiles lors de la mise à l'échelle. Pour un bon exemple, voir :
(source :springsource.com)
et :http://blog.springsource.org/2011/04/01/routing-topologies-for-performance-and-scalability-with-rabbitmq/
Enfin, en ce qui concerne Redis, oui, il peut être utilisé comme courtier de messages et peut bien fonctionner. Cependant, Rabbitmq a plus de fonctionnalités de mise en file d'attente de messages que Redis, car rabbitmq a été conçu à partir de zéro pour être une file d'attente de messages dédiée complète au niveau de l'entreprise. Redis, d'autre part, a été principalement créé pour être un magasin de valeurs clés en mémoire (bien qu'il fasse bien plus que cela maintenant ; il est même appelé un couteau suisse). Pourtant, j'ai lu/entendu de nombreuses personnes obtenir de bons résultats avec Redis pour des projets de petite taille, mais je n'en ai pas beaucoup entendu parler dans des applications plus importantes.
Voici un exemple d'utilisation de Redis dans une implémentation de chat à interrogation longue :http://eflorenzano.com/blog/2011/02/16/technology-behind-convore/
