Meddelandeköer
En meddelandekö är en metod som används för IPC (inter-process communication – kommunikation mellan processer) eller mellan olika komponenter i ett program eller flera program. Meddelandeköer innehåller ett protokoll eller gränssnitt för att möjliggöra meddelandeöverföring.
Meddelandeköer för IPC inom en dator har gjorts tillgängliga via UNIX <sys.msg.h>- och POSIX mqueue.h-systembibliotek, där de kan användas i både synkront och asynkront läge. Ett synkront meddelande kräver att sändnings- eller mottagningsprocesser blockeras medan meddelandet skickas, tills det har bekräftats av mottagaren. Asynkrona meddelanden blockerar inte sändnings- eller mottagningsprocesser och kan buffras för fördröjd leverans.
För program som kan sträcka sig över flera datorer har ett antal meddelandekösystem, både tillverkarspecifika och med öppen källkod, utvecklats, till exempel IBM:s WebSphere MQ, Java Message Service (JMS) och RabbitMQ. Alla dessa system ger möjlighet att skicka, hantera och ta emot meddelanden.
Användning av meddelandeköer kan göra programdesignen mer komplex och öka antalet tjänster som måste hanteras, i jämförelse med traditionella meddelandefunktioner med begäran och svar. Men i en viss skala, och för dataströmbearbetningsprogram, behövs distribuerade meddelandekösystem för att hantera den extra komplexiteten och skalan.
Bild 1: Ett gränssnitt ansluter till avsändare (eller producenter), som skapar meddelanden och till mottagare (eller konsumenter) som kan ta emot meddelandena.
Egenskaper för meddelandeköer
Meddelandeköer och deras nyhet kan förstås och uppskattas när de jämförs med traditionella RPC- och begäran–svar-mekanismer. De primära funktionerna i en meddelandekö är följande:
Lagring: Till skillnad från traditionella system för begäran och svar som förlitar sig på grundläggande TCP- och UDP-protokoll över socketar lagrar meddelandeköer vanligtvis meddelanden i någon typ av buffert tills de antingen har lästs av en målprocess eller uttryckligen tagits bort från meddelandekön.
Asynkronitet: Till skillnad från begärande- och svarssystem gör buffring av meddelanden att meddelandeköer kan exponera en viss grad av asynkronitet i program, vilket gör att källprocesser kan skicka meddelanden och låta dem ackumuleras i en kö medan målprocesserna hämtar dem att bearbeta. Det gör att program kan fungera i vissa felscenarier, till exempel ojämn anslutning eller fel i källprocessen eller målprocessen.
Routning: Meddelandeköer kan också tillhandahålla routningsfunktioner, där flera processer kan läsa eller skriva meddelanden i samma kö, vilket möjliggör sändnings- eller unicast-kommunikationsparadigm.
Fördelar med meddelandeköer
Den främsta fördelen med en meddelandekö är att den ger lös koppling mellan olika entiteter i ett distribuerat program. Det möjliggör asynkron icke-blockerande kommunikation som ger en högre toleransnivå mot fel i processer.
Bild 2: Meddelandeköer tillhandahåller ett gränssnitt som gör det möjligt för program att kommunicera med varandra.
- Inga direkta anslutningar mellan program: Meddelandeköer möjliggör indirekt program-till-program-kommunikation. Avsändare behöver inte nödvändigtvis känna till mottagarna av meddelanden och tvärtom. Det här möjliggör för logiken för routning av meddelanden (och potentiellt arbete) att beslutas av meddelandekösystemet.
- Kommunikationen mellan program kan vara oberoende av tid: Meddelandeköer buffrar vanligtvis meddelanden mellan program så att de inte behöver blockera eller avbryta körningen för att skicka eller ta emot meddelanden. De kan utföra annat arbete och bearbeta svaret när ett meddelande kommer in eller vid ett senare tillfälle. När du skriver ett meddelandeprogram behöver du inte veta (eller bekymra dig om) när ett program skickar ett meddelande, eller när målet kan ta emot ett meddelande. Meddelandet har inte gått förlorat, utan det behålls av köhanteraren tills målet är redo att bearbeta det. Meddelandet stannar kvar i kön tills det tas bort av ett program. Det betyder att skicka och ta emot program är fristående. Avsändaren kan fortsätta bearbeta utan att vänta på att mottagaren bekräftar mottagningen av meddelandet. Målprogrammet måste inte ens köras när meddelandet skickas. Den kan hämta meddelandet när den har startats.
- Arbete kan utföras av små fristående program: Med meddelandeköer kan du använda fördelarna med att använda små, fristående program. Istället för ett enda, stort program som utföra alla delar av ett jobb sekventiellt kan du sprida jobbet på flera mindre, oberoende program. Det begärande programmet skickar meddelanden till vart och ett av de separata programmen och ber dem utföra sin funktion. När varje program har slutförts skickas resultatet tillbaka som ett eller flera meddelanden.
- Kommunikation kan styras av händelser: Program kan styras enligt köernas tillstånd. Du kan till exempel se till att ett program startar så snart ett meddelande kommer in i kön. Eller så kan du ange att programmet inte startar förrän det, till exempel, finns 10 meddelanden över en viss prioritet i kön eller 10 meddelanden av valfri prioritet i kön.
- Program kan tilldela ett meddelande en prioritet: Ett program kan tilldela ett meddelande en prioritet när meddelandet placeras i en kö. Det här anger positionen i kön som det nya meddelandet läggs till på. Program kan hämta meddelanden från en kö i den ordning som meddelanden är i kön eller genom att hämta ett specifikt meddelande. (Ett program kan vilja hämta ett specifikt meddelande om det letar efter ett svara på en begäran som det har skickat tidigare.)
- Återställningsstöd: Många meddelandeköer erbjuder beständighet och loggning, vilket möjliggör återställning av tillstånd och meddelanden i kön vid fel.
- Flera köer: Vissa system tillåter flera köer som kan definieras och konfigureras av programutvecklaren. Det här gör att meddelanden kan dirigeras till de nödvändiga entiteterna baserat på en utgivar- eller prenumerantrelation. Apache Kafka är ett exempel på detta.
- Enkel skalbarhet: Meddelandeköer kan skalas horisontellt för att hantera en ökning av meddelandebelastningen, till skillnad från nära kopplade system, där det är svårare att skala och hantera kommunikationstrafik och slutpunkter.