RabbitMQ - Solution Message-Oriented Middleware


Avantages

Interopérabilité

L'interopérabilité est l'un des critères les plus importants dans le choix d'un middleware. Grâce au choix de l'implémentation du protocole AMQP, RabbitMQ assure une totale compatibilité entre n'importe quel broker et application client implémentant ce standard. Cela signifie que broker et application peuvent tourner chacun sur un système d'exploitation différent ou être développés avec des langages différents.

Pour prouver de son interopérabilité, RabbitMQ a testé son broker et ses API client avec le middleware Qpid. Ce dernier implémente tout comme RabbitMQ le standard AMQP, ce qui leur permet normalement d'être compatible. Les tests qui ont été effectués entre les deux middlewares sont les suivants :

Les tests sont concluants et démontrent que nous ne sommes pas dépendants du broker et des clients de RabbitMQ.



Haute disponibilité

RabbitMQ assure une complète disponibilité des messages de bout en bout, c'est-à-dire à partir de l'envoi par le producteur du message jusqu'à la réception par le consommateur. Les deux cas pratiques, qui nous intéressent, sont la gestion des deux situations suivantes :

  1. Broker hors service
  2. Consommateur hors service
Dans le premier cas, RabbitMQ, comme préciser dans son utilisation, possède une base de données appelée Mnesia. Lors de l'initialisation des composants (exchanges et queues) de notre broker, on peut les définir comme persistent. Alors, ces composants sont stockés dans la base de données de RabbitMQ et les messages, qui sont envoyés au fur et à mesure dans les queues, sont eux aussi dupliqués.
Cette option devient utile lorsque le broker devient hors service. Aucune information contenue dans le broker n'est perdue puisque tout a déjà été dupliqué. Lorsque le broker est à nouveau en service, il reconstruit tout ces composants à partir de la base de données et peut reprendre ses fonctions : envoi et réception de messages.
Il est aussi possible de définir un cluster de type actif/passif pour éviter une remise en marche manuelle du broker ; ou encore de définir une paire de noeuds (instance de broker) de type actif/passif, comme le cluster. Le principe des deux méthodes est le même, lorsque la machine active ou le noeud actif tombe, alors la machine passive ou le noeud passif prend la main jusqu'au rétablissement du premier.

Dans le deuxième cas, il y a deux types de scénarios possibles.
Soit le consommateur tombe alors que le message est encore dans la queue, et par conséquent le message est stocké dans la queue jusqu'à ce que le consommateur puisse le réceptionner, c'est le principe de l'envoi asynchrone.
Soit le consommateur tombe alors qu'il a reçu le message mais n'a pas eu le temps de le traiter, et par conséquent RabbitMQ propose un système d'accusé de réception. Tant que le message n'a pas été accusé, il n'est pas supprimé de la queue. Par défaut, le message est accusé dès réception par le consommateur. Mais il est possible d'envoyer manuellement l'accusé de réception au broker afin d'assurer la disponibilité du message jusqu'à la fin de son traitement.

Enfin, la haute disponibilité est assurée chez RabbitMQ par quatre grandes fonctionnalités :