Een reeks gerelateerde berichten in een gedefinieerde volgorde verwerken zonder de verwerking van andere groepen berichten te blokkeren.
Context en probleem
Toepassingen moeten vaak een reeks berichten verwerken in de volgorde waarin ze binnenkomen, terwijl ze nog steeds kunnen worden uitgeschaald om een verhoogde belasting te verwerken. In een gedistribueerde architectuur is het verwerken van deze berichten op volgorde niet eenvoudig, omdat de werknemers onafhankelijk kunnen schalen en vaak onafhankelijk berichten kunnen ophalen met behulp van een patroon concurrerende consumenten.
Een besteltraceringssysteem ontvangt bijvoorbeeld een grootboek met orders en de relevante bewerkingen voor die orders. Deze bewerkingen kunnen bestaan uit het maken van een order, het toevoegen van een transactie aan de order, het wijzigen van een eerdere transactie of het verwijderen van een order. In dit systeem moeten bewerkingen worden uitgevoerd op een FIFO-manier (first-in-first-out), maar alleen op orderniveau. De initiële wachtrij ontvangt echter een grootboek met transacties voor veel orders, die mogelijk interleaved zijn.
Oplossing
Push gerelateerde berichten naar categorieën in het wachtrijsysteem en laat de wachtrijlisteners vergrendelen en slechts uit één categorie ophalen, één bericht tegelijk.
Dit is hoe het algemene sequentiële convoypatroon eruitziet:
Berichten voor verschillende categorieën kunnen in de wachtrij worden geplaatst, zoals wordt weergegeven in het volgende diagram:
Problemen en overwegingen
Beschouw de volgende punten als u besluit hoe u dit patroon wilt implementeren:
- Categorie-/schaaleenheid. Op welke eigenschap van uw binnenkomende berichten kunt u uitschalen? In het scenario voor het bijhouden van bestellingen is deze eigenschap de order-id.
- Doorvoer. Wat is de doorvoer van uw doelbericht? Als het erg hoog is, moet u mogelijk uw FIFO-vereisten herzien. Kunt u bijvoorbeeld een begin-/eindbericht afdwingen, sorteren op tijd en vervolgens een batch verzenden voor verwerking?
- Servicemogelijkheden. Is uw keuze voor berichtenbus een eenmalige verwerking van berichten binnen een wachtrij of categorie van een wachtrij mogelijk?
- Evolvability. Hoe voegt u een nieuwe categorie berichten toe aan het systeem? Stel dat het grootboeksysteem dat hierboven wordt beschreven, specifiek is voor één klant. Als u een nieuwe klant wilt onboarden, kunt u een set grootboekprocessors hebben die werk distribueren per klant-id?
- Het is mogelijk dat consumenten een bericht op volgorde ontvangen vanwege een variabele netwerklatentie bij het verzenden van berichten. Overweeg het gebruik van volgnummers om de volgorde te controleren. U kunt ook een speciale vlag voor het einde van de reeks opnemen in het laatste bericht van een transactie. Technologieën voor stroomverwerking, zoals Spark of Azure Stream Analytics, kunnen berichten binnen een tijdvenster op volgorde verwerken.
Wanneer dit patroon gebruiken
Gebruik dit patroon wanneer:
- U hebt berichten die op volgorde aankomen en moeten in dezelfde volgorde worden verwerkt.
- Binnenkomende berichten zijn of kunnen zodanig worden gecategoriseerd dat de categorie een schaaleenheid voor het systeem wordt.
Dit patroon is mogelijk niet geschikt voor:
- Extreem hoge doorvoerscenario's (miljoenen berichten/minuut of seconde), omdat de FIFO-vereiste de schaal beperkt die door het systeem kan worden uitgevoerd.
Workloadontwerp
Een architect moet evalueren hoe het sequentiële convoypatroon kan worden gebruikt in het ontwerp van hun workload om de doelstellingen en principes te verhelpen die worden behandeld in de pijlers van het Azure Well-Architected Framework. Voorbeeld:
| Pijler | Hoe dit patroon ondersteuning biedt voor pijlerdoelen |
|---|---|
| Beslissingen over betrouwbaarheidsontwerp helpen uw workload bestand te worden tegen storingen en ervoor te zorgen dat deze herstelt naar een volledig functionerende status nadat er een fout is opgetreden. | Met dit patroon kunnen racevoorwaarden worden geëlimineerd die moeilijk kunnen worden opgelost, conflicterend berichtafhandeling of andere tijdelijke oplossingen voor het oplossen van verkeerd geordende berichten die kunnen leiden tot storingen. - RE:02 Kritieke stromen - RE:07 Achtergrondtaken |
Net als bij elke ontwerpbeslissing moet u rekening houden met eventuele compromissen ten opzichte van de doelstellingen van de andere pijlers die met dit patroon kunnen worden geïntroduceerd.
Opmerking
In Azure kan dit patroon worden geïmplementeerd met behulp van Azure Service Bus-berichtsessies. Voor de consumenten kunt u Logic Apps gebruiken met de Service Bus peek-lock-connector of Azure Functions met de Service Bus-trigger.
Voor het vorige voorbeeld van het bijhouden van bestellingen verwerkt u elk grootboekbericht in de volgorde waarin het wordt ontvangen en verzendt u elke transactie naar een andere wachtrij waarin de categorie is ingesteld op de order-id. Een transactie omvat nooit meerdere orders in dit scenario, dus consumenten verwerken elke categorie parallel, maar FIFO binnen de categorie.
De grootboekprocessor schakelt de berichten uit door de inhoud van elk bericht in de eerste wachtrij ongedaan te maken:
De grootboekprocessor zorgt voor:
- Het grootboek één transactie tegelijk doorlopen.
- Stel de sessie-id van het bericht in zodat deze overeenkomt met de order-id.
- Elke grootboektransactie verzenden naar een secundaire wachtrij met de sessie-id ingesteld op de order-id.
De consumenten luisteren naar de secundaire wachtrij waar ze alle berichten verwerken met overeenkomende order-id's in volgorde uit de wachtrij. Consumenten gebruiken de modus peek-lock .
Bij het overwegen van schaalbaarheid is de grootboekwachtrij een primair knelpunt. Verschillende transacties die in het grootboek zijn geboekt, kunnen verwijzen naar dezelfde order-id. Berichten kunnen echter uitwaaieren na het grootboek naar het aantal orders in een serverloze omgeving.
Volgende stappen
De volgende informatie kan relevant zijn bij het implementeren van dit patroon: