Meddelandesessioner
Azure Service Bus-sessioner aktiverar gemensam och organiserad hantering av obundna sekvenser av relaterade meddelanden. Sessioner kan användas i fifo-mönster (first in, first out) och request-response . Den här artikeln visar hur du använder sessioner för att implementera dessa mönster när du använder Service Bus.
Kommentar
Basic-nivån av Service Bus stöder inte sessioner. Standard- och Premium-nivåerna stöder sessioner. Skillnader mellan dessa nivåer finns i Service Bus-priser.
FiFO-mönster (first-in, first out)
Använd sessioner för att förverkliga en FIFO-garanti vid bearbetning av meddelanden i Service Bus-köer eller prenumerationer. Service Bus är inte normativt när det gäller relationen mellan meddelanden och definierar inte heller en viss modell för att avgöra var en meddelandesekvens startar eller slutar.
Alla avsändare kan skapa en session när de skickar meddelanden till ett ämne eller en kö genom att ange sessions-ID-egenskapen till någon programdefinierad identifierare som är unik för sessionen. På protokollnivån AMQP 1.0 mappar det här värdet till egenskapen group-id.
I sessionsmedvetna köer eller prenumerationer uppstår sessioner när det finns minst ett meddelande med sessions-ID:t. När en session finns finns det ingen definierad tid eller API för när sessionen upphör att gälla eller försvinner. Teoretiskt sett kan ett meddelande tas emot för en session i dag, nästa meddelande om ett år och om sessions-ID:t matchar är sessionen densamma ur Service Bus-perspektivet.
Vanligtvis har dock ett program en tydlig uppfattning om var en uppsättning relaterade meddelanden startar och slutar. Service Bus anger inga specifika regler. Ditt program kan till exempel ange egenskapen Etikett för att det första meddelandet ska starta, för mellanliggande meddelanden till innehåll och för att det sista meddelandet ska avslutas. Innehållsmeddelandenas relativa position kan beräknas som det aktuella meddelandet SequenceNumber delta från startmeddelandet SequenceNumber.
Viktigt!
När sessioner är aktiverade i en kö eller en prenumeration kan klientprogrammen inte längre skicka/ta emot vanliga meddelanden. Alla meddelanden måste skickas som en del av en session (genom att ange sessions-ID: t) och tas emot genom att acceptera sessionen. Klienter kan fortfarande titta på en kö eller prenumeration som har sessioner aktiverade. Se Meddelandebläddring.
API:erna för sessioner finns på kö- och prenumerationsklienter. Det finns en imperativ modell som styr när sessioner och meddelanden tas emot och en hanterarbaserad modell som döljer komplexiteten i hanteringen av mottagningsloopen.
För exempel använder du länkar i avsnittet Nästa steg .
Sessionsfunktioner
Sessioner ger samtidig demultiplexing av interleaved meddelandeströmmar samtidigt som beställd leverans bevaras och garanteras.
En sessionsmottagare skapas av en klient som accepterar en session. När sessionen godkänns och hålls av en klient har klienten ett exklusivt lås på alla meddelanden med sessionens sessions-ID i kön eller prenumerationen. Den innehåller exklusiva lås på alla meddelanden med sessions-ID :t som kommer senare.
Låset frigörs när du anropar stängningsmetoder på mottagaren eller när låset upphör att gälla. Det finns metoder på mottagaren för att förnya låsen också. I stället kan du använda funktionen för automatisk låsförnyelse där du kan ange hur lång tid du vill fortsätta att förnya låset. Sessionslåset bör behandlas som ett exklusivt lås på en fil, vilket innebär att programmet bör stänga sessionen så snart den inte längre behöver den och/eller inte förväntar sig några ytterligare meddelanden.
När flera samtidiga mottagare hämtar från kön skickas meddelandena som hör till en viss session till den specifika mottagare som för närvarande har låset för den sessionen. Med den åtgärden är en interfolierad meddelandeström i en kö eller prenumeration helt demultiplexed till olika mottagare och dessa mottagare kan också leva på olika klientdatorer, eftersom låshanteringen sker på tjänstsidan, inuti Service Bus.
Föregående bild visar tre samtidiga sessionsmottagare. En session med SessionId = 4 har ingen aktiv, ägande klient, vilket innebär att inga meddelanden levereras från den här specifika sessionen. En session fungerar på många sätt som en underkö.
Sessionslåset som innehas av sessionsmottagaren är ett paraply för de meddelandelås som används av avskärmningsläget för peek-lock . Endast en mottagare kan ha ett lås på en session. En mottagare kan ha många meddelanden under flygning, men meddelandena tas emot i ordning. Om du överger ett meddelande kommer samma meddelande att hanteras igen med nästa mottagningsåtgärd.
Meddelandesessionstillstånd
När arbetsflöden bearbetas i storskaliga molnsystem med hög tillgänglighet måste arbetsflödeshanteraren som är associerad med en viss session kunna återställas från oväntade fel och kan återuppta delvis slutfört arbete på en annan process eller dator från den plats där arbetet började.
Sessionstillståndsanläggningen möjliggör en programdefinierad anteckning av en meddelandesession i asynkron meddelandekö, så att det registrerade bearbetningstillståndet i förhållande till den sessionen blir omedelbart tillgängligt när sessionen förvärvas av en ny processor.
Från Service Bus-perspektivet är meddelandesessionstillståndet ett täckande binärt objekt som kan innehålla data av storleken på ett meddelande, vilket är 256 KB för Service Bus Standard och 100 MB för Service Bus Premium. Bearbetningstillståndet i förhållande till en session kan hållas i sessionstillståndet, eller så kan sessionstillståndet peka på någon lagringsplats eller databaspost som innehåller sådan information.
Metoderna för att hantera sessionstillstånd SetState och GetState, finns i objektet sessionsmottagare. En session som tidigare inte hade något sessionstillstånd returnerar en null-referens för GetState. Det tidigare angivna sessionstillståndet kan rensas genom att skicka null till SetState metoden på mottagaren.
Sessionstillståndet förblir så länge det inte rensas (returnerar null), även om alla meddelanden i en session används.
Sessionstillståndet som finns i en kö eller i en prenumeration räknas mot den entitetens lagringskvot. När programmet är klart med en session rekommenderar vi därför att programmet rensar sitt kvarhållna tillstånd för att undvika kostnader för extern hantering.
Effekt av leveransantal
Definitionen av leveransantal per meddelande i kontexten för sessioner varierar något från definitionen i avsaknad av sessioner. Här är en tabell som sammanfattar när leveransantalet ökas.
| Scenario | Ökar meddelandets leveransantal |
|---|---|
| Sessionen godkänns, men sessionslåset upphör att gälla (på grund av tidsgränsen) | Ja |
| Sessionen godkänns, meddelandena i sessionen slutförs inte (även om de är låsta) och sessionen är stängd | Nej |
| Sessionen accepteras, meddelanden slutförs och sedan stängs sessionen uttryckligen | N/A (det är standardflödet. Här tas meddelanden bort från sessionen) |
Mönster för begärandesvar
Mönstret för begäran-svar är ett väletablerat integrationsmönster som gör det möjligt för avsändarprogrammet att skicka en begäran och ger ett sätt för mottagaren att korrekt skicka ett svar tillbaka till avsändarprogrammet. Det här mönstret behöver vanligtvis en kortlivad kö eller ett ämne för programmet att skicka svar till. I det här scenariot ger sessioner en enkel alternativ lösning med jämförbar semantik.
Flera program kan skicka sina begäranden till en enda begärandekö, med en specifik rubrikparameter inställd på att unikt identifiera avsändarprogrammet. Mottagarprogrammet kan bearbeta begäranden som kommer i kön och skicka svar i den sessionsaktiverade kön, vilket anger sessions-ID:t till den unika identifierare som avsändaren hade skickat i begärandemeddelandet. Programmet som skickade begäran kan sedan ta emot meddelanden på det specifika sessions-ID:t och bearbeta svaren korrekt.
Kommentar
Programmet som skickar de första begärandena bör känna till sessions-ID:t och använda det för att acceptera sessionen så att den session där den förväntar sig att svaret är låst. Det är en bra idé att använda ett GUID som unikt identifierar instansen av programmet som ett sessions-ID. Det bör inte finnas någon sessionshanterare eller en tidsgräns som anges på sessionsmottagaren för kön för att säkerställa att svar är tillgängliga för att låsas och bearbetas av specifika mottagare.
Sekvensering jämfört med sessioner
Sekvensnummer i sig garanterar köordningen och extraheringsordningen för meddelanden, men inte bearbetningsordningen, vilket kräver sessioner.
Anta att det finns tre meddelanden i kön och två konsumenter.
- Konsument 1 hämtar meddelande 1.
- Konsument 2 hämtar meddelande 2.
- Konsument 2 slutför bearbetningen av meddelande 2 och hämtar meddelande 3, medan Konsument 1 inte är klar med bearbetning av meddelande 1 ännu.
- Konsument 2 slutför bearbetningen av meddelande 3, men konsument 1 är fortfarande inte klar med bearbetning av meddelande 1 ännu.
- Slutligen slutför konsument 1 bearbetningsmeddelande 1.
Därför bearbetas meddelandena i den här ordningen: meddelande 2, meddelande 3 och meddelande 1. Om du behöver meddelande 1, 2 och 3 för att bearbetas i ordning måste du använda sessioner.
Om meddelanden bara behöver hämtas i ordning behöver du inte använda sessioner. Om meddelanden behöver bearbetas i ordning använder du sessioner. Samma sessions-ID ska anges för meddelanden som hör ihop, vilket kan vara meddelande 1, 4 och 8 i en uppsättning, och 2, 3 och 6 i en annan uppsättning.
Förfallodatum för meddelande
För sessionsaktiverade köer eller ämnens prenumerationer låses meddelanden på sessionsnivå. Om time-to-live (TTL) för något av meddelandena upphör att gälla, tas alla meddelanden som är relaterade till sessionen antingen bort eller med obeställbara bokstäver baserat på den obeställbara inställningen för meddelandeförfallotid på entiteten. Med andra ord, om det finns ett enda meddelande i sessionen som har passerat TTL har alla meddelanden i sessionen upphört att gälla. Meddelandena upphör bara att gälla om det finns en aktiv lyssnare. Mer information finns i Meddelande förfallodatum.
Nästa steg
Du kan aktivera meddelandesessioner när du skapar en kö med Hjälp av Azure-portalen, PowerShell, CLI, Resource Manager-mall, .NET, Java, Python och JavaScript. Mer information finns i Aktivera meddelandesessioner.
Prova exemplen på det språk du väljer för att utforska Azure Service Bus-funktioner.
- .NET
- Java
- Python
- JavaScript