Pourquoi avons-nous besoin de courtiers de messages comme RabbitMQ sur une base de données telle que PostgreSQL?
Je suis nouveau pour les courtiers de messages comme RabbitMQ que nous pouvons utiliser pour créer des tâches/des files de messages pour un système de planification comme Celery .
Maintenant, voici la question:
Je peux créer une table dans PostgreSQL qui peut être ajoutée à de nouvelles tâches et consommée par le programme consommateur tel que Celery.
Pourquoi diable voudrais-je installer une toute nouvelle technologie pour ce RabbitMQ?
Maintenant, je pense que la mise à l’échelle ne peut pas être la solution car notre base de données comme PostgreSQL peut fonctionner dans un environnement distribué.
J'ai cherché sur Google pour quels problèmes la base de données pose pour le problème particulier, et j'ai trouvé:
- polling maintient la base de données occupée et peu performante
- verrouillage de la table -> encore une fois peu performant
- des millions de lignes de tâches -> encore une fois, l'interrogation est peu performante
Maintenant, comment RabbitMQ ou tout autre courtier de messages comme celui-ci résout-il ces problèmes?
En outre, j'ai découvert que le protocole AMQP est ce qu'il suit. Qu'est-ce qui est bien dans tout ça?
Peut-on aussi utiliser Redis comme courtier de messages? Je trouve cela plus analogue à Memcached qu'à RabbitMQ.
S'il vous plaît nous éclairer à ce sujet!
Les files d'attente de Rabbit résident en mémoire et seront donc beaucoup plus rapides que leur implémentation dans une base de données. Une (bonne) file d'attente de messages dédiée devrait également fournir des fonctionnalités essentielles telles que la régulation/contrôle de flux, et la possibilité de choisir différents algorithmes de routage, pour en nommer deux (le lapin les fournit, etc.). En fonction de la taille de votre projet, vous pouvez également souhaiter que le composant de transmission de message soit séparé de votre base de données. Ainsi, si l'un des composants subit une charge importante, il ne doit pas gêner le fonctionnement de l'autre.
En ce qui concerne les problèmes que vous avez mentionnés:
interrogation en gardant la base de données dynamique et peu performante : en utilisant Rabbitmq, les producteurs peuvent Push mettre à jour le consommateur, ce qui est beaucoup plus performant. que le scrutin. Les données sont simplement envoyées au consommateur quand il le faut, éliminant ainsi le besoin de contrôles inutiles.
verrouillage de la table -> encore une fois performance faible: Il n'y a pas de table à verrouiller: P
des millions de lignes de tâches -> encore une fois, l'interrogation est peu performante: Comme mentionné ci-dessus, Rabbitmq fonctionnera plus rapidement car il réside en 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 RAM. Des options de clustering sont également disponibles.
En ce qui concerne l'AMQP, je dirais qu'une fonctionnalité vraiment intéressante est "l'échange" et sa capacité à acheminer 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 )
Enfin, en ce qui concerne Redis, oui, il peut être utilisé en tant que courtier de messages et peut bien se comporter. Cependant, Rabbitmq dispose de davantage de fonctionnalités de mise en file d'attente de messages que de redis, Rabbitmq ayant été conçu dès le départ pour devenir une file de messages dédiée complète au niveau de l'entreprise. Redis, d’autre part, a été créé principalement pour être un magasin clé-valeur en mémoire (bien qu’il fasse beaucoup plus que cela à présent; 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 grandes.
Voici un exemple d'utilisation de redis dans une implémentation de discussion à longue interrogation: http://eflorenzano.com/blog/2011/02/16/technology-behind-convore/
PostgreSQL 9.5
PostgreSQL 9.5 incorpore SELECT ... FOR UPDATE ... SKIP LOCKED. Cela rend la mise en œuvre de systèmes de file d'attente en fonctionnement beaucoup plus simple et plus simple. Vous n’avez peut-être plus besoin d’un système de file d’attente externe, car il est désormais simple de récupérer des "lignes" qu’aucune autre session n’a verrouillées et de les conserver jusqu’à ce que vous confirmiez que le travail est terminé. Il fonctionne même avec des transactions en deux phases lorsqu'une coordination externe est requise.
Les systèmes de file d'attente externes restent utiles, offrant des fonctionnalités prédéfinies, des performances éprouvées, une intégration avec d'autres systèmes, des options pour la mise à l'échelle horizontale et la fédération, etc. Néanmoins, dans les cas simples, vous n'en avez plus vraiment besoin.
Versions plus anciennes
Vous n'avez pas besoin de tels outils, mais en utiliser un peut vous rendre la vie plus facile. Faire la mise en file d'attente dans la base de données semble facile, mais vous découvrirez en pratique que la mise en file d'attente simultanée fiable et hautement performante est très difficile dans une base de données relationnelle .
C'est pourquoi des outils tels que PGQ existent.
Vous pouvez vous débarrasser des polling dans PostgreSQL en utilisant LISTEN et NOTIFY, mais cela ne résoudra pas le problème de la distribution fiable des entrées en haut de la file d'attente à un seul consommateur tout en préservant fortement fonctionnement simultané et non blocage d'insertions. Toutes les solutions simples et évidentes qui, selon vous, résoudront ce problème ne le sont pas dans le monde réel et ont tendance à dégénérer en versions moins efficaces de l'extraction de la file d'attente pour un seul travailleur.
Si vous n'avez pas besoin d'extraits de files d'attente multi-ouvriers hautement concurrents, utiliser une table de file d'attente unique dans PostgreSQL est tout à fait raisonnable.