Översikt över köer
I det här avsnittet beskrivs de allmänna och grundläggande begreppen bakom köad kommunikation. Efterföljande avsnitt går in på information om hur de köbegrepp som beskrivs här visas i Windows Communication Foundation (WCF).
Grundläggande köbegrepp
När du utformar ett distribuerat program är det viktigt att välja rätt transport för kommunikation mellan tjänster och klienter. Flera faktorer påverkar vilken typ av transport som ska användas. En viktig faktor – isolering mellan tjänsten, klienten och transporten – avgör användningen av en köad transport eller en direkttransport, till exempel TCP eller HTTP. På grund av typen av direkta transporter som TCP och HTTP stoppas kommunikationen helt om tjänsten eller klienten slutar fungera eller om nätverket misslyckas. Tjänsten, klienten och nätverket måste köras samtidigt för att programmet ska fungera. Köade transporter ger isolering, vilket innebär att om tjänsten eller klienten misslyckas eller om kommunikationslänkarna mellan dem misslyckas kan klienten och tjänsten fortsätta att fungera.
Köer ger tillförlitlig kommunikation även med fel i de kommunicerande parterna eller nätverket. Köer samlar in och levererar meddelanden som utbyts mellan de kommunicerande parterna. Köer backas vanligtvis upp av någon form av butik, som kan vara flyktig eller beständig. Köer lagrar meddelanden från en klient för en tjänsts räkning och vidarebefordrar senare dessa meddelanden till tjänsten. Indirekta köer säkerställer isolering av fel av någon part, vilket gör det till den föredragna kommunikationsmekanismen för system med hög tillgänglighet och frånkopplade tjänster. Indirekta kommer med kostnaden för hög svarstid. Svarstiden är tidsfördröjningen mellan den tid då klienten skickar ett meddelande och den tid då tjänsten tar emot det. Det innebär att när ett meddelande har skickats vet du inte när meddelandet kan bearbetas. De flesta köade program klarar av långa svarstider. Följande bild visar en konceptuell modell för köad kommunikation.
Konceptuell modell för kommunikation i kö
I verkligheten är kön ett distribuerat begrepp. Därför kan de vara lokala för båda parter eller fjärranslutna till båda parter. Vanligtvis är kön lokal för tjänsten. I den här konfigurationen kan klienten inte vara beroende av att anslutningen till fjärrkön är ständigt tillgänglig. På samma sätt måste kön vara tillgänglig oberoende av tillgängligheten för tjänstens läsning från kön. En köhanterare hanterar en samling köer. Den ansvarar för att acceptera meddelanden som skickas till dess köer från andra köhanterare. Det ansvarar också för att hantera anslutningar till fjärrköer och överföra meddelanden till dessa fjärrköer. För att säkerställa tillgängligheten för köer trots klient- eller tjänstprogramfel körs köhanteraren vanligtvis som en extern tjänst.
När en klient skickar ett meddelande till en kö adresseras meddelandet till målkön, som är kön som hanteras av tjänstens köhanterare. Köhanteraren på klienten skickar meddelandet till en överföringskö (eller utgående). Överföringskö är en kö i klientköhanteraren som lagrar meddelanden för överföring till målkön. Köhanteraren hittar sedan en sökväg till köhanteraren som äger målkön och överför meddelandet till den. För att säkerställa tillförlitlig kommunikation implementerar köcheferna ett tillförlitligt överföringsprotokoll för att förhindra dataförlust. Målköhanteraren accepterar meddelanden som är adresserade till de målköer som den äger och lagrar meddelandena. Tjänsten skickar begäranden om att läsa från målkön, då köhanteraren sedan levererar meddelandet till målprogrammet. Följande bild visar kommunikationen mellan de fyra parterna.
Köad kommunikation i ett typiskt distributionsscenario
Köhanteraren tillhandahåller därför den isolering som krävs så att avsändaren och mottagaren kan misslyckas oberoende av varandra utan att den faktiska kommunikationen påverkas. Fördelen med extra indirektion som köer ger gör det också möjligt för flera programinstanser att läsa från samma kö, så att jordbruksarbete mellan noderna uppnår högre dataflöde. Därför är det inte ovanligt att köer används för att uppnå högre skalnings- och dataflödeskrav.
Köer och transaktioner
Med transaktioner kan du gruppera en uppsättning åtgärder så att om en åtgärd misslyckas misslyckas alla åtgärder. Ett exempel på hur du använder transaktioner är när en person använder en bankomat för att överföra 1 000 USD från sitt sparkonto till sitt checkkonto. Detta innebär följande åtgärder:
Tar ut 1 000 dollar från sparkontot.
Sätter in 1 000 dollar på checkkontot.
Om den första åtgärden lyckas och 1 000 USD tas ut från sparkontot, men den andra åtgärden misslyckas, går 1 000 USD förlorade eftersom de redan har dragits tillbaka från sparkontot. Om en åtgärd misslyckas måste båda åtgärderna misslyckas för att hålla kontona i ett giltigt tillstånd.
I transaktionsmeddelanden kan meddelanden skickas till kön och tas emot från kön under en transaktion. Om ett meddelande skickas i en transaktion och transaktionen återställs är resultatet alltså som om meddelandet aldrig hade skickats till kön. På samma sätt, om ett meddelande tas emot i en transaktion och transaktionen återställs, blir resultatet som om meddelandet aldrig hade tagits emot. Meddelandet finns kvar i kön som ska läsas.
På grund av långa svarstider kan du inte veta hur lång tid det tar att nå målkön när du skickar ett meddelande, och du vet inte heller hur lång tid det tar för tjänsten att bearbeta meddelandet. Därför vill du inte använda en enda transaktion för att skicka meddelandet, ta emot meddelandet och sedan bearbeta meddelandet. Detta skapar en transaktion som inte har checkats in under en obestämd tid. När en klient och tjänst kommunicerar via en kö med hjälp av en transaktion är två transaktioner inblandade: en på klienten och en i tjänsten. Följande bild visar transaktionsgränserna i vanlig kökommunikation.
Kommunikation i kö som visar separata transaktioner för avbildning och leverans
Klientens transaktion bearbetar och skickar meddelandet. När transaktionen har checkats in finns meddelandet i överföringskö. I tjänsten läser transaktionen meddelandet från målkön, bearbetar meddelandet och genomför sedan transaktionen. Om ett fel uppstår under bearbetningen återställs meddelandet och placeras i målkön.
Asynkron kommunikation med hjälp av köer
Köer tillhandahåller ett asynkront kommunikationsmedel. Program som skickar meddelanden med köer kan inte vänta tills meddelandet tas emot och bearbetas av mottagaren på grund av långa svarstider som införts av köhanteraren. Meddelanden kan finnas kvar i kön under en mycket längre tid än det avsedda programmet. För att undvika detta kan programmet ange ett Time-To-Live-värde för meddelandet. Det här värdet anger hur länge meddelandet ska finnas kvar i överföringskö. Om det här tidsvärdet överskrids och meddelandet fortfarande inte har skickats till målkön kan meddelandet överföras till en kö med obeställbara meddelanden.
När avsändaren skickar ett meddelande innebär returen från sändningsåtgärden att meddelandet bara tog sig till överföringskö på avsändaren. Om det därför uppstår ett fel när meddelandet skulle hämtas till målkön kan det sändande programmet inte känna till det omedelbart. Om du vill notera sådana fel överförs det misslyckade meddelandet till en kö med obeställbara meddelanden.
Eventuella fel, till exempel ett meddelande som inte når målkön eller time-to-live-upphörande, måste bearbetas separat. Det är därför inte ovanligt att köade program skriver två uppsättningar logik:
Den normala klient- och tjänstlogik som används för att skicka och ta emot meddelanden.
Kompensationslogik för att hantera meddelanden från den misslyckade överföringen eller leveransen.
I följande avsnitt beskrivs dessa begrepp.
Köprogrammering med obeställbara bokstäver
Köer med obeställbara meddelanden innehåller meddelanden som av olika skäl inte kunde nå målkön. Orsakerna kan vara allt från utgångna meddelanden till anslutningsproblem som förhindrar överföring av meddelandet till målkön.
Vanligtvis kan ett program läsa meddelanden från en systemomfattande kö med obeställbara meddelanden, avgöra vad som gick fel och vidta lämpliga åtgärder, till exempel korrigera felen och skicka meddelandet igen eller anteckna det.
Programmering av Giftmeddelandekö
När ett meddelande når målkön kan tjänsten upprepade gånger misslyckas med att bearbeta meddelandet. Ett program som läser ett meddelande från kön under en transaktion och uppdaterar en databas kan till exempel hitta databasen tillfälligt frånkopplad. I det här fallet återställs transaktionen, en ny transaktion skapas och meddelandet läss om från kön. Ett andra försök kan lyckas eller misslyckas. I vissa fall, beroende på orsaken till felet, kan meddelandet upprepade gånger misslyckas med leveransen till programmet. I det här fallet anses meddelandet vara "gift". Sådana meddelanden flyttas till en giftkö som kan läsas av ett program för gifthantering.