Patroon sequentiële vastgelopen werk
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 uitschalen om een grotere belasting te verwerken. In een gedistribueerde architectuur is het op volgorde verwerken van deze berichten niet eenvoudig, omdat de werksters onafhankelijk kunnen schalen en vaak onafhankelijk berichten kunnen pullen met behulp van een patroon concurrerende consumenten.
Een systeem voor ordertracking ontvangt bijvoorbeeld een grootboek met orders en de relevante bewerkingen op die orders. Deze bewerkingen kunnen zijn om een order te maken, een transactie toe te voegen aan de order, een eerdere transactie te wijzigen of een order te verwijderen. In dit systeem moeten bewerkingen worden uitgevoerd op een FIFO-manier (first-in-first-out), maar alleen op volgordeniveau. De eerste wachtrij ontvangt echter een grootboek met transacties voor veel orders, die onderling kunnen worden opgeslagen.
Oplossing
Push gerelateerde berichten naar categorieën binnen het wachtrijsysteem en laat de wachtrijlisteners slechts uit één categorie, één bericht tegelijk, vergrendelen en pullen.
Zo ziet het algemene patroon Sequentieel patroon Voor het patroon Patroon patroon eruit:
In de wachtrij kunnen berichten voor verschillende categorieën onderling worden opgeslagen, 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 de volgorde is deze eigenschap de order-id.
- Doorvoer. Wat is de doorvoer van uw doelbericht? Als het zeer hoog is, moet u mogelijk uw FIFO-vereisten opnieuw overwegen. Kunt u bijvoorbeeld een begin-/eindbericht afdwingen, sorteren op tijd en vervolgens een batch verzenden voor verwerking?
- Servicemogelijkheden. Staat uw keuze voor berichtenbus de verwerking van berichten in een wachtrij of categorie van een wachtrij één voor één toe?
- Betaalbaarheid. Hoe voegt u een nieuwe berichtcategorie toe aan het systeem? Stel bijvoorbeeld dat het hierboven beschreven grootboeksysteem specifiek is voor één klant. Als u onboarding van een nieuwe klant nodig hebt, kunt u dan een set grootboekprocessors hebben die werk distribueren per klant-id?
- Het is mogelijk dat consumenten een bericht in de niet-volgorde ontvangen vanwege variabele netwerklatentie bij het verzenden van berichten. Overweeg het gebruik van volgnummers om de volgorde te controleren. U kunt ook een speciale 'einde van de reeks'-vlag opnemen in het laatste bericht van een transactie. Stroomverwerkingstechnologieën zoals Spark of Azure Stream Analytics kunnen berichten in volgorde verwerken binnen een tijdvenster.
Wanneer dit patroon gebruiken
Gebruik dit patroon wanneer:
- U hebt berichten die op volgorde binnenkomen en in dezelfde volgorde moeten 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:
- Zeer hoge doorvoerscenario's (miljoenen berichten per minuut of seconde), omdat de FIFO-vereiste de schaalbaarheid beperkt die door het systeem kan worden uitgevoerd.
Voorbeeld
In Azure kan dit patroon worden geïmplementeerd met behulp van Azure Service Bus berichtsessies. Voor de consumenten kunt u een Logic Apps met de Service Bus peek-lock-connector of Azure Functions met de Service Bus trigger.
In het vorige voorbeeld voor het bijhouden van ordervolgorde verwerkt u elk grootboekbericht in de volgorde waarin deze is ontvangen en verzendt u elke transactie naar een andere wachtrij waar de categorie is ingesteld op de order-id. Een transactie omvat in dit scenario nooit meerdere orders, dus consumenten verwerken elke categorie parallel, maar FIFO binnen de categorie.
De ledgeprocessor ventilatoren de berichten door de batching van de inhoud van elk bericht in de eerste wachtrij:
De grootboekprocessor zorgt voor het volgende:
- Het grootboek één voor één laten lopen.
- De sessie-id van het bericht zo instellen dat deze overeenkomen met de order-id.
- Elke grootboektransactie naar een secundaire wachtrij verzenden 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 van de wachtrij. Consumenten gebruiken de peek-lock-modus.
Bij het overwegen van schaalbaarheid is de grootboekwachtrij een primair knelpunt. Verschillende transacties die in het grootboek worden geplaatst, kunnen verwijzen naar dezelfde order-id. Berichten kunnen echter na het grootboek het aantal bestellingen in een serverloze omgeving laten zien.
Volgende stappen
De volgende informatie kan relevant zijn bij het implementeren van dit patroon: