RabbitMQ är ett utmärkt open-source-projekt som gör att du kan leverera hundratusentals meddelanden per sekund till din ansökan snabbt och effektivt. Följande post presenterar hur du kan placera ett RabbitMQ-kluster med tre separata värdar. För detta ändamål kommer vi att använda Docker och ansluta till det färdiga klustret med Node.js.

om RabbitMQ

RabbitMQ är ett kösystem baserat på AMQP-protokollet, själva systemet skrevs i Erlang. Tack vare användningen av detta språk är RabbitMQ idealisk för användning som en central databuss i mikroservicearkitekturen. En sådan skena ger ett bra substrat för applikationer som möjliggör ett stort dynamiskt utvecklingsområde i DDD-och CQRS-paradigmet. Eftersom databussen (kö av meddelanden) är ryggraden i arkitekturen är det viktigt att det alltid är tillgängligt och motståndskraftigt mot fel. Redundant arkitektur blir det naturliga valet, dvs replikering av data i separata verkställande noder.

replikering i RabbitMQ stöds inbyggt i master-slave-läge. Detta innebär att RabbitMQ alltid kommer att välja en nod för varje skapad kö och det kommer att omdirigera alla meddelanden till den för att spara, samt hämta meddelanden från den för att läsa från kön, de andra noderna (slavar) fungerar som en data replikator redo att ta över rollen som huvudnoden hela tiden. Även om den största känslan är replikering när noder är utspridda på olika fysiska maskiner, kommer jag i detta fall att använda ett exempel på replikering inom samma maskin. RabbitMQ på grund av dess syfte – det vill säga hundratusentals stödda meddelanden per sekund, föredras inte i replikationsläge på maskiner som inte finns i samma serverrack. Detta beror på det faktum att meddelanden stanna i kön mycket kort och antagandena bör inte gå utöver RAM, replikera dem baserat på en nätverksanslutning i en annan del av datacentret eller till en helt annan datacenter skulle innebära drastiska minskningar i prestanda, och i detta system klass kan inte ges. Dessutom, genom att placera RabbitMQ-noder nära varandra, minimerar vi risken för så kallad nätverkspartition (vilket är mycket osannolikt när det gäller en roulette), d.v. s. fenomenet att avbryta kommunikationen mellan noder på ett sådant sätt att minst 2 noder från hela klustret anser sig vara mästare. Mer om nätverkspartitionen i samband med RabbitMQ kan läsas här.

därför sätter den praktikbaserade regeln RabbitMQ i replikeringsläge endast i samma datacenter.

ladda ner Docker-bilder

jag antar att du vet vad som är Docker och hur du använder det, för i nästa del av posten kommer vi att använda den i stor utsträckning

börja med att ladda ner lämpliga RabbitMQ-bilder (tillsammans med adminpanelen plugin) och Nod.js, för detta ändamål använder vi följande kommandon:

docker pull 3.6.6-managementdocker pull node:11.10.1

Setup RabbitMQ hosts

för presentationen kommer vi att starta en RabbitMQ-bild som vi kommer att ansluta till kommandot docker exec och åberopa bash-skalet för att kunna köra konfigurationen på vårt sätt. Låt oss använda kommandot:

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

ovanstående kommando kommer att köra bilden från RabbitMQ som kommer att raderas efter att ha lämnat skalet. Instansen kommer att anslutas till vårt nätverksgränssnitt så vi behöver inte oroa oss för port vidarebefordran. Om skalet [email protected]:/# visade sig för våra ögon betyder det att allt gick bra.

nästa steg är att köra tre RabbitMQ-processer på separata portar, varje process får ett unikt namn.

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

nästa, med hjälp av rabbitmqctl, bifogar vi båda noderna till roten med namnet 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

när allt kommer omkring kan vi öppna webbläsaren och ange adressen http://localhost:15672 för att verifiera att allt gick bra bör klusterhanteringskonsolen peka på alla noder som på skärmen nedan.

viktigt. Inaktivera inte containerskalet från RabbitMQ eftersom det tar bort det (alternativet –rm på kommandot Docker startup)

vi har det sista att göra, även om RabbitMQ-klustret är klart, måste vi konfigurera lämpliga policyer. Denna funktion implementeras med hjälp av administrationspanelen, mer information om hög tillgänglighet (HA) i RabbitMQ kan läsas i dokumentationen.

ovan är ett exempel på ha-policykonfiguration. Och Nedan är verifieringsmetoden. Numret + 2 Vid nodnamnet betyder antalet separata värdar som kön replikeras till.

Installation och nedladdning av AMQP-biblioteket vid Node.js

nästa steg är att starta Docker-containerinstansen med noden.js image, för detta ändamål, kör följande kommando som också delar nätverksgränssnittet.

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

sedan på den plats som valts av vår webbplats (t.ex. /home) skapar vi en katalog där vi lägger nödvändiga skript och installerar AMQP-connection-manager-biblioteket som tillåter anslutning till RabbitMQ (eller annat system som implementerar AMQP-protokollet) från noden.js.

npm install --save amqp-connection-manager

dessutom tillåter biblioteket tillägg av flera RabbitMQ-värdadresser som ger en mekanism för att återansluta i händelse av fel på någon värd. Detta är en mycket användbar funktionalitet, eftersom den bryr sig om en korrekt anslutning till RabbitMQ och i händelse av ett fel kan det upptäcka meddelanden i minnet tills anslutningen visas tillbaka.

Provproducent-konsumentkod

nu när vi har förberett alla komponenter kan vi börja skapa en enkel kod som är ansvarig för att skapa och ta emot meddelanden. För detta ändamål skapar vi två filer och fyller dem med en kod.

producent.JS-skriptet ansluter till RabbitMQ-instansen och börjar skicka 10 meddelanden per sekund.

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()

konsument.JS-skriptet ansluter till RabbitMQ-instansen och börjar läsa meddelanden från kön.

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()

filer som skapats på detta sätt kan köras separat med Node.js och watch as consumer.js tar emot data som produceras av producer.js. För att verifiera replikeringsoperationen i RabbitMQ-klustret uppmuntrar jag dig att inaktivera under utbyte av data med skript en av RabbitMQ-processerna för att se hur felet kommer att hanteras och hur RabbitMQ kommer att välja den nya mästaren och omdirigera meddelandena i enlighet därmed.

rabbitmqctl -n john stop_app

att inaktivera en av RabbitMQ-instanserna påverkar inte produktionen eller nedladdningen av meddelanden. Köer replikeras automatiskt och anslutningen återställs utan att behöva implementera sina egna mekanismer.

Sammanfattningsvis är RabbitMQ ett bra kösystem som säkerställer hög tillgänglighet efter en korrekt konfiguration som inte orsakar många problem. Ett stort antal bibliotek på många språk, t.ex. nod.js, PHP, Java, Python, Golang, C / C++, möjliggör enkel implementering av systemet i projektet. Jag rekommenderar alla att läsa dokumentationen som förklarar mycket tydligt problemen med driften av systemet och dess korrekta konfiguration, vilket är väldigt omfattande.

all kod lagras i förvaret på Github

liknande sökningar: nodejs rabbitmq / nodejs queue / rabbitmq queue nodejs