Confusion de messagerie: Pub / Sub vs Multicast vs Fan Out
J'ai évalué les technologies de messagerie pour mon entreprise, mais je suis devenu très confus par les différences conceptuelles entre quelques termes:
Pub/Sub vs Multicast vs Fan Out Je travaille avec les définitions suivantes:
- Pub/Sub a des éditeurs livrant une copie séparée de chaque message à chaque abonné, ce qui signifie qu'il existe une possibilité de garantir la livraison
- Fan Out a une seule file d'attente poussant vers tous les clients en écoute.
- Multicast ne fait que spammer des données et si quelqu'un écoute, c'est bien, sinon, cela n'a pas d'importance. Aucune possibilité de garantir qu'un client reçoit définitivement un message.
Ces définitions sont-elles exactes? Ou Pub/Sub est-il le modèle et les moyens de multidiffusion, direct, fanout, etc. pour obtenir le modèle?
J'essaie d'intégrer les définitions RabbitMQ prêtes à l'emploi dans notre architecture, mais je tourne en rond pour le moment en essayant d'écrire les spécifications de notre application.
S'il vous plaît quelqu'un pourrait-il me dire si j'ai raison?
Je suis confus par votre choix de trois termes à comparer. Dans RabbitMQ, Fanout et Direct sont des types d'échange. Pub-Sub est un modèle de messagerie générique mais pas un type d'échange. Et vous n'avez même pas mentionné le 3ème et le plus important type d'échange, à savoir Topic. En fait, vous pouvez implémenter le comportement Fanout sur un échange de sujet simplement en déclarant plusieurs files d'attente avec la même clé de liaison. Et vous pouvez définir le comportement Direct sur un échange de sujet en déclarant une file d'attente avec * comme clé de liaison générique.
Pub-Sub est généralement compris comme un modèle dans lequel une application publie des messages qui sont consommés par plusieurs abonnés.
Avec RabbitMQ/AMQP, il est important de se rappeler que les messages sont toujours publiés sur les échanges. Échange ensuite l'itinéraire vers les files d'attente. Et les files d'attente remettent des messages aux abonnés. Le comportement de l'échange est important. Dans les échanges de sujets, la clé de routage de l'éditeur est mise en correspondance avec la clé de liaison de l'abonné afin de prendre la décision de routage. Les clés de liaison peuvent avoir des modèles génériques qui influencent davantage la décision de routage. Un routage plus compliqué peut être fait en fonction du contenu des en-têtes de message en utilisant un type d'échange d'en-têtes
RabbitMQ ne garantit pas la livraison des messages mais vous pouvez obtenir une livraison garantie en choisissant les bonnes options (mode de livraison = 2 pour les msgs persistants) et en déclarant les échanges et les files d'attente avant d'exécuter votre application afin que les messages ne soient pas supprimés.
Vos définitions sont à peu près correctes. Notez que la livraison garantie n'est pas limitée au pub/sub uniquement, et elle peut également être effectuée avec fanout. Et oui, pub/sub est une description très basique qui peut être réalisée avec des méthodes spécifiques comme fanout, direct et ainsi de suite.
Il existe d'autres modèles de messagerie que vous pourriez trouver utiles. Jetez un œil à Enterprise Integration Patterns pour plus de détails.
D'un point de vue d'échange électronique, le terme "multidiffusion" signifie "le message est placé une fois sur le câble" et toutes les applications clientes qui écoutent peuvent lire le message sur le "câble". Toute solution qui crée N copies du message pour les N clients n'est pas multidiffusion. En plus d'examiner le code source, on peut également utiliser un "renifleur" pour déterminer combien de copies du message sont envoyées sur le câble à partir du système de messagerie. Et oui, les messages de multidiffusion sont une forme du message du protocole UDP. Voir: http://en.wikipedia.org/wiki/Multicast pour une description générale. Il y a une dizaine d'années, nous avons utilisé le système de messagerie de TIBCO qui supportait la multidiffusion. Voir: https://docs.tibco.com/pub/ems_openvms_c_client/8.0.0-june-2013/docs/html/tib_ems_users_guide/wwhelp/wwhimpl/common/html/wwhelp.htm#context=tib_ems_users_guide&file= EMS.5.091.htm