Un tour d'horizon sur RabbitMQ
ELEPHANT technologies, l’ESN locale et à taille humaine spécialisée sur 2 métiers : le développement et le pilotage autour de 4 expertises : hardware, embarqué, software et web.
Aujourd'hui, retrouvez Robert notre elephantech développeur fullstack (java, angular) qui nous parle de la découverte de broker RabbitMQ.
Let’s go !
Un tour d’horizon sur RABBITMQ
Dans le domaine informatique, des messages sont constamment envoyés d’un service à un autre ou d’un point A à un point B. Cet envoi doit être effectué de façon contrôlée sinon les messages se bloquent et provoquent la fin du processus. Afin de permettre aux applications de communiquer entre elles sans problème, faire appel à un médiateur est conseillé (il s’agit d’un service qui assurera la distribution des messages). Ces médiateurs sont appelés des message brokers.
Exemple : ActiveMQ, KAFKA et RabbitMQ.
Qu’est-ce que RabbitMQ ?
Initialement développé par Rabbit Technologie Ltd, le serveur RabbitMQ est un message broker, une multi-plateforme et un multi-protocole, écrit en Erlang. (AMQP, MQTT, STOMP). C’est en 2010 qu’il est acquis par SpringSource pour ensuite incorporer Pivotal Software en 2013.
RabbitMQ est particulièrement adapté pour monter rapidement une architecture micro-services. Ce qui nécessite cependant un bus de message pour garantir les communications entre les différentes briques de cette architecture.
Son rôle est de transformer et de router les messages, depuis les publishers vers les consumers. Le broker utilise les exchanges et les bindings pour savoir s’il doit délivrer ou non le message dans la queue.
Le publisher va envoyer un message dans un exchange qui va, en fonction du binding, router le message vers la ou les queues. Ensuite un consumer va consommer les messages.
Quels sont les éléments que composent un broker ?
Comment le message transite d’un publisher à un consommer ?
1er élément : le Message
Le message est comme une requête HTTP, c’est-à-dire qu’il contient des attributs ainsi qu’un payload.
Parmi les attributs du protocole, vous pouvez depuis votre puplisher y ajouter des headers qui seront disponibles dans attributes[headers]. L’attribut routing_key, n’est pas très utile dans ce protocole.
2ème élément : les Bindings
Les bindings sont les règles que les exchanges utilisent pour déterminer à quelle queue il faut délivrer le message. Les différentes configurations peuvent utiliser la routing key (direct/topic exchanges) ainsi que les headers (header exchanges).
3ème élément : les Exchanges
Un exchange est un routeur de message. A savoir que chaque type d’exchange définit différents types de routage.
Attention ! Vous pouvez publier un exchange mais vous ne pouvez pas en consommer.
Il est important de savoir que l'exchange de Rabbit par défaut est l’exchange amq.default. Vous pouvez ni le supprimer ni vous binder dessus. Cet exchange est auto bindé avec toutes les queues et avec une routing key égale au nom de la queue.
L’EXCHANGE TYPE FANOUT
L’exchange fanout délivre le message à toutes les queues bindées.
L’EXCHANGE TYPE DIRECT
L’exchange direct n’autorise que le binding utilisant la routing key. Si celle du message est strictement égale à celle spécifiée dans le binding alors le message sera délivré à la queue.
L’EXCHANGE TYPE TOPIC
L’exchange topic délivre le message si la routing_key du message matche le pattern défini dans le binding.
Une routing key est composé de plusieurs segments séparés par des « .. » Il y a également 2 caractères utilisés dans le matching :
* N’importe quelle valeur de segment
# N’importe quelle valeur de segment une ou plusieurs fois
L’EXCHANGE TYPE HEADERS
L’exchange headers délivre le message si les headers du binding matchent les headers du message.
L’option x-match dans le binding permet de définir si un seul header ou tous doivent matcher.
X-MATCH = ANY → le message sera délivré si un seul des headers du binding correspond à un header du message.
X-MATCH = ALL → le message sera délivré si tous les headers du binding correspondent aux headers du message.
4ème élément : les Queues
Une queue est l’endroit où sont stockés les messages. Il existe des options de configuration afin de modifier leurs comportements.
En voici quelques une :
→ Durable (stockée sur disque), la queue survivra au redémarrage du broker. Attention seuls les messages persistants survivront au redémarrage.
→ Exclusive, la queue sera utilisable sur une seule connexion et sera supprimée à la clôture de celle-ci.
→ Auto-delete, la queue sera supprimée quand toutes les connections seront fermées (après au moins une connexion).
Bon à savoir ! Quand vous croyez publier dans une queue, en réalité le message est publié dans l’exchange amq.default avec la routing key = queue name.
Consumer
Le rôle du consumer est d’exécuter un traitement après avoir récupéré un ou plusieurs messages. Pour cela, il va réserver un ou plusieurs messages depuis la queue, avant d’exécuter un traitement. Généralement si le traitement s’est correctement déroulé, le consumer va acquitter le message avec succès (basic.ack). En cas d’erreur, le consumer peut également acquitter négativement le message (basic.nack). Si celui-ci n’est pas acquitté, il restera à sa place dans la queue et sera re fetch un peu plus tard.
Vous voilà maintenant fins prêts pour démarrer sur RabbitMQ !
🐘 Nous remercions Robert pour son article et si vous souhaitez découvrir d'autres articles techniques, c'est par ici : https://www.elephant-technologies.fr/les-actualites?news_category_filter%5Bcategory%5D=