RabbitMQ est un excellent projet open-source qui vous permet de transmettre des centaines de milliers de messages par seconde à votre application rapidement et efficacement. L’entrée suivante présente la manière dont vous pouvez placer un cluster RabbitMQ de trois hôtes distincts. À cette fin, nous utiliserons Docker et nous connecterons au cluster prêt à l’aide de Node.js.

À propos de RabbitMQ

RabbitMQ est un système de file d’attente basé sur le protocole AMQP, le système lui-même a été écrit en Erlang. Grâce à l’utilisation de ce langage, RabbitMQ est parfaitement adapté pour une utilisation en tant que bus de données central dans l’architecture de microservices. Un tel rail fournit un excellent substrat pour des applications permettant une large gamme dynamique de développement dans le paradigme DDD et CQRS. Étant donné que le bus de données (file d’attente de messages) est l’épine dorsale de l’architecture, il est important qu’il soit toujours disponible et résistant aux pannes. L’architecture redondante devient le choix naturel, c’est-à-dire la réplication des données dans des nœuds exécutifs distincts.

La réplication dans RabbitMQ est prise en charge nativement en mode maître-esclave. Cela signifie que RabbitMQ sélectionnera toujours un nœud pour chaque file d’attente créée et il y redirigera tous les messages pour les enregistrer, ainsi que les récupérera pour les lire dans la file d’attente, les autres nœuds (esclaves) agissent comme un réplicateur de données prêt à prendre en charge le rôle du nœud maître à tout moment. Bien que le plus grand sens soit la réplication lorsque les nœuds sont dispersés sur différentes machines physiques, dans ce cas, j’utiliserai un exemple de réplication au sein de la même machine. RabbitMQ en raison de son but – c’est-à-dire des centaines de milliers de messages pris en charge par seconde, n’est pas préféré en mode de réplication sur des machines qui ne sont pas dans le même rack de serveur. Cela est dû au fait que les messages restent très courts dans la file d’attente et que les hypothèses ne doivent pas aller au-delà de la RAM, les répliquer sur la base d’une connexion réseau dans une partie différente du centre de données ou vers un centre de données complètement différent signifierait une diminution drastique des performances, et dans cette classe de système ne peut pas être accordée. De plus, en plaçant les nœuds RabbitMQ proches les uns des autres, nous minimisons le risque de partition réseau (ce qui est très peu probable dans le cas d’une roulette), c’est-à-dire le phénomène d’interruption de la communication entre les nœuds de telle sorte qu’au moins 2 nœuds de l’ensemble du cluster se considèrent comme maître. Plus d’informations sur la partition réseau dans le contexte de RabbitMQ peuvent être lues ici.

Par conséquent, la règle basée sur la pratique met RabbitMQ en mode de réplication uniquement dans le même centre de données.

Téléchargement d’images Docker

Je suppose que vous savez ce qu’est Docker et comment l’utiliser, car dans la partie suivante de l’entrée, nous l’utiliserons largement

Pour commencer, commencez par télécharger les images RabbitMQ appropriées (avec le plugin du panneau d’administration) et le nœud.js, à cet effet, nous utilisons les commandes suivantes:

docker pull 3.6.6-managementdocker pull node:11.10.1

Configuration des hôtes RabbitMQ

Pour les besoins de la présentation, nous lancerons une image RabbitMQ à laquelle nous nous connecterons avec la commande docker exec et invoquerons le shell bash pour pouvoir exécuter la configuration à notre manière. Utilisons la commande:

docker run --hostname rabbit --name rabbit --rm -ti --net="host" rabbitmq:3.6.6-management /bin/bash

La commande ci-dessus exécutera l’image à partir de RabbitMQ qui sera supprimée après avoir quitté le shell. L’instance sera connectée à notre interface réseau afin que nous n’ayons pas à nous soucier de la redirection de port. Si la coquille [email protected]:/# est apparue à nos yeux, cela signifie que tout s’est bien passé.

L’étape suivante consiste à exécuter trois processus RabbitMQ sur des ports distincts, chaque processus recevra un nom unique.

RABBITMQ_NODE_PORT=5672 RABBITMQ_SERVER_START_ARGS="-rabbitmq_management listener " RABBITMQ_NODENAME=rabbit rabbitmq-server -detachedRABBITMQ_NODE_PORT=5673 RABBITMQ_SERVER_START_ARGS="-rabbitmq_management listener " RABBITMQ_NODENAME=hare rabbitmq-server -detachedRABBITMQ_NODE_PORT=5674 RABBITMQ_SERVER_START_ARGS="-rabbitmq_management listener " RABBITMQ_NODENAME=john rabbitmq-server -detached

Ensuite, à l’aide du rabbitmqctl, nous attachons les deux nœuds à la racine avec le nom rabbit:

rabbitmqctl -n hare stop_apprabbitmqctl -n hare join_cluster [email protected]`hostname -s`rabbitmqctl -n hare start_apprabbitmqctl -n john stop_apprabbitmqctl -n john join_cluster [email protected]`hostname -s`rabbitmqctl -n john start_app

Après tout, nous pouvons ouvrir le navigateur et entrer l’adresse http://localhost:15672 pour vérifier que tout s’est bien passé, la console de gestion du cluster doit pointer vers tous les nœuds comme sur l’écran ci-dessous.

Important. Ne désactivez pas le shell de conteneur de RabbitMQ car cela le supprimera (l’option –rm de la commande de démarrage Docker)

Nous avons la dernière chose à faire, bien que le cluster RabbitMQ soit prêt, nous devons configurer les stratégies appropriées. Cette fonction est implémentée à l’aide du panneau d’administration, plus d’informations sur la haute disponibilité (HA) dans RabbitMQ peuvent être lues dans la documentation.

Ci-dessus est un exemple de configuration de stratégie HA. Et voici la méthode de vérification. Le nombre +2 au nom du nœud signifie le nombre d’hôtes distincts sur lesquels la file d’attente est répliquée.

Installation et téléchargement de la bibliothèque amqp sur Node.js

L’étape suivante consiste à démarrer l’instance de conteneur Docker avec le nœud.image js, à cet effet, exécutez la commande suivante qui partage également l’interface réseau.

docker run -ti --rm --net="host" node:11.10.1 /bin/bash

Ensuite, à l’endroit choisi par notre site (par exemple /home), nous créons un répertoire dans lequel nous mettons les scripts nécessaires et installons la bibliothèque amqp-connection-manager qui permet la connexion à RabbitMQ (ou à un autre système implémentant le protocole AMQP) à partir du niveau du nœud.js.

npm install --save amqp-connection-manager

De plus, la bibliothèque permet l’ajout de plusieurs adresses d’hôte RabbitMQ fournissant un mécanisme de reconnexion en cas de défaillance d’un hôte. C’est une fonctionnalité très utile, car elle veille à une connexion correcte avec RabbitMQ et en cas d’échec, elle peut détecter les messages en mémoire jusqu’à ce que la connexion apparaisse.

Exemple de code producteur-consommateur

Maintenant que nous avons tous les composants préparés, nous pouvons commencer à créer un code simple responsable de la création et de la réception des messages. Pour cela, nous allons créer deux fichiers et les remplir avec un code.

producteur.js – le script se connecte à l’instance RabbitMQ et commence à envoyer 10 messages par seconde.

let q = 'tasks';let amqp = require('amqp-connection-manager');function sleep(ms) { if(ms setTimeout(resolve, ms));}let main = async () => { var connection = amqp.connect(); var channelWrapper = connection.createChannel({ json: true, setup: function(channel) { return channel.assertQueue(q, { durable: true }); } }); console.log('Starting message stream') while (true) { await channelWrapper.sendToQueue(q, { value: Math.random() }) await sleep(100) }}main()

consommateur.js – le script se connecte à l’instance RabbitMQ et commence à lire les messages de la file d’attente.

let q = 'tasks';let amqp = require('amqp-connection-manager');let main = async () => { var connection = amqp.connect(); var channelWrapper = connection.createChannel({ json: true, setup: function(channel) { return channel.assertQueue(q, { durable: true }); } }); channelWrapper.addSetup(function(channel) { return Promise.all() });}main()

Les fichiers ainsi créés peuvent être exécutés séparément à l’aide de Node.js et regardez comme consumer.js reçoit des données produites par producer.js. Afin de vérifier l’opération de réplication dans le cluster RabbitMQ, je vous encourage à désactiver lors de l’échange de données par des scripts l’un des processus RabbitMQ pour voir comment l’échec sera géré et comment RabbitMQ sélectionnera le nouveau maître et redirigera les messages en conséquence.

rabbitmqctl -n john stop_app

La désactivation de l’une des instances RabbitMQ n’affecte pas la production ou le téléchargement des messages. Les files d’attente sont automatiquement répliquées et la connexion récupérée sans qu’il soit nécessaire d’implémenter ses propres mécanismes.

En résumé, RabbitMQ est un excellent système de file d’attente qui assure une haute disponibilité après une configuration correcte qui ne pose pas beaucoup de problèmes. Un grand nombre de bibliothèques dans de nombreuses langues, par exemple Node.js, PHP, Java, Python, Golang, C / C ++, permet une implémentation facile du système dans le projet. Je recommande à tout le monde de lire la documentation qui explique très clairement les problèmes liés au fonctionnement du système et à sa configuration correcte, ce qui est vraiment vaste.

Tout le code est conservé dans le dépôt sur Github

Recherches similaires : nodejs rabbitmq / nodejs queue / rabbitmq queue nodejs