RabbitMQ

Il y a deux ans nous avions parlé de JMS [1], et des principes et enjeux liés aux échanges de messages entre systèmes logiciels. Aujourd’hui je profite d'être sur un sujet très proche de JMS  pour écrire un petit article ce coup ci sur RabbitMQ [2].

Un message Broker

Qu’est ce que RabbitMQ? Il s’agit d’un message broker [4] qui à l'instar de JMS permet la réception et le dispatch de message au sein d’un système d’information.

De façon logique, on va donc retrouver comme dans JMS une logique de files auxquelles les applications vont devoir s’abonner. La différence dans RabbitMQ est que la gestion des messages n’est pas limitée autour de l’utilisation de files ou de topic mais autour de files configurable [5] selon différentes configurations auxquelles vont être associées des clefs de routages permettant la gestion de la diffusion des messages.

Modele flow

Dans le détails, le modèle flow de RabbitMQ est la définition d’un acteur, le producteur de message qui poussera des messages dans un exchange de l’agent RabbitMQ qui selon les règles de routage alimente une ou plusieurs queues qui elles seront lu par un serveur qui consume les messages.

Comportement par default

Jusque la c’est simple. Un message entre il est routé et op il ressort! C’est la première configuration en fait. Celle que l’on pourrait appeler par défaut et ça tombe bien c’est celle qui est appliqué sur l’exchange par défaut “(AMQP Default)” qui est bindé (où associée) à tous les queues existantes du serveur le routage se réalisant sur la base des routingKey portant le nom des queues cible.

Docker

L'idéal est évidemment de tester ca pour cela on va se charger un conteneur docker pour jouer un peu. Je ne reviens pas sur docker ni docker compose [3], on en a déjà parlé [8].

Pour jouer chargez et lancez le script docker suivant et on est parti!

1 2 3 4 5 6 7 8 9 10 11

version: "3" services: rabbitmq: container_name: rabbitmq image: bitnami/rabbitmq:latest environment: RABBITMQ_USERNAME: user RABBITMQ_PASSWORD: password ports: - "15672:15672"

On se connecte en http://localhost:15672 et on va sur l’onglet Queues. On y ajoute les queueA, queueB et queueC et je vous laisse aller sur l’exchange “(AMQP Default)” pour faire les tests qui vont bien en injectant avec l’aide de l’interface les messages qui vont bien (sans oublier la routingKey portant le nom de la queue qui va bien)

Bien maintenant que l’on à vu les grandes lignes voyons les autres types de config. Le contexte de test étant déjà initialisé, je vous laisserai vous amuser avec au fur et à mesure…

Fanout

La configuration suivante pour un exchange est le mode Fanout c’est à dire que tous les messages seront pousser dans toutes les queues associés sans prise en compte de la routingKey. Pour tester cette conf, vous pouvez utiliser l’exchange “amq.fanout” fourni par la configuration initiale de RabbitMQ.

Direct

Nous venons de passer en revue les deux conf les plus basique et à priori à ne pas utiliser…. car outre le fait qu’elles aient peu d'intérêt, elle n’offre pas vraiment une gestion propre du routage.

Maintenant par contre on va s'intéresser aux exchanges de type Direct, Topic et Header.

Les premiers de type Direct vont permettre un routage exacte des messages sur la base de la routingKey devant être égale à la règle de binding, un peu comme dans la règle de routage par défaut où la règle est le nom de la queue cible. Ici avec ce mécanisme, il y a séparation entre règle de routage et nommage.

À noter que rien n'empêche deux binding différent de posséder la même règle permettant de broadcaster les messages sur deux queues différentes.

Topic

Les exchanges de type Topic vont fournir plus de souplesse car dans le principe il s’agit de la même chose que les Direct sauf qu’ici il ne s’agit plus d'être conforme à une égalité mais à une expression régulière simplifié utilisant des mots cascader par des “.” pouvant etre substitué unitairement par un “*” ou substituée en groupe par un #. [6]

Enfin le type header [7], il faut l’avouer, c’est pour ceux qui souhaite avoir une gestion des règles de routage très fine car la les règles de routage s'appliqueront aux éléments du header des messages (et on ne l’utilisera pas dans cet article).

Maintenant que l’on à fait le tour du jouet, on s’amuse un peu avec? ca sera au prochain épisode ….

Références:

[1] https://un-est-tout-et-tout-est-un.blogspot.com/2018/04/jee-jms.html
[2] https://www.rabbitmq.com/documentation.html
[3] https://un-est-tout-et-tout-est-un.blogspot.com/2019/08/docker-compose.html
[4] https://www.cloudamqp.com/blog/2015-09-03-part4-rabbitmq-for-beginners-exchanges-routing-keys-bindings.html
[5] https://blog.eleven-labs.com/fr/rabbitmq-partie-1-les-bases/
[6] https://www.rabbitmq.com/tutorials/tutorial-four-python.html
[7] https://lostechies.com/derekgreer/2012/05/29/rabbitmq-for-windows-headers-exchanges/
[8] https://hub.docker.com/r/softonic/rabbitmqadmin