Meddelandekö

"Mailbox (computing)" omdirigerar hit. För filformatet, se Mbox .

Inom datavetenskap är meddelandeköer och brevlådor mjukvarutekniska komponenter som vanligtvis används för interprocesskommunikation (IPC), eller för kommunikation mellan trådar inom samma process. De använder en kö för meddelanden – förmedling av kontroll eller innehåll. Gruppkommunikationssystem tillhandahåller liknande typer av funktionalitet.

Meddelandeköparadigmet är ett syskon till förlags-/prenumerantmönstret och är vanligtvis en del av ett större meddelandeorienterat mellanprogramsystem . De flesta meddelandesystem stöder både utgivare/prenumerant- och meddelandekömodeller i deras API , t.ex. Java Message Service (JMS).

Uppdrag och ägande

Meddelandeköer implementerar ett asynkront kommunikationsmönster mellan två eller flera processer/trådar varigenom den sändande och mottagande parten inte behöver interagera med meddelandekön samtidigt. Meddelanden som placeras i kön lagras tills mottagaren hämtar dem. Meddelandeköer har implicita eller explicita gränser för storleken på data som kan överföras i ett enda meddelande och antalet meddelanden som kan förbli utestående i kön.

Remittera

Många implementeringar av meddelandeköer fungerar internt i ett operativsystem eller i en applikation . Sådana köer finns endast för det systemets syften .

Andra implementeringar tillåter vidarebefordran av meddelanden mellan olika datorsystem, vilket potentiellt kopplar samman flera applikationer och flera operativsystem. Dessa meddelandekösystem tillhandahåller vanligtvis motståndskraftig funktionalitet för att säkerställa att meddelanden inte "försvinner" i händelse av ett systemfel. Exempel på kommersiella implementeringar av denna typ av meddelandeköprogramvara ( även känd som meddelandeorienterad mellanprogram ) inkluderar IBM MQ (tidigare MQ Series) och Oracle Advanced Queuing (AQ). Det finns en Java- standard som heter Java Message Service , som har flera proprietära och gratis programvaruimplementationer .

Realtidsoperativsystem (RTOS) som VxWorks och QNX uppmuntrar användningen av meddelandekö som den primära kommunikationsmekanismen mellan processer eller trådar. Detta kan resultera i integration mellan meddelandeöverföring och CPU-schemaläggning. Tidiga exempel på kommersiella RTOSer som uppmuntrade en meddelandeköbas för kommunikation mellan trådar inkluderar också VRTX och pSOS +, som båda är från början av 1980-talet. Programmeringsspråket Erlang använder processer för att ge samtidighet; dessa processer kommunicerar asynkront med hjälp av meddelandekö.

Äganderätt

Programvaran för meddelandekön kan vara antingen proprietär, öppen källkod eller en blandning av båda. Den körs sedan antingen lokalt på privata servrar eller på externa molnservrar ( meddelandekötjänst) .

Exempel på leverantörer av hårdvarubaserade meddelandeprogram är Solace , Apigee och IBM MQ .

Användande

I en typisk implementering av meddelandeköer installerar och konfigurerar en systemadministratör meddelandeköprogramvara (en köhanterare eller mäklare) och definierar en namngiven meddelandekö. Eller så registrerar de sig hos en meddelandekötjänst .

En applikation registrerar sedan en mjukvarurutin som "lyssnar" efter meddelanden som placeras i kön.

Andra och efterföljande applikationer kan ansluta till kön och överföra ett meddelande till den.

Mjukvaran för köhanteraren lagrar meddelandena tills en mottagande applikation ansluter och anropar sedan den registrerade mjukvarurutinen. Den mottagande ansökan behandlar sedan meddelandet på ett lämpligt sätt.

Det finns ofta många alternativ för den exakta semantiken för meddelandeöverföring, inklusive:

  • Hållbarhet – meddelanden kan förvaras i minnet, skrivas till disk eller till och med överföras till ett DBMS om behovet av tillförlitlighet indikerar en mer resurskrävande lösning.
  • Säkerhetspolicyer – vilka applikationer ska ha tillgång till dessa meddelanden?
  • Policyer för rensning av meddelanden – köer eller meddelanden kan ha en " tid att leva "
  • Meddelandefiltrering – vissa system stöder filtrering av data så att en prenumerant bara kan se meddelanden som matchar vissa fördefinierade kriterier av intresse
  • Leveranspolicyer – måste vi garantera att ett meddelande levereras minst en gång eller inte mer än en gång?
  • Routingpolicyer – i ett system med många köservrar, vilka servrar ska ta emot ett meddelande eller en kös meddelanden?
  • Batchingpolicyer – ska meddelanden levereras omedelbart? Eller ska systemet vänta lite och försöka leverera många meddelanden samtidigt?
  • Kökriterier – när ska ett meddelande betraktas som "köat"? När en kö har det? Eller när den har vidarebefordrats till minst en fjärrkö? Eller till alla köer?
  • Avisering om kvitto – En utgivare kan behöva veta när några eller alla prenumeranter har fått ett meddelande.

Dessa är alla överväganden som kan ha betydande effekter på transaktionssemantik, systemtillförlitlighet och systemeffektivitet.

Standarder och protokoll

Historiskt sett har meddelandeköer använt proprietära, slutna protokoll, vilket begränsar möjligheten för olika operativsystem eller programmeringsspråk att interagera i en heterogen uppsättning miljöer.

Ett tidigt försök att göra meddelandeköer mer allmänt förekommande var Sun Microsystems JMS - specifikation, som gav en Java -abstraktion av ett klient- API . Detta gjorde det möjligt för Java-utvecklare att byta mellan leverantörer av meddelandeköer på ett sätt som liknar det för utvecklare som använder SQL- databaser. I praktiken, med tanke på mångfalden av meddelandekötekniker och scenarier, var detta inte alltid så praktiskt som det kunde vara.

Tre standarder har dykt upp som används i implementeringar av meddelandeköer med öppen källkod:

  1. Advanced Message Queuing Protocol (AMQP) – funktionsrikt meddelandeköprotokoll, godkänt som ISO/IEC 19464 sedan april 2014
  2. Streaming Text Oriented Messaging Protocol (STOMP) – enkelt, textorienterat meddelandeprotokoll
  3. MQTT (tidigare MQ Telemetry Transport) – lättviktigt meddelandeköprotokoll speciellt för inbäddade enheter

Dessa protokoll befinner sig i olika stadier av standardisering och antagande. De två första fungerar på samma nivå som HTTP , MQTT på nivån TCP/IP .

använder även HTTP för att tillhandahålla meddelandeköer av vissa implementeringar, såsom Amazons SQS . Detta beror på att det alltid är möjligt att lagra asynkront beteende (vilket är vad som krävs för meddelandekö) över ett synkront protokoll med hjälp av begäran-svar-semantik. Sådana implementeringar är dock begränsade av det underliggande protokollet i detta fall och kanske inte kan erbjuda den fullständiga troheten eller uppsättningen av alternativ som krävs i meddelandet som skickas ovan.

Synkron vs. asynkron

Många av de mer allmänt kända kommunikationsprotokollen som används fungerar synkront . HTTP-protokollet – som används på World Wide Web och i webbtjänster – är ett uppenbart exempel där en användare skickar en begäran om en webbsida och sedan väntar på ett svar.

Det finns dock scenarier där synkront beteende inte är lämpligt. Till exempel AJAX ( Asynchronous JavaScript and XML ) användas för att asynkront skicka text-, JSON- eller XML-meddelanden för att uppdatera en del av en webbsida med mer relevant information. Google använder detta tillvägagångssätt för sin Google Suggest, en sökfunktion som skickar användarens delvis inskrivna frågor till Googles servrar och returnerar en lista över möjliga fullständiga frågor som användaren kan vara intresserad av att skriva. Denna lista uppdateras asynkront när användaren skriver.

Andra asynkrona exempel finns i händelseaviseringssystem och system för publicering/prenumeration .

  • En ansökan kan behöva meddela en annan att en händelse har inträffat, men behöver inte vänta på svar.
  • I system för publicering/prenumeration "publicerar" en applikation information för hur många kunder som helst att läsa.

I båda ovanstående exempel skulle det inte vara meningsfullt att avsändaren av informationen skulle behöva vänta om till exempel en av mottagarna hade kraschat.

Applikationer behöver inte vara uteslutande synkrona eller asynkrona. En interaktiv applikation kan behöva svara på vissa delar av en förfrågan omedelbart (som att berätta för en kund att en försäljningsförfrågan har accepterats och hantera löftet om att dra på lager), men kan ställa andra delar i kö (som att slutföra beräkning av fakturering , vidarebefordra data till det centrala redovisningssystemet och anlita alla möjliga andra tjänster) för att göras en tid senare.

I alla dessa typer av situationer kan ett delsystem som utför meddelandeköning (eller alternativt ett broadcast-meddelandesystem) hjälpa till att förbättra det övergripande systemets beteende.

Implementering i UNIX

Det finns två vanliga implementeringar av meddelandeköer i UNIX . Den ena är en del av SYS V API, den andra är en del av POSIX .

SYS V

UNIX SYS V implementerar meddelandeförmedling genom att behålla en uppsättning länkade listor som meddelandeköer. Varje meddelandekö identifieras av sitt index i arrayen och har en unik deskriptor. Ett givet index kan ha flera möjliga deskriptorer. UNIX ger standardfunktioner för att komma åt funktionen för att skicka meddelanden.

msgget()
Detta systemanrop tar en nyckel som ett argument och returnerar en deskriptor av kön med den matchande nyckeln om den finns. Om den inte finns och IPC_CREAT -flaggan är satt, skapar den en ny meddelandekö med den givna nyckeln och returnerar dess deskriptor.
msgrcv()
Används för att ta emot ett meddelande från en given köbeskrivning. Den som ringer måste ha läsbehörighet för kön. Det är av två typer.
  • Blockering av mottagning sätter barnet i sömn om det inte kan hitta en begärd meddelandetyp. Den sover tills ett annat meddelande postas i kön, och vaknar sedan för att kolla igen.
  • Icke-blockerande tar emot returer omedelbart till den som ringer, och nämner att det misslyckades.
msgctl()
Används för att ändra meddelandeköparametrar som ägaren. Det viktigaste är att den används för att ta bort meddelandekön genom att skicka flaggan IPC_RMID . En meddelandekö kan endast tas bort av dess skapare, ägare eller superanvändare.

POSIX

POSIX.1-2001 meddelandekö API är det senare av de två UNIX meddelandekö API:erna. Det skiljer sig från SYS V API, men har liknande funktion. Unix-mansidan mq_overview(7) ger en översikt över POSIX-meddelandeköer.

Grafiska användargränssnitt

Grafiska användargränssnitt (GUI) använder en meddelandekö, även kallad en händelsekö eller ingångskö , för att skicka grafiska inmatningsåtgärder , såsom musklick , tangentbordshändelser eller andra användarinmatningar, till applikationsprogrammet . Fönstersystemet placerar meddelanden som indikerar användare eller andra händelser, såsom timertickar eller meddelanden skickade av andra trådar, i meddelandekön. GUI-applikationen tar bort dessa händelser en i taget genom att anropa en rutin som heter getNextEvent() eller liknande i en händelseloop , och sedan anropa lämplig applikationsrutin för att bearbeta den händelsen.

Se även

Hämtad från " https://en.wikipedia.org/w/index.php?title=Message_queue&oldid=1136636808 "