Pourquoi utiliser AMQP / ZeroMQ / RabbitMQ

Question

par opposition à l'écriture de votre propre bibliothèque.

Nous travaillons sur un projet qui sera un pool de serveurs à division automatique. Si une section devient trop lourde, le responsable le divise et la place sur une autre machine en tant que processus distinct. Cela alerterait également tous les clients connectés concernés par la connexion au nouveau serveur.

Je suis intéressé par l'utilisation de ZeroMQ pour la communication inter-serveur et inter-processus. Mon partenaire préférerait rouler le sien. Je compte sur la communauté pour répondre à cette question.

Je suis moi-même un programmeur plutôt novice et je viens d’apprendre à propos des files de messagerie. Comme je l'ai lu sur Google, il semble que tout le monde utilise des files d'attente de messagerie pour toutes sortes de choses, mais pourquoi? Qu'est-ce qui les rend meilleurs que d'écrire votre propre bibliothèque? Pourquoi sont-ils si courants et pourquoi y en a-t-il autant?

Answer 1

  

Qu'est-ce qui les rend meilleurs que d'écrire votre propre bibliothèque?

Lors du déploiement de la première version de votre application, probablement rien: vos besoins sont bien définis et vous développerez un système de messagerie adapté à vos besoins: petite liste de fonctionnalités, petit code source, etc.

Ces outils sont très utiles après la première version, lorsque vous devez réellement étendre votre application et y ajouter des fonctionnalités. Laissez-moi vous donner quelques cas d'utilisation:

• votre application devra parler à une machine big endian (sparc / powerpc) depuis une petite machine endian (x86, intel / amd). Votre système de messagerie avait une hypothèse d’ordre Endian: allez le réparer
• vous avez conçu votre application pour qu'il ne s'agisse pas d'un protocole / système de messagerie binaire, mais maintenant, elle est très lente car vous passez l'essentiel de votre temps à l'analyser (le nombre de messages a augmenté et l'analyse est devenue un goulot d'étranglement): adaptez-la pour qu'elle puisse transport binaire / codage fixe

• au début, vous aviez 3 machines dans un réseau local, pas de retards notables, tout se rend à chaque machine. votre client / patron / pointy-haired-devil-boss se présente et vous indique que vous allez installer l'application sur le réseau étendu que vous ne gérez pas - et que vous commencez à avoir des échecs de connexion, une latence incorrecte, etc. vous devez enregistrer le message et recommencer l'envoi plus tard: retournez dans le code et branchez ce matériel (et profitez-en)

• Les messages envoyés doivent avoir une réponse, mais pas la totalité: vous envoyez des paramètres et vous attendez à une feuille de calcul au lieu d'envoyer et accuser réception, retournez au code et branchez ces données (et profitez-en). .)

• certains messages sont critiques et leur réception / envoi nécessite une sauvegarde / persistance / appropriée. Pourquoi demandes-tu ? fins d'audit

Et de nombreux autres cas d'utilisation que j'ai oubliés ...

Vous pouvez le mettre en œuvre vous-même, mais ne perdez pas de temps à le faire: vous le remplacerez probablement plus tard de toute façon.

Answer 2

Cela ressemble beaucoup à demander: pourquoi utiliser une base de données quand vous pouvez écrire la vôtre?

La réponse est que l’utilisation d’un outil existant depuis un certain temps et bien compris dans de nombreux cas d’utilisation, porte ses fruits avec le temps et l’évolution de vos besoins. Cela est particulièrement vrai si plusieurs développeurs sont impliqués dans un projet. Voulez-vous devenir un membre du personnel de soutien pour un système de file d'attente si vous passez à un nouveau projet? L'utilisation d'un outil empêche que cela se produise. Cela devient le problème de quelqu'un d'autre.

Exemple: persistance. Écrire un outil pour stocker un message sur le disque est facile. Écrire une persistance qui se redimensionne et fonctionne correctement et de manière stable, dans de nombreux cas d'utilisation différents, et qui est gérable, et peu coûteux à gérer, est difficile. Si vous voulez voir quelqu'un se plaindre de la difficulté de la tâche, regardez ceci: http://www.lshift.net/blog/2009/12/07/rabbitmq-at-the-skills-matter-functional-programming-exchange

Quoi qu'il en soit, j'espère que cela aide. Par tous les moyens écrivez votre propre outil. Beaucoup de gens l'ont fait. Tout ce qui résout votre problème est bon.

Answer 3

J'envisage d'utiliser ZeroMQ moi-même - c'est pourquoi je suis tombé sur cette question.

Supposons pour l'instant que vous avez la possibilité de mettre en œuvre un système de mise en file d'attente des messages qui répond à toutes vos exigences. Pourquoi voudriez-vous adopter ZeroMQ (ou une autre bibliothèque tierce) plutôt que de rouler vous-même? Simple - coût.

Supposons un instant que ZeroMQ réponde déjà à toutes vos exigences. Tout ce qui reste à faire est de l'intégrer à votre construction, de lire un peu de doco, puis de commencer à l'utiliser. Cela demande beaucoup moins d'effort que de rouler soi-même. De plus, le fardeau de la maintenance a été transféré à une autre société. Depuis que ZeroMQ est gratuit, c'est comme si vous veniez de développer votre équipe de développement pour inclure (une partie de) l'équipe ZeroMQ.

Si vous dirigiez une entreprise de développement de logiciels, alors je pense que vous feriez bien de comparer le coût / risque de l'utilisation de bibliothèques tierces à celle de vos propres bibliothèques. Dans ce cas, l'utilisation de ZeroMQ serait gagnante sans problème.

Peut-être que vous (ou plutôt votre partenaire) souffrez, comme tant de développeurs, du " Pas Inventé ici " syndrome? Si c'est le cas, ajustez votre attitude et réévaluez l'utilisation de ZeroMQ. Personnellement, je préfère de loin les avantages de l’attitude Fièrement trouvé ailleurs. J'espère que je peux être fier de trouver ZeroMQ ... le temps nous le dira.

EDIT: Je suis tombé sur ce vidéo des développeurs de ZeroMQ qui explique pourquoi l'utilisation de ZeroMQ.

Answer 4

  

Qu'est-ce qui les rend meilleurs que d'écrire votre propre bibliothèque?

Les systèmes de mise en file d'attente de messages sont transactionnels, ce qui est conceptuellement facile à utiliser en tant que client, mais difficile à mettre en œuvre en tant qu'implémenteur, notamment en ce qui concerne les files d'attente persistantes. Vous pouvez penser que vous pouvez vous en sortir en écrivant une bibliothèque de messagerie rapide, mais sans transactions ni persistance, vous ne bénéficieriez pas pleinement des avantages d'un système de messagerie.

La persistance dans ce contexte signifie que le middleware de messagerie conserve les messages non gérés dans un stockage permanent (sur disque) en cas de panne du serveur. après un redémarrage, les messages peuvent être traités et aucune retransmission n'est nécessaire (l'expéditeur ne sait même pas qu'il y a eu un problème). Transactionnel signifie que vous pouvez lire des messages de différentes files d'attente et écrire des messages dans différentes files d'attente de manière transactionnelle, ce qui signifie que toutes les lectures et les écritures réussissent ou que (si un ou plusieurs échouent), rien ne réussit. Ce n’est pas très différent de la transactionnalité connue grâce à l’interface avec les bases de données et présente les mêmes avantages (cela simplifie le traitement des erreurs; sans transaction, vous devez vous assurer que chaque lecture / écriture réussit, et si un ou plusieurs échouent, vous devez annuler les modifications qui ont abouti).

Answer 5

Avant d'écrire votre propre bibliothèque, lisez le Guide 0MQ ici: http://zguide.zeromq.org/ page: tous

Il est fort probable que vous choisissiez d'installer RabbitMQ ou que vous créiez votre bibliothèque au-dessus de ZeroMQ car ils ont déjà effectué toutes les tâches difficiles.

Answer 6

Si vous avez un peu de temps, essayez-le et déployez votre propre implémentation! Les leçons tirées de cet exercice vous convaincront de l’utilité d’utiliser une bibliothèque déjà testée.