Meddelandesessioner

Azure Service Bus-sessioner möjliggör gemensam och ordnad hantering av obundna sekvenser av relaterade meddelanden. Sessioner kan användas i först in, först ut (FIFO) och begäran-svar-mönster. Den här artikeln visar hur du använder sessioner för att implementera dessa mönster när du använder Service Bus.

Fifo-mönster (först in, först ut)

Om du vill realisera en FIFO-garanti Service Bus kan du använda sessioner. Service Bus är inte normativt om typen av relation 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 meddelanden skickas till ett ämne eller en kö genom att ange egenskapen sessions-ID till en 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 finns 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 idag, nästa meddelande om ett år, och om sessions-ID:t matchar är sessionen densamma ur ett Service Bus perspektiv.

Vanligtvis har dock ett program en tydlig uppfattning om var en uppsättning relaterade meddelanden börjar och slutar. Service Bus anger inga specifika regler. Programmet kan till exempel ange egenskapen Etikett för det första meddelandet till att starta , för mellanliggande meddelanden till innehåll och för att det sista meddelandet ska avsluta. Den relativa positionen för innehållsmeddelanden kan beräknas som det aktuella meddelandet SequenceNumber delta från startmeddelandet SequenceNumber.

API:erna för sessioner finns i 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 med att hantera mottagningsloopen.

För exempel använder du länkar i avsnittet Nästa steg.

Sessionsfunktioner

Sessioner ger samtidig de-multiplexering av överbevarande meddelandeströmmar samtidigt som den beställda leveransen bevaras och garanterars.

En sessionsmottagare skapas av en klient som accepterar en session. När sessionen accepteras och hålls av en klient, har klienten ett exklusivt lås för alla meddelanden med sessionens sessions-ID i kön eller prenumerationen. Den kommer också att innehålla exklusiva lås för alla meddelanden med sessions-ID:t som kommer senare.

Låset släpps 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änge 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 meddelanden 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 de-multiplexeras en sammanflätad meddelandeström i en kö eller prenumeration till olika mottagare, och dessa mottagare kan också vara live på olika klientdatorer, eftersom låshanteringen sker på tjänstsidan i Service Bus.

Föregående bild visar tre samtidiga sessionsmottagare. En session med SessionId = 4 har ingen aktiv, äger 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 sessionsmottagaren har är ett samlingsparaply för de meddelandelås som används av peek-lock-likvidläget. Endast en mottagare kan ha ett lås för en session. En mottagare kan ha många flygmeddelanden, men meddelandena tas emot i ordning. Om du lämnar ett meddelande ser du samma meddelande 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 där arbetet började.

Funktionen för sessionstillstånd möjliggör en programdefinierad anteckning av en meddelandesession i 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.

Ur Service Bus perspektiv är meddelandesessionens tillstånd ett täckande binärt objekt som kan innehålla data med 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å en lagringsplats eller databaspost som innehåller sådan information.

Metoderna för att hantera sessionstillståndet SetState och GetState finns i sessionsmottagareobjektet. En session som tidigare inte hade något sessionstillstånd returnerar en null-referens för GetState. Du kan rensa det tidigare inställda sessionstillståndet genom att skicka null till metoden SetState på mottagaren.

Sessionstillståndet förblir så länge det inte rensas (null returneras), även om alla meddelanden i en session förbrukas.

Sessionstillståndet som finns i en kö eller i en prenumeration räknas mot 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 externa hanteringskostnader.

Påverkan av leveransantal

Definitionen av antal leveranser per meddelande i sessionssammanhang varierar något från definitionen i avsaknad av sessioner. Här är en tabell som sammanfattar när antalet leveranser ökar.

Mönster för begäran-svar

Mönstret för begäran/svar är ett väletablerat integrationsmönster som gör att avsändarprogrammet kan skicka en begäran och ger ett sätt för mottagaren att skicka ett svar tillbaka till avsändarprogrammet på rätt sätt. Det här mönstret behöver vanligtvis en kortlivad kö eller ett ämne som programmet kan skicka svar till. I det här scenariot tillhandahåller 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, och ange sessions-ID:t till den unika identifierare som avsändaren skickade i begärandemeddelandet. Programmet som skickade begäran kan sedan ta emot meddelanden om det specifika sessions-ID:t och bearbeta svaren korrekt.

Nästa steg

Du kan aktivera meddelandesessioner när du skapar en kö med Azure Portal, 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.

• Azure Service Bus-klientbiblioteksexempel för .NET (senaste)
• Exempel Service Bus Azure-klientbibliotek för Java (senaste)
• Exempel Service Bus Azure-klientbibliotek för Python
• Exempel Service Bus Azure-klientbibliotek för JavaScript
• Exempel Service Bus Azure-klientbibliotek för TypeScript

Hitta exempel för äldre .NET- och Java-klientbibliotek nedan:

• Exempel Service Bus Azure-klientbibliotek för .NET (äldre)
• Exempel Service Bus Azure-klientbibliotek för Java (äldre)