Dans le domaine in­for­ma­tique, des messages doivent cons­tam­ment être envoyés d’un service à un autre. Cet envoi doit être effectué de façon contrôlée, faute de quoi les messages se bloquent mu­tuel­le­ment et pro­vo­quent une con­ges­tion empêchant ainsi que les processus ne se déroulent de façon optimale. Afin de permettre aux ap­pli­ca­tions de com­mu­ni­quer entre elles sans problème, il est pertinent de faire appel à un médiateur, c’est-à-dire un service qui assurera la dis­tri­bu­tion des messages. De tels mé­dia­teurs sont appelés message brokers (agents de messages). Nous vous pré­sen­tons l’un d’entre eux dans cet article : RabbitMQ.

Nom de domaine
Votre domaine en un clic
  • 1 cer­ti­fi­cat SSL Wildcard par contrat
  • Fonction incluse Domain Connect pour une con­fi­gu­ra­tion DNS sim­pli­fiée

Qu’est-ce que RabbitMQ ?

RabbitMQ est basé sur l’idée du Advanced Message Queuing Protocol (AMQP). Le principal avantage du AMQP est qu’il n’impose pas à l’émetteur et au des­ti­na­taire de com­prendre le même langage de pro­gram­ma­tion. Le message broker s’est aujourd’hui quelque peu détaché du AMQP et fonc­tionne également avec des pro­to­coles de messages comme STOMP ou MQTT grâce à des plugins, mais l’idée reste la même : le pro­duc­teur et le des­ti­na­taire du message sont séparés par une file d’attente dans laquelle les messages sont stockés tem­po­rai­re­ment.

Remarque

Le terme « message » est très souvent utilisé dans ce contexte. Les messages peuvent être des ins­truc­tions à d’autres pro­grammes ou des messages textuels à pro­pre­ment parler. Toute forme de transfert d’in­for­ma­tions peut avoir lieu via RabbitMQ ou d’autres message brokers.

L’avantage de RabbitMQ réside dans le fait que le pro­duc­teur du message n’a pas à effectuer per­son­nel­le­ment l’envoi. Le message broker reçoit le message et donne ainsi la pos­si­bi­lité au pro­duc­teur de commencer une nouvelle tâche. L’émetteur n’est pas obligé d’attendre que le des­ti­na­taire reçoive le message. Dans le cadre de cette procédure, le message est placé dans la file d’attente avant d’être récupéré par le con­som­ma­teur. À cet instant, l’émetteur est déjà occupé à une nouvelle tâche. Il s’agit donc d’une procédure asyn­chrone : l’émetteur et le des­ti­na­taire n’ont pas à agir au même rythme.

Dé­rou­le­ment avec RabbitMQ

Il existe quatre étapes dans la trans­mis­sion des messages :

  • Producer : génère le message
  • Exchange : transmet le message
  • Queue : stocke le message
  • Consumer : traite le message

Le « Producer » publie un message, mais au lieu de le trans­mettre di­rec­te­ment au « Consumer », il l’envoie à l’« Exchange ». Cette étape est res­pon­sable de la dis­tri­bu­tion des messages aux dif­fé­rentes files d’attente, qui les trans­met­tent ensuite au Consumer. Les étapes « Exchange » et « Queue » font partie de RabbitMQ et sont gérées par le logiciel. Pour que les messages par­vien­nent aux bons des­ti­na­taires, on utilise des « Routing Keys ». L’émetteur alloue au message une Routing Key qui fonc­tionne comme une adresse. À l’aide de cette clé, l’Exchange identifie la façon dont le message doit être adressé.

Un « Binding » a lieu entre l’Exchange et la file d’attente. Celui-ci assure la connexion entre chaque file d’attente in­di­vi­duelle et l’Exchange. Le Binding définit par ailleurs selon quels critères un message doit être transmis. Les messages peuvent être dis­tri­bués selon quatre types de base.

Direct Exchange

Un Direct Exchange est une connexion directe entre l’émetteur et le des­ti­na­taire. Le Producer alloue au message une Routing Key qui cor­res­pond à la Binding Key de la Queue. Par con­sé­quent, une seule Queue est possible et un seul Consumer est gé­né­ra­le­ment rattaché à cette dernière.

Topic Exchange

Ce type d’Exchange élargit le concept de Direct Exchange. Plutôt que d’avoir recours à un seul critère (Routing Key = Binding Key), plusieurs Queues peuvent être atteintes. Il fonc­tionne à l’aide de balises et permet d’accepter certaines Queues ou Binding Keys tout en main­te­nant l’exclusion des autres Queues.

Fanout Exchange

Le Fanout Exchange est une diffusion per­met­tant de dis­tri­buer un message à toutes les Queues dis­po­nibles. Aucun tri n’est effectué. Les Routing Keys sont ignorées.

Header Exchange

Le système ignore également les Routing Keys en cas de Header Exchanges. Pour ce type d’Exchange, c’est l’en-tête du message qui joue un rôle essentiel. L’Exchange y trouvera les attributs qui lui per­met­tront d’accéder aux bonnes Queues. En ce sens, l’Header Exchange fonc­tionne de façon similaire au Topic Exchange, puisqu’il existe également plusieurs Queues, mais elles ne peuvent pas être toutes adressées.

Les Consumers, autrement dit les logiciels des­ti­na­taires, s’ins­cri­vent à certaines Queues qui leur trans­met­tent les messages. Par con­sé­quent, un seul Consumer est également prévu par Queue. Si plusieurs Consumers retirent des messages d’une file d’attente, il est im­pos­sible de garantir une dis­tri­bu­tion correcte. Il est également possible, mais pas impératif, d’imposer ou pas au des­ti­na­taire l’envoi d’un accusé de réception pour chaque message.

RabbitMQ en pratique

RabbitMQ est un serveur open source codé en langage de pro­gram­ma­tion Erlang et peut être té­lé­chargé pour Linux, BSD, Unix, Windows et macOS depuis le site Internet officiel. Il est par ailleurs re­com­mandé d’installer des plug-ins fa­ci­li­tant le travail avec ce message broker et com­plé­tant l’éventail de fonc­tion­na­li­tés. En premier lieu, il est re­com­mandé d’activer le plugin de gestion, qui est fourni à l’ins­tal­la­tion, mais n’est pas activé par défaut. Avec ce plugin, les uti­li­sa­teurs peuvent gérer RabbitMQ à l’aide d’une IGU, disposer d’une vue d’ensemble des messages dans les files d’attente et consulter des sta­tis­tiques.

Le plugin Shovel peut aussi avoir son im­por­tance : il permet de connecter ensemble deux instances de broker. Cela peut notamment s’avérer utile pour mieux répartir la charge. Par ailleurs, vous pouvez déplacer des données sensibles ou de très grandes quantités de données dans un tout autre réseau, notamment pour des raisons de sécurité.

RabbitMQ nécessite des ports car la com­mu­ni­ca­tion fonc­tionne via TCP. Ces ports ne doivent pas être fermés ou bloqués par d’autres ap­pli­ca­tions. Une liste de tous les ports utilisés est dis­po­nible dans la do­cu­men­ta­tion de RabbitMQ.

En résumé

RabbitMQ séduit prin­ci­pa­le­ment par sa cons­truc­tion simple. Le message broker peut être mis en place ra­pi­de­ment et se montre utile dans de nom­breuses si­tua­tions. Toutefois, dans les scénarios de plus grande envergure, les dé­ve­lop­peurs et les ad­mi­nis­tra­teurs préfèrent utiliser Apache Kafka.

Aller au menu principal