Berichtsessies
Azure Service Bus maken gezamenlijke en geordende verwerking van niet-gebonden reeksen gerelateerde berichten mogelijk. Sessies kunnen worden gebruikt in de patronen first in, first out (FIFO) en request-response. In dit artikel wordt beschreven hoe u sessies gebruikt om deze patronen te implementeren bij het gebruik Service Bus.
Notitie
De basislaag van Service Bus biedt geen ondersteuning voor sessies. De lagen Standard en Premium ondersteunen sessies. Zie Prijzen voor Service Bus verschillen tussen deze lagen.
FIFO-patroon (First In, First Out)
Als u een FIFO-garantie wilt realiseren in Service Bus, gebruikt u sessies. Service Bus is niet prescriptief over de aard van de relatie tussen berichten en definieert ook geen bepaald model om te bepalen waar een berichtenreeks begint of eindigt.
Elke afzender kan een sessie maken bij het verzenden van berichten naar een onderwerp of wachtrij door de eigenschap sessie-id in te stellen op een toepassings-id die uniek is voor de sessie. Op het protocolniveau AMQP 1.0 wordt deze waarde toe te staan aan de eigenschap group-id.
Bij sessiebewuste wachtrijen of abonnementen ontstaan er sessies wanneer er ten minste één bericht met de sessie-id is. Zodra een sessie bestaat, is er geen gedefinieerde tijd of API voor wanneer de sessie verloopt of verdwijnt. Theoretisch kan een bericht worden ontvangen voor een sessie vandaag, het volgende bericht over een jaar en als de sessie-id overeenkomt, is de sessie hetzelfde vanuit het Service Bus perspectief.
Normaal gesproken heeft een toepassing echter een duidelijk beeld van waar een reeks gerelateerde berichten begint en eindigt. Service Bus stelt geen specifieke regels in. Uw toepassing kan bijvoorbeeld de eigenschap Label instellen voor het eerste bericht om te starten, voor tussenliggende berichten naar inhoud en voor het laatste bericht om te eindigen. De relatieve positie van de inhoudsberichten kan worden berekend als het huidige bericht SequenceNumber delta van het startbericht SequenceNumber.
Belangrijk
Wanneer sessies zijn ingeschakeld voor een wachtrij of een abonnement, kunnen de clienttoepassingen geen reguliere berichten meer verzenden/ontvangen. Alle berichten moeten worden verzonden als onderdeel van een sessie (door de sessie-id in te stellen) en ontvangen door de sessie te accepteren.
De API's voor sessies bestaan op wachtrij- en abonnements-clients. Er is een imperatieve model dat bepaalt wanneer sessies en berichten worden ontvangen, en een op handler gebaseerd model dat de complexiteit van het beheren van de ontvangstlus verbergt.
Gebruik voor voorbeelden koppelingen in de sectie Volgende stappen.
Sessiefuncties
Sessies bieden gelijktijdige de multiplexing van interleaved berichtstromen met behoud en garantie voor geordende levering.
Een sessieontvanger wordt gemaakt door een client die een sessie accepteert. Wanneer de sessie wordt geaccepteerd en wordt gehouden door een client, houdt de client een exclusieve vergrendeling op alle berichten met de sessie-id van die sessie in de wachtrij of het abonnement. Het bevat ook exclusieve vergrendelingen voor alle berichten met de sessie-id die later wordt ontvangen.
De vergrendeling wordt vrijgegeven wanneer u methoden voor sluiten aanroept bij de ontvanger of wanneer de vergrendeling verloopt. Er zijn ook methoden voor de ontvanger om de vergrendelingen te vernieuwen. In plaats daarvan kunt u de functie voor automatische vergrendelingsvernieuwing gebruiken, waar u de tijdsduur kunt opgeven waarvoor u de vergrendeling steeds wilt vernieuwen. De sessievergrendeling moet worden behandeld als een exclusieve vergrendeling van een bestand, wat betekent dat de toepassing de sessie moet sluiten zodra deze niet meer nodig is en/of geen verdere berichten verwacht.
Wanneer meerdere gelijktijdige ontvangers uit de wachtrij halen, worden de berichten van een bepaalde sessie verzonden naar de specifieke ontvanger die momenteel de vergrendeling voor die sessie bevat. Met deze bewerking wordt een interleavede berichtenstroom in één wachtrij of abonnement op een schone manier uit multiplexed naar verschillende ontvangers en kunnen deze ontvangers ook op verschillende clientmachines worden geplaatst, omdat het vergrendelingsbeheer aan de servicezijde gebeurt, binnen Service Bus.
In de vorige afbeelding ziet u drie gelijktijdige sessieontvangers. Eén sessie met = 4 heeft geen actieve client die eigenaar is, wat betekent dat er geen berichten SessionId worden bezorgd vanuit deze specifieke sessie. Een sessie fungeert op veel manieren als een subwachtrij.
De sessievergrendeling die door de sessieontvanger wordt vastgehouden, is een overkoepelende oplossing voor de berichtvergrendelingen die worden gebruikt door de afwikkelingsmodus peek-lock. Slechts één ontvanger kan een sessie vergrendelen. Een ontvanger kan veel in-flight-berichten hebben, maar de berichten worden op volgorde ontvangen. Het verlaten van een bericht zorgt ervoor dat hetzelfde bericht opnieuw wordt weergegeven bij de volgende ontvangstbewerking.
Status van berichtsessie
Wanneer werkstromen worden verwerkt in grootschalige cloudsystemen met hoge beschikbaarheid, moet de werkstroom-handler die aan een bepaalde sessie is gekoppeld, in staat zijn om te herstellen van onverwachte fouten en kan het gedeeltelijk voltooide werk op een ander proces of op een andere computer worden hervat vanaf het begin van het werk.
De sessietoestandfaciliteit maakt een toepassingsdefininieerde aantekening van een berichtsessie binnen de broker mogelijk, zodat de vastgelegde verwerkingstoestand ten opzichte van die sessie direct beschikbaar wordt wanneer de sessie wordt verkregen door een nieuwe processor.
Vanuit het Service Bus perspectief is de status van de berichtsessie een ondoorzichtig binair object dat gegevens van de grootte van één bericht kan bevatten. Dit is 256 kB voor Service Bus Standard en 100 MB voor Service Bus Premium. De verwerkingstoestand ten opzichte van een sessie kan binnen de sessietoestand worden gehouden, of de sessietoestand kan wijzen op een opslaglocatie of databaserecord die dergelijke informatie bevat.
De methoden voor het beheren van de sessietoestand, SetState en GetState, vindt u op het object sessieontvanger. Een sessie die eerder geen sessietoestand had, retourneert een null-verwijzing voor GetState. De eerder ingesteld sessietoestand kan worden geweerd door null door te geven aan de Methode SetState op de ontvanger.
De sessietoestand blijft zolang deze niet wordt geweerd (null wordt geretourneerd), zelfs als alle berichten in een sessie worden gebruikt.
De sessietoestand in een wachtrij of in een abonnement telt mee voor het opslagquotum van die entiteit. Wanneer de toepassing is voltooid met een sessie, wordt het daarom aanbevolen dat de toepassing de behouden status opschoont om externe beheerkosten te voorkomen.
Impact van aantal leveringen
De definitie van het aantal bezorgingen per bericht in de context van sessies verschilt enigszins van de definitie als er geen sessies zijn. Hier is een tabel waarin wordt samengevat wanneer het aantal leveringen wordt verhoogd.
| Scenario | Is het aantal leveringen van het bericht verhoogd? |
|---|---|
| Sessie wordt geaccepteerd, maar de sessievergrendeling verloopt (vanwege een time-out) | Yes |
| Sessie wordt geaccepteerd, de berichten in de sessie worden niet voltooid (zelfs als ze zijn vergrendeld) en de sessie wordt gesloten | No |
| Sessie wordt geaccepteerd, berichten worden voltooid en vervolgens wordt de sessie expliciet gesloten | N.v.t. (Dit is de standaardstroom. Hier worden berichten verwijderd uit de sessie) |
Aanvraag-antwoordpatroon
Het patroon request-reply is een goed opgezet integratiepatroon waarmee de afzendertoepassing een aanvraag kan verzenden en een manier biedt voor de ontvanger om een antwoord correct terug te sturen naar de afzendertoepassing. Dit patroon heeft doorgaans een korte wachtrij of onderwerp nodig waar de toepassing antwoorden op kan verzenden. In dit scenario bieden sessies een eenvoudige alternatieve oplossing met vergelijkbare semantiek.
Meerdere toepassingen kunnen hun aanvragen verzenden naar één aanvraagwachtrij, met een specifieke headerparameter ingesteld om de zezendertoepassing uniek te identificeren. De ontvangertoepassing kan de aanvragen verwerken die in de wachtrij komen en antwoorden verzenden op de wachtrij met sessie ingeschakeld, waarbij de sessie-id wordt instellen op de unieke id die de afzender heeft verzonden in het aanvraagbericht. De toepassing die de aanvraag heeft verzonden, kan vervolgens berichten op de specifieke sessie-id ontvangen en de antwoorden correct verwerken.
Notitie
De toepassing die de eerste aanvragen verzendt, moet de sessie-id kennen en deze gebruiken om de sessie te accepteren, zodat de sessie waarop het antwoord wordt verwacht, is vergrendeld. Het is een goed idee om een GUID te gebruiken die het exemplaar van de toepassing uniek identificeert als een sessie-id. Er mag geen sessie-handler of een time-out zijn opgegeven op de sessie-ontvanger voor de wachtrij om ervoor te zorgen dat antwoorden beschikbaar zijn om te worden vergrendeld en verwerkt door specifieke ontvangers.
Volgende stappen
U kunt berichtsessies inschakelen tijdens het maken van een wachtrij met Azure Portal, PowerShell, CLI, Resource Manager sjabloon, .NET, Java, Python en JavaScript. Zie Berichtsessies inschakelen voor meer informatie.
Probeer de voorbeelden in de taal van uw keuze om Azure Service Bus verkennen.
- Voorbeelden Service Bus Azure Service Bus-clientbibliotheek voor .NET (meest recente versie)
- Voorbeelden van Azure Service Bus-clientbibliotheek voor Java (meest recente versie)
- Voorbeelden Service Bus Azure Service Bus-clientbibliotheek voor Python
- Voorbeelden Service Bus Azure Service Bus-clientbibliotheek voor JavaScript
- Voorbeelden Service Bus Azure Service Bus-clientbibliotheek voor TypeScript
Zoek voorbeelden voor de oudere .NET- en Java-clientbibliotheken hieronder: