Berichtsessies

Azure Service Bus-sessies maken gezamenlijke en geordende verwerking van niet-gebonden reeksen gerelateerde berichten mogelijk. Sessies kunnen worden gebruikt in eerste in, eerste uit (FIFO) en aanvraag-respons-patronen. In dit artikel wordt beschreven hoe u sessies gebruikt om deze patronen te implementeren bij het gebruik van Service Bus.

FIFO-patroon (First-In, First-Out)

Gebruik sessies om FIFO-verwerking te bereiken bij het verwerken van berichten uit 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.

Een afzender kan een sessie initiëren bij het verzenden van berichten in een onderwerp of wachtrij door de eigenschap sessie-id in te stellen op een unieke id die door de toepassing is gedefinieerd. 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 er vandaag een bericht worden ontvangen voor een sessie, het volgende bericht over een jaar, en als de sessie-id overeenkomt, is de sessie hetzelfde vanuit het perspectief van de Service Bus.

Meestal definieert een toepassing echter waar een set gerelateerde berichten begint en eindigt. Service Bus legt geen specifieke regels op. Uw toepassing kan bijvoorbeeld de eigenschap Label instellen voor het eerste bericht als begin, voor tussenliggende berichten als 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 beginberichtSequenceNumber.

De API's voor sessies bestaan op wachtrij- en abonnementsclients. Er zijn twee manieren om sessies en berichten te ontvangen: het imperatieve model, waar u handmatig bepaalt wanneer en hoe berichten worden ontvangen, en het model op basis van de handler, wat dingen vereenvoudigt door de berichtenlus en -verwerking automatisch te beheren.

Gebruik voor voorbeelden koppelingen in de sectie Voorbeelden .

Sessiekenmerken

Sessies bieden gelijktijdige demultiplexing van interleaved berichtstreams, met behoud en garantie voor bestelde levering.

Een client maakt een sessieontvanger om een sessie te accepteren. Wanneer de client een sessie accepteert en vasthoudt, 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 aankomen.

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 verstrengelde berichtenstroom in één wachtrij of abonnement helder gedemultiplexeerd naar verschillende ontvangers en kunnen deze ontvangers zich ook op verschillende clientcomputers bevinden, aangezien het vergrendelingsbeheer plaatsvindt aan de serverzijde, 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 vastgehouden, fungeert als een paraplu voor de berichtvergrendelingen die worden gebruikt door de peek-lock-vereffeningsmodus. 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, SetStateen GetState, zijn te vinden 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.

De sessiestatus blijft behouden zolang deze niet wordt gewist (teruggeeft null), zelfs als alle berichten in een sessie zijn opgebruikt.

De sessiestatus in een wachtrij of in een abonnement telt mee voor het opslagquotum van die entiteit. Wanneer de toepassing klaar is met een sessie, wordt het daarom aanbevolen voor de toepassing om de bewaarde status op te schonen om kosten voor extern beheer te vermijden.

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.

Verzoek-antwoordpatroon

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.

Sequencing versus sessies

Volgnummer op zichzelf garandeert de wachtrijvolgorde en de extractievolgorde van berichten, maar niet de verwerkingsvolgorde, waarvoor sessies zijn vereist.

Neem aan dat er drie berichten in de wachtrij staan en twee consumenten.

1. Consument 1 haalt bericht 1 op.
2. Consument 2 haalt het tweede bericht op.
3. 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.
4. Consumer 2 voltooit het verwerken van bericht 3, maar consument 1 is nog niet klaar met het verwerken van bericht 1.
5. 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 sessiegeschikte wachtrijen of onderwerpenabonnementen worden berichten op sessieniveau vergrendeld. Als de time-to-live (TTL) voor een van de berichten verloopt, worden alle berichten die aan die sessie zijn gekoppeld, op basis van de instelling voor verlopen berichten op de entiteit, verwijderd of naar de dead-letter queue verplaatst. Met andere woorden, als er één bericht in de sessie is dat de TTL heeft overschreden, worden alle berichten in de sessie ongeldig. De berichten verlopen alleen als er een actieve listener is. Zie Verlooptijd van bericht voor meer informatie.

Voorbeelden

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
  • Sessieberichten verzenden en ontvangen
  • De sessieprocessor gebruiken
• Java
  • Berichten verzenden naar een sessie
  • Berichten ontvangen van de eerste beschikbare sessie
  • Berichten ontvangen van een specifieke sessie
  • Alle sessieberichten verwerken met behulp van een processor
• Python
  • Berichten verzenden en ontvangen van een wachtrij waarvoor een sessie is ingeschakeld
  • Berichten ontvangen van meerdere beschikbare sessies parallel met een threadpool
• JavaScript
  • Berichten verzenden naar en ontvangen van wachtrijen of abonnementen waarvoor een sessie is ingeschakeld
  • Voortdurend alle beschikbare sessies doorlezen
  • Sessiestatus gebruiken

Verwante inhoud

• Een blogbericht waarin technieken worden beschreven voor het opnieuw ordenen van berichten die niet in orde zijn