Échange de sujets vs échange direct dans RabbitMQ
Nous avons une application qui utilisera RabbitMQ et dispose de plusieurs files d'attente différentes pour passer des messages entre les niveaux.
Au départ, je prévoyais d'utiliser plusieurs échanges directs, avec un pour chaque type de message, mais il semble que le fait d'avoir un seul échange de sujet avec des files d'attente utilisant différentes liaisons de clé de routage permettra d'obtenir la même chose.
Avoir un seul échange semble également être un peu plus facile à maintenir, mais je me demandais s'il y avait un avantage (le cas échéant) à le faire d'une manière par rapport à l'autre?
Option 1, utilisant plusieurs échanges directs:
ExchangeA (type: direct)
-QueueA
ExchangeB (type: direct)
-QueueB
ExchangeC (type: direct)
-QueueC
Option 2, utilisant l'échange de sujet unique:
Exchange (type: topic)
-QueueA (receives messages from exchange with routing key of "TypeA")
-QueueB (receives messages from exchange with routing key of "TypeB")
-QueueC (receives messages from exchange with routing key of "TypeC")
En supposant que les deux modèles sont considérés comme étant mis en œuvre à l'aide d'un courtier en cours d'exécution, il y a peu de différence que je puisse voir.
L'option 2 semble plus courante dans le monde réel pour résoudre ce type de problème de routage (au moins dans mon expérience anecdotique) et c'est exactement le défi que les échanges de sujets existent pour résoudre.
La seule différence que vous pourriez rencontrer serait liée à la vitesse de routage. Je ne sais pas avec certitude si le routage Exchange (basé toujours sur une correspondance de chaîne exacte) est plus rapide dans RabbitMQ par rapport à la technique de clé de routage utilisée dans les échanges de sujets (qui peut inclure des caractères génériques comme # et *). Mon intuition serait que la discrimination Exchange serait plus rapide, mais vous pouvez expérimenter par vous-même pour le découvrir, ou essayer de contacter l'équipe RabbitMQ pour leur demander.
Enfin, si vous optez pour l'option 1, vous vous retrouverez avec beaucoup de files d'attente, vous aurez une prolifération proportionnelle d'échanges. Cela ressemble à un mal de tête de maintenance. Si vous n'avez qu'une poignée de files d'attente, ce ne sera pas trop un problème.
En effet, l'approche 2 est meilleure car elle vous donne la possibilité d'utiliser une seule file d'attente pour plusieurs clés de routage.
Sujet d'échange
QueueA-- binding key = India.Karnataka.*
Vous pouvez acheminer un message vers l'échange de sujets avec une clé de routage comme India.Karnataka.bangalore, India.Karnataka.Mysore.
Tous les messages ci-dessus sont envoyés à QueueA.
échange direct
Mais je n'ai pas compris pourquoi créez-vous plusieurs échanges directs dans l'approche 1. Vous pouvez avoir un échange direct unique et plusieurs files d'attente avec chaque liaison de file d'attente avec une clé unique.
QueueA-- binding key = Key1
QueueB-- binding Key = Key2
QueueC-- binding Key = Key3
Tous les messages key1 vont à QueueA.Key2 va à QueueB ... Vous pouvez toujours maintenir un échange direct unique.
Pour un seul petit nœud avec peu de charge, il y a peu de différence. La plupart des gens optent pour l'option deux pour les raisons ci-dessus.
Lors de la conception du système, vous devez vous demander comment cela pourrait se développer à l'avenir.
Comment va-t-elle évoluer?
En ai-je besoin pour évoluer? Est-ce que je veux ajouter un cluster à haute disponibilité à l'avenir? Mon itinéraire va-t-il changer ...
L'option 2 offre beaucoup plus de flexibilité dans la plupart des cas.
Il vous permet de faire des choses comme attacher un nouveau consommateur à Exchange avec sa propre file d'attente et capturer facilement tout sous-ensemble ou tout votre flux de messages. (ces files d'attente peuvent se trouver sur d'autres nœuds d'un cluster ou être mises en miroir sur n nœuds fournissant un basculement) Un cas d'utilisation typique consisterait à consigner tous les messages à l'aide d'une 4e file d'attente.
Si votre goulot d'étranglement est du côté du traitement, vous pouvez également subdiviser davantage vos rubriques de message et effectuer une certaine hiérarchisation sans avoir à modifier vos éditeurs. Exemple: ToppicA.urgent, traité par un consommateur dédié, TopicA.log finalement traité.
La réponse courte est d'aller avec l'option 2, sauf si vous avez des exigences de performances très spécifiques.Si, par exemple, vous devez traiter un taux soutenu de plus de 50 000 msg/s, vous voudrez peut-être penser à l'option 1 sur des nœuds dédiés, mais pour des flux normaux l'option 2 sera plus facile à mettre à l'échelle et à entretenir.
L'échange direct prend également en charge plusieurs itinéraires ( https://www.rabbitmq.com/tutorials/amqp-concepts.html#exchange-direct ), alors pourquoi n'utilisez-vous pas quelque chose comme ceci:
ExchangeA (type: direct)
-QueueA
-RoutingA
ExchangeB (type: direct)
-QueueB
-RoutingB
ExchangeC (type: direct)
-QueueC
-RoutingC