Dela via

Meddelandesessioner

Azure Service Bus-sessioner tillåter gemensam och ordnad bearbetning 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.

Anmärkning

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.

Först in, först ut-mönster

Använd sessioner för att uppnå FIFO-bearbetning i bearbetning av meddelanden från 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.

En avsändare kan initiera en session när meddelanden skickas till ett ämne eller en kö genom att ange sessions-ID-egenskapen till unik identifierare som definierats av programmet. 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.

Normalt definierar dock ett program var en uppsättning relaterade meddelanden startar och slutar. Service Bus tillämpar inga specifika regler. Ditt program kan till exempel ange egenskapen Etikett för det första meddelandet som start, för mellanliggande meddelanden som 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 startmeddelandetSequenceNumber.

Viktigt!

När sessioner är aktiverade i en kö eller en prenumeration kan klientprogrammen inte längre skicka/ta emot vanliga meddelanden. Klienter måste skicka meddelanden som en del av en session genom att ange sessions-ID och tas emot genom att acceptera sessionen. Klienter kan fortfarande granska en kö eller prenumeration som har sessioner aktiverade. Se Meddelandebläddring.

API:erna för sessioner finns på kö- och prenumerationsklienter. Det finns två sätt att ta emot sessioner och meddelanden: den imperativa modellen, där du manuellt styr när och hur meddelanden tas emot, och den hanterarbaserade modellen, vilket förenklar saker och ting genom att automatiskt hantera meddelandeloopen och bearbetningen.

För exempel använder du länkar i avsnittet Exempel .

Sessionsfunktioner

Sessioner möjliggör samtidig demultiplexering av sammanflätade meddelandeströmmar, samtidigt som leverans i ordning bevaras och garanteras.

Diagram som visar hur sessionsfunktionen bevarar en ordnad leverans.

En klient skapar en sessionsmottagare för att acceptera en session. När klienten accepterar och håller en session 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 interleaverad meddelandeström i en kö eller prenumeration helt demultiplexerad till olika mottagare och dessa mottagare kan också finnas på olika klientdatorer, eftersom låshanteringen sker på tjänstens sida, 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 övergripande begrepp för de meddelandelås som används av peek-lock-avvecklingsläget. Endast en mottagare kan låsa 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 mäklaren, så att det registrerade bearbetningens tillstånd 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 för sessionsmottagaren. 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 till enhetens 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.

Scenarium Ökar meddelandets antal leveranser?
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.

Anmärkning

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 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.

  1. Konsument 1 hämtar meddelande 1.
  2. Konsument 2 hämtar meddelande 2.
  3. 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.
  4. Konsument 2 slutför bearbetningen av meddelande 3, men konsument 1 är fortfarande inte klar med bearbetning av meddelande 1 ännu.
  5. 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 löper ut, tas alla meddelanden relaterade till den sessionen bort eller flyttas till dödbrevkön baserat på dödbrevfunktionen aktiverad vid meddelandeförfall på själva 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. För mer information, se Meddelandets utgångsdatum.

Exempel

Du kan aktivera meddelandesessioner när du skapar en kö med hjälp av Azure-portalen, PowerShell, CLI, en 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.

Relaterat innehåll