God dag, Habr! Jag vill dela med mig av en lärobok-guide med den kunskap jag har kunnat samla om RabbitMQ och sammanställa som korta rekommendationer och slutsatser.
Innehållsförteckning
- RabbitMQ. Del 1. Introduktion. Erlang, AMQP och RPC
- RabbitMQ. Del 2. Vi går igenom Exchanges
- RabbitMQ. Del 3. Vi går igenom Queues och Bindings
- RabbitMQ. Del 4. Vi går igenom vad meddelanden och ramverk är
- RabbitMQ. Del 5. Prestanda för publicering och konsumtion av meddelanden
- RabbitMQ. Del 6. Översikt av modulerna Federation och Shovel
- RabbitMQ. Del 7. Detaljer om Connection och Channel
- RabbitMQ. Del 8. RabbitMQ i .NET
- RabbitMQ. Del 9. Övervakning
Kort om AMQP
AMQP (Advanced Message Queuing Protocol) – en öppen protokoll för att överföra meddelanden mellan systemkomponenter. Huvudidén är att separata delsystem (eller oberoende applikationer) kan utbyta meddelanden på valfritt sätt genom en AMQP-broker, som ansvarar för routning, eventuellt garanterar leverans, distribuerar datastreams och prenumererar på nödvändiga meddelandetyper.
Protokoll AMQP introducerar tre begrepp:

exchange(utbytespunkt eller utbyte) – till vilken meddelanden skickas. Utbytespunkten fördelar meddelandet skickar vidare till en eller flera köer. Den ruttnar meddelanden till köer baserat på de skapade kopplingarna (binding) mellan den och könqueue(kö) – en databasstruktur på disk eller i RAM som lagrar referenser till meddelanden och ger kopior av meddelandenconsumers(konsumenter)binding(bindning) – en regel som meddelar utbytespunkten till vilken av köerna dessa meddelanden ska komma.
Protokollet fungerar ovanpå .
Kort om Erlang
Källkoden för projektet finns i ett repository på . Arkitekturen är baserad på och BEAM.
Erlangutvecklades av företagetEricssoni mitten av 1980-talet som ett distribuerat, felfritt realtidsystem för applikationer som kräver en pålitlighet på 99,999%.Erlanganvänds inom olika branscher och moderna applikationer, exempelvis i
Kort om RabbitMQ
– är en meddelandebroker med öppen källkod. Den routar meddelanden enligt alla grundläggande principer för protokollet beskrivna i . RabbitMQ implementerar och kompletterar protokollet. AMQP.
Huvudidén med meddelandeutbytesmodellen i RabbitMQ är att producer (producent) inte skickar meddelanden direkt till kön. I själva verket vet producenten oftast inte ens om meddelandet kommer att levereras till någon kö.
Istället kan utgiveren skicka meddelanden endast till en mäklare. Å ena sidan tar mäklaren emot meddelanden från utgivarna, å andra sidan skickar den dem till köer. Mäklaren måste veta exakt vad som ska göras med det mottagna meddelandet. Ska det läggas till i en viss kö? Ska det läggas till i flera köer? Eller ska meddelandet ignoreras?

Kortfattat kan arbetet RabbitMQ beskrivas på följande sätt:
- Utgivaren skickar ett meddelande till en specifik mäklare
- Mäklaren, när den mottar ett meddelande, dirigerar det till en eller flera köer enligt bindningsreglerna mellan mäklaren och köerna
- Kön lagrar en referens till detta meddelande. Meddelandet i sig lagras i RAM eller på disk
- När konsumenten är redo att hämta ett meddelande från kön, skapar servern en kopia av meddelandet via referensen och skickar det
- Konsumenten tar emot meddelandet och skickar en bekräftelse till mäklaren
- Mäklaren, när den får bekräftelsen, tar bort kopian av meddelandet från kön. Därefter tar den bort den från RAM och disk
RPC
Process ligger till grund för praktiskt taget all interaktion med kärnan RabbitMQ. Till exempel, inledande diskussioner om kundens villkor med RabbitMQ, visar en viss process RPC. När denna sekvens är klar, RabbitMQ kommer att vara redo att ta emot förfrågningar från kunden:

Det finns också i specifikationen AMQP och både klient och server kan anropa kommandon. Detta innebär att klienten förväntar sig interaktion med servern. Kommandon är klasser och metoder. Till exempel, Connection.Start – anrop av metoden Start klassen Connection.
Anslutning och kanaler
För sådan informationsutbyte mellan klienten och servern används kanaler. Kanaler skapas inom ramen för en viss anslutning. Varje kanal är isolerad från andra kanaler. I synkron läge kan man inte utföra nästa kommando förrän svar har mottagits.
För att kunna skicka kommandon parallellt måste flera kanaler öppnas. Varje kanal skapar en separat Erlang process. En anslutning kan ha många kanaler (). För varje kanal finns det vissa strukturer och objekt i minnet. Ju fler kanaler som finns inom en anslutning, desto mer minne används RabbitMQ för att hantera en sådan anslutning.

Ett enkelt exempel på att skapa en anslutning och kanal med hjälp av :
// ...
private void TryConnect()
{
var factory = new ConnectionFactory()
{
HostName = "host_name",
UserName = "user_name",
Password = "p@ssword",
// Включение автоматичекого восстановления
// соединения после сбоев сети
AutomaticRecoveryEnabled = true
};
_connection = factory.CreateConnection();
}
// ...
public void CreateChanel()
{
_channel = _connection.CreateModel();
// other options
}Att öppna en ny anslutning för varje operation rekommenderas starkt inte, eftersom detta kommer att leda till stora kostnader. Kanalerna bör också vara permanenta, men många protokollfel leder till att kanalen stängs, så livslängden för kanalen kan vara kortare än för anslutningen.
Var används RabbitMQ?
I kontexten av mikrotjänster används protokollet AMQP och dess implementation i RabbitMQ används ofta för asynkron kommunikation mellan tjänster.
I kontexten av IIOT protokoll AMQP och dess implementation i RabbitMQ används för datadelning mellan servrar (server-till-server). Dessutom används plugin som är en implementation av protokollet för datatransmission mellan sensorn och servern i låga hastighetsmiljöer med hög latens (en fullständig lista över stödda protokoll finns på ).
I nästa artikel kommer vi att börja titta närmare på Exchanges.
Länkar
Källa: habr.com
