Berichtsessies
Azure Service Bus-sessies maken gezamenlijke en geordende verwerking van niet-gekoppelde reeksen gerelateerde berichten mogelijk. Sessies kunnen worden gebruikt in eerste in, first out (FIFO) en aanvraag-responspatronen . In dit artikel wordt beschreven hoe u sessies gebruikt om deze patronen te implementeren bij het gebruik van Service Bus.
Notitie
De basislaag van Service Bus biedt geen ondersteuning voor sessies. De lagen Standard en Premium bieden ondersteuning voor sessies. Zie Service Bus-prijzen voor verschillen tussen deze lagen.
FiFO-patroon (First-In, First Out)
Gebruik sessies om een FIFO-garantie te realiseren bij het verwerken van berichten in Service Bus-wachtrijen of -abonnementen. 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 in een onderwerp of wachtrij door de eigenschap sessie-id in te stellen op een door de toepassing gedefinieerde id die uniek is voor de sessie. Op het niveau van het AMQP 1.0-protocol wordt deze waarde toegewezen aan de eigenschap groeps-id .
Bij sessiebewuste wachtrijen of abonnementen komen sessies tot stand wanneer er ten minste één bericht is met de sessie-id. Zodra er 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 in de tijd van een jaar en als de sessie-id overeenkomt, is de sessie hetzelfde vanuit het perspectief van Service Bus.
Normaal gesproken heeft een toepassing echter een duidelijk idee van waar een set gerelateerde berichten begint en eindigt. Service Bus stelt geen specifieke regels in. Uw toepassing kan bijvoorbeeld de eigenschap Label instellen voor het eerste bericht dat moet worden gestart, voor tussenliggende berichten naar inhoud en voor het laatste bericht dat moet worden beëindigd. De relatieve positie van de inhoudsberichten kan worden berekend als de huidige delta van het bericht SequenceNumber van het beginbericht SequenceNumber.
Belangrijk
Wanneer sessies zijn ingeschakeld in een wachtrij of een abonnement, kunnen de clienttoepassingen geen normale 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. Clients kunnen nog steeds een wachtrij of abonnement bekijken waarvoor sessies zijn ingeschakeld. Bekijk het bladeren door berichten.
De API's voor sessies bestaan op wachtrij- en abonnementsclients. Er is een imperatief model dat bepaalt wanneer sessies en berichten worden ontvangen en een handlermodel dat de complexiteit van het beheren van de ontvangstlus verbergt.
Gebruik voor voorbeelden koppelingen in de sectie Volgende stappen .
Sessiefuncties
Sessies bieden gelijktijdige demultiplexing van interleaved berichtstreams, met behoud en garantie voor bestelde levering.
Een sessieontvanger wordt gemaakt door een client die een sessie accepteert. Wanneer de sessie wordt geaccepteerd en 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 exclusieve vergrendelingen voor alle berichten met de sessie-id die later aankomt.
De vergrendeling wordt vrijgegeven wanneer u methoden voor sluiten aanroept op de ontvanger of wanneer de vergrendeling verloopt. Er zijn methoden op de ontvanger om ook de vergrendelingen te vernieuwen. In plaats daarvan kunt u de functie voor automatische verlenging van vergrendeling gebruiken, waarin u de tijdsduur kunt opgeven waarvoor u de vergrendeling wilt verlengen. De sessievergrendeling moet worden behandeld als een exclusieve vergrendeling op 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 worden gehaald, worden de berichten die behoren tot een bepaalde sessie verzonden naar de specifieke ontvanger die momenteel de vergrendeling voor die sessie bevat. Met deze bewerking wordt een interleaved berichtenstroom in één wachtrij of abonnement schoon gedemultiplexeerd naar verschillende ontvangers en kunnen deze ontvangers ook live op verschillende clientcomputers, omdat het vergrendelingsbeheer plaatsvindt aan de servicezijde, in Service Bus.
In de vorige afbeelding ziet u drie gelijktijdige sessieontvangers. Eén sessie met SessionId = 4 heeft geen actieve client die eigenaar is, wat betekent dat er geen berichten worden bezorgd van deze specifieke sessie. Een sessie fungeert op veel manieren als een subwachtrij.
De sessievergrendeling die door de sessieontvanger wordt gehouden, is een paraplu voor de berichtvergrendelingen die worden gebruikt door de modus voor het vergrendelen van peek-lock . Slechts één ontvanger kan een vergrendeling op een sessie hebben. Een ontvanger kan veel in-flight-berichten hebben, maar de berichten worden op volgorde ontvangen. Als u een bericht afgeeft, wordt hetzelfde bericht opnieuw geleverd met de volgende ontvangstbewerking.
Status van berichtsessie
Wanneer werkstromen worden verwerkt in grootschalige cloudsystemen met hoge beschikbaarheid, moet de werkstroomhandler die is gekoppeld aan een bepaalde sessie, kunnen herstellen van onverwachte fouten en kan het gedeeltelijk voltooide werk op een ander proces of op een andere computer hervatten vanaf waar het werk is begonnen.
De sessiestatusfaciliteit maakt een door de toepassing gedefinieerde aantekening van een berichtsessie binnen de broker mogelijk, zodat de vastgelegde verwerkingsstatus ten opzichte van die sessie direct beschikbaar wordt wanneer de sessie wordt verkregen door een nieuwe processor.
Vanuit het perspectief van Service Bus is de status van de berichtsessie een ondoorzichtig binair object dat gegevens kan bevatten van de grootte van één bericht, wat 256 KB voor Service Bus Standard is en 100 MB voor Service Bus Premium. De verwerkingsstatus ten opzichte van een sessie kan binnen de sessiestatus worden gehouden, of de sessiestatus kan verwijzen naar een bepaalde opslaglocatie of databaserecord die dergelijke informatie bevat.
De methoden voor het beheren van de sessiestatus SetState en GetState, vindt u op het object sessieontvanger. Een sessie die eerder geen sessiestatus had, retourneert een null-verwijzing voor GetState. De eerder ingestelde sessiestatus kan worden gewist door null door te geven aan de SetState methode op de ontvanger.
Sessiestatus blijft zolang deze niet wordt gewist (null retourneert), zelfs als alle berichten in een sessie worden verbruikt.
De sessiestatus 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 voor de toepassing om de bewaarde status op te schonen om kosten voor extern beheer te voorkomen.
Impact van het aantal bezorgingen
De definitie van het aantal bezorgingen per bericht in de context van sessies varieert enigszins van de definitie bij afwezigheid van sessies. Hier volgt een tabel met een samenvatting wanneer het aantal bezorgingen wordt verhoogd.
| Scenario | Is het aantal bezorgingen van het bericht verhoogd |
|---|---|
| Sessie wordt geaccepteerd, maar de sessievergrendeling verloopt (vanwege time-out) | Ja |
| Sessie wordt geaccepteerd, de berichten in de sessie worden niet voltooid (zelfs niet als ze zijn vergrendeld) en de sessie wordt gesloten | Nee |
| Sessie wordt geaccepteerd, berichten zijn voltooid en vervolgens wordt de sessie expliciet gesloten | N.v.v. (dit is de standaardstroom. Hier worden berichten verwijderd uit de sessie) |
Patroon aanvraag-antwoord
Het aanvraag-antwoordpatroon is een vast 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 wachtrij of onderwerp met een korte levensduur nodig voor de toepassing om antwoorden naar te verzenden. In dit scenario bieden sessies een eenvoudige alternatieve oplossing met vergelijkbare semantiek.
Meerdere toepassingen kunnen hun aanvragen verzenden naar één aanvraagwachtrij, waarbij een specifieke headerparameter is ingesteld om de afzendertoepassing uniek te identificeren. De ontvangertoepassing kan de aanvragen in de wachtrij verwerken en antwoorden verzenden in de wachtrij waarvoor de sessie is ingeschakeld, waarbij de sessie-id wordt ingesteld op de unieke id die de afzender heeft verzonden op het aanvraagbericht. De toepassing die de aanvraag heeft verzonden, kan vervolgens berichten ontvangen over de specifieke sessie-id en de antwoorden correct verwerken.
Notitie
De toepassing die de eerste aanvragen verzendt, moet weten over de sessie-id 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 waarmee het exemplaar van de toepassing uniek wordt geïdentificeerd als een sessie-id. Er mag geen sessiehandler of een time-out zijn opgegeven op de sessieontvanger voor de wachtrij om ervoor te zorgen dat antwoorden beschikbaar zijn om te worden vergrendeld en verwerkt door specifieke ontvangers.
Sequencing versus sessies
Volgnummer op zichzelf garandeert de wachtrijvolgorde en de extractievolgorde van berichten, maar niet de verwerkingsvolgorde, waarvoor sessies zijn vereist.
Stel dat er drie berichten in de wachtrij staan en twee consumenten.
- Consument 1 haalt bericht 1 op.
- Consument 2 haalt bericht 2 op.
- Consumer 2 voltooit het verwerken van bericht 2 en haalt bericht 3 op, terwijl Consumer 1 nog niet klaar is met het verwerken van bericht 1.
- Consumer 2 voltooit het verwerken van bericht 3, maar consument 1 is nog niet klaar met het verwerken van bericht 1.
- Ten slotte voltooit consumer 1 het verwerken van bericht 1.
De berichten worden dus in deze volgorde verwerkt: bericht 2, bericht 3 en bericht 1. Als u bericht 1, 2 en 3 in volgorde wilt verwerken, moet u sessies gebruiken.
Als berichten alleen op volgorde moeten worden opgehaald, hoeft u geen sessies te gebruiken. Als berichten op volgorde moeten worden verwerkt, gebruikt u sessies. Dezelfde sessie-id moet worden ingesteld voor berichten die bij elkaar horen, wat bericht 1, 4 en 8 in een set kan zijn, en 2, 3 en 6 in een andere set.
Verlooptijd van bericht
Voor wachtrijen of abonnementen op sessieniveau worden berichten vergrendeld op sessieniveau. Als de time-to-live (TTL) voor een van de berichten verloopt, worden alle berichten met betrekking tot die sessie verwijderd of niet-geschreven op basis van de optie voor verlopen berichten die is ingeschakeld voor de verloopinstelling voor berichten op de entiteit. Met andere woorden, als er één bericht is in de sessie die de TTL heeft doorgegeven, worden alle berichten in de sessie verlopen. De berichten verlopen alleen als er een actieve listener is. Zie Verlooptijd van bericht voor meer informatie.
Volgende stappen
U kunt berichtsessies inschakelen tijdens het maken van een wachtrij met behulp van Azure Portal, PowerShell, CLI, Resource Manager-sjabloon, .NET, Java, Python en JavaScript. Zie Berichtensessies inschakelen voor meer informatie.
Probeer de voorbeelden in de taal van uw keuze om Azure Service Bus-functies te verkennen.
- .NET
- Java
- Python
- JavaScript