Berichtvolgorde en -timestamps

Sequentiëren en tijdstempels zijn twee functies die altijd zijn ingeschakeld voor alle Service Bus-entiteiten en die zichtbaar zijn via de Sequence​Number eigenschappen van EnqueuedTimeUtc ontvangen of bekeken berichten.

Voor dergelijke gevallen waarin de absolute volgorde van berichten significant is en/of waarin een consument een betrouwbare unieke id voor berichten nodig heeft, worden berichten met een tussenruimteloos, toenemend volgnummer ten opzichte van de wachtrij of het onderwerp verhoogd. Voor gepartitioneerde entiteiten wordt het volgnummer uitgegeven ten opzichte van de partitie.

Volgnummer

De sequenceNumber-waarde is een uniek 64-bits geheel getal dat is toegewezen aan een bericht omdat het wordt geaccepteerd en opgeslagen door de broker en fungeert als interne id. Voor gepartitioneerde entiteiten weerspiegelen de bovenste 16 bits de partitie-id. Volgnummers worden overgezet naar nul wanneer het 48/64-bits bereik is uitgeput.

Het volgnummer kan worden vertrouwd als een unieke id, omdat het wordt toegewezen door een centrale en neutrale instantie en niet door clients. Het vertegenwoordigt ook de werkelijke volgorde van aankomst en is nauwkeuriger dan een tijdstempel als ordercriterium, omdat tijdstempels mogelijk niet hoog genoeg resolutie hebben tegen extreme berichtsnelheden en kunnen worden onderworpen aan (nochtans minimale) klokverschil in situaties waarin het eigendom van de broker overgaat tussen knooppunten.

De absolute aankomstorder is bijvoorbeeld van belang in bedrijfsscenario's waarin een beperkt aantal aangeboden goederen worden bediend op basis van de eerste aankomst, terwijl de leveringen voor het laatst worden geleverd; concertticketverkoop is een voorbeeld.

Tijdstempel

De functie voor tijdstempels fungeert als een neutrale en betrouwbare instantie die de UTC-tijd van aankomst van een bericht nauwkeurig vastlegt, weerspiegeld in de eigenschap EnqueuedTimeUtc . De waarde is handig als een bedrijfsscenario afhankelijk is van deadlines, zoals of een werkitem vóór middernacht is ingediend, maar de verwerking zich ver achter de achterstand in de wachtrij bevindt.

Notitie

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

Stel, er zijn 5 berichten in de wachtrij en 2 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.

Dus 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 op berichten die bij elkaar horen. Dit kan bericht 1, 4 en 8 in één set zijn, en 2, 3 en 6 in een andere set.

Zie Service Bus-berichtensessies voor meer informatie.

Geplande berichten

U kunt berichten verzenden naar een wachtrij of onderwerp voor vertraagde verwerking, bijvoorbeeld om te plannen dat een taak op een bepaald moment beschikbaar komt voor verwerking door een systeem. Deze mogelijkheid realiseert een betrouwbare op tijd gebaseerde scheduler op basis van gedistribueerde tijd.

Geplande berichten worden pas in de wachtrij geplaatst als de gedefinieerde tijd in de wachtrij wordt weergegeven. Voor die tijd kunnen geplande berichten worden geannuleerd. Annulering verwijdert het bericht.

U kunt berichten op twee manieren plannen met een van onze klanten:

• Gebruik de reguliere verzend-API, maar stel de Scheduled​Enqueue​Time​Utc eigenschap voor het bericht in voordat u het verzendt.
• Gebruik de API voor planningsberichten, geef zowel het normale bericht als de geplande tijd door. De API retourneert het SequenceNumber van het geplande bericht, dat u later kunt gebruiken om het geplande bericht zo nodig te annuleren.

Geplande berichten en de bijbehorende volgnummers kunnen ook worden gedetecteerd met behulp van het bladeren door berichten.

Het SequenceNumber voor een gepland bericht is alleen geldig terwijl het bericht deze status heeft. Naarmate het bericht overgaat naar de actieve status, wordt het bericht toegevoegd aan de wachtrij alsof het op het huidige moment is ge enqueueerd, waaronder het toewijzen van een nieuw SequenceNumber.

Omdat de functie is verankerd aan afzonderlijke berichten en berichten slechts één keer kunnen worden verzonden, biedt Service Bus geen ondersteuning voor terugkerende planningen voor berichten.

Notitie

Het moment waarop berichten worden verzonden, betekent niet dat het bericht tegelijkertijd wordt verzonden. Het wordt geïntenseueerd, maar de werkelijke verzendtijd is afhankelijk van de workload van de wachtrij en de status ervan.

Notitie

Vanwege prestatieoverwegingen zijn de activering en annulering van geplande berichten onafhankelijke bewerkingen zonder wederzijdse vergrendeling. Als een bericht wordt geactiveerd en tegelijkertijd wordt geannuleerd, wordt het activeringsproces niet omgekeerd en wordt het bericht nog steeds geactiveerd. Bovendien kan dit leiden tot een negatief aantal geplande berichten. Om deze racevoorwaarde te minimaliseren, is het raadzaam om te voorkomen dat activerings- en annuleringsbewerkingen in nauwe volgorde worden gepland.

Geplande berichten gebruiken met werkstromen

Het is gebruikelijk om langerlopende zakelijke werkstromen te zien die een expliciet tijdonderdeel voor hen hebben, zoals time-outs van 5 minuten voor tweeledige verificatie, time-outs van uren voor gebruikers die hun e-mailadres bevestigen, en onderdelen van meerdere dagen, weken of maanden in domeinen zoals banken en verzekeringen.

Deze werkstromen worden vaak gestart door de verwerking van een bericht, waarbij vervolgens een bepaalde status wordt opgeslagen en vervolgens een bericht wordt gepland om het proces op een later tijdstip voort te zetten. Frameworks zoals NServiceBus en MassTransit maken het gemakkelijker om al deze elementen samen te integreren.

Volgende stappen

Zie de volgende onderwerpen voor meer informatie over Service Bus Messaging:

• Service Bus-wachtrijen, -onderwerpen en -abonnementen
• Aan de slag met Service Bus-wachtrijen
• Service Bus-onderwerpen en -abonnementen gebruiken

Aanvullende resource

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