Uw verwerkingstoepassing opschalen

Als u de toepassing voor het verwerken van gebeurtenissen wilt schalen, kunt u meerdere exemplaren van de toepassing uitvoeren en ervoor zorgen dat ze de belasting onder elkaar verdelen. In de oudere versies stond EventProcessorHost u toe de belasting te verdelen tussen meerdere exemplaren van uw programma en gebeurtenissen vast te leggen bij ontvangst. In de nieuwere versies (5.0 en hoger) kunt u met EventProcessorClient (.NET en Java) of EventHubConsumerClient (Python en JavaScript) hetzelfde bereiken.

Voorbeeldscenario

Denk bijvoorbeeld aan een thuisbeveiligingsbedrijf dat 100.000 woningen bewaakt. Elke minuut krijgt het gegevens van verschillende sensoren, zoals een bewegingsdetector, deur/raam open sensor, glasonderbrekingsdetector, enzovoort, geïnstalleerd in elk huis. Het bedrijf biedt een website voor bewoners om de activiteit van hun huis in bijna realtime te bewaken.

Elke sensor pusht gegevens naar een Event Hub. De Event Hub is geconfigureerd met 16 partities. Aan het verbruikende einde hebt u een mechanisme nodig waarmee deze gebeurtenissen kunnen worden gelezen, samengevoegd en de aggregaties kunnen worden gedumpt naar een opslagblob, die vervolgens wordt geprojecteerd op een gebruiksvriendelijke webpagina.

Bij het ontwerpen van de consument in een gedistribueerde omgeving moet het scenario de volgende vereisten afhandelen:

• Schaal: Maak meerdere consumenten waarbij elke consument eigenaar wordt van het lezen van een paar Event Hubs-partities.
• Laadbalans: De consumenten dynamisch vergroten of verkleinen. Wanneer bijvoorbeeld een nieuw sensortype (bijvoorbeeld een koolmonoxidedetector) aan elk huis wordt toegevoegd, neemt het aantal gebeurtenissen toe. In dat geval verhoogt de operator (een mens) het aantal consumentenexemplaren. Vervolgens kan de groep consumenten het aantal partities waarvan ze eigenaar zijn, opnieuw verdelen om de belasting te delen met de zojuist toegevoegde consumenten.
• naadloze hervatting van fouten: Als een consument (consument A) mislukt (bijvoorbeeld de virtuele machine die als host fungeert voor de consument plotseling vastloopt), kunnen andere consumenten de partities ophalen die eigendom zijn van consument A en doorgaan. Ook moet het vervolgpunt, een controlepunt of offsetgenoemd, precies zijn op het punt waarop consument A is mislukt, of iets daarvoor.
• Gebeurtenissen verwerken: Terwijl de vorige drie punten betrekking hebben op het beheer van de consument, moet er code zijn om de gebeurtenissen te verwerken en er iets nuttigs mee te doen. Bijvoorbeeld, aggregeer het en upload het naar de blobopslagplaats.

Eventverwerker of consumentenclient

U hoeft niet uw eigen oplossing te bouwen om aan deze vereisten te voldoen. De Azure Event Hubs SDK's bieden deze functionaliteit. In .NET- of Java-SDK's gebruikt u een gebeurtenisprocessorclient (EventProcessorClient) en in Python- en JavaScript-SDK's gebruikt u EventHubConsumerClient.

Voor de meeste productiescenario's raden we u aan de gebeurtenisprocessorclient te gebruiken voor het lezen en verwerken van gebeurtenissen. Event Processor-clients kunnen samenwerken binnen de context van een consumentengroep voor een bepaalde Event Hub. Klanten beheren automatisch de distributie en het balanceren van taken wanneer instanties beschikbaar of niet beschikbaar zijn binnen de groep.

Eigendom van partities bijhouden

Een instantie van een gebeurtenisprocessor is doorgaans eigenaar van en verwerkt gebeurtenissen van een of meer partities. Het eigendom van partities wordt gelijkmatig verdeeld over alle actieve gebeurtenisprocessorexemplaren die zijn gekoppeld aan een combinatie van event hubs en consumentengroepen.

Elke gebeurtenisprocessor krijgt een unieke identificatie en claimt beheer van partities door een vermelding toe te voegen of bij te werken in een checkpoint store. Alle exemplaren van gebeurtenisprocessoren communiceren periodiek met dit archief om hun eigen verwerkingsstatus te actualiseren en om meer te weten te komen over andere actieve exemplaren. Deze gegevens worden vervolgens gebruikt om de belasting van de actieve processors te verdelen.

Berichten ontvangen

Wanneer u een gebeurtenisprocessor maakt, geeft u de functies op die gebeurtenissen en fouten verwerken. Elke aanroep van de functie die gebeurtenissen verwerkt, levert één gebeurtenis van een specifieke partitie. Het is uw verantwoordelijkheid om deze gebeurtenis af te handelen. Als u ervoor wilt zorgen dat de consument elk bericht ten minste één keer verwerkt, moet u uw eigen code schrijven met logica voor opnieuw proberen. Maar wees voorzichtig met vergiftigde berichten.

We raden u aan om dingen relatief snel te doen. Dat wil gezegd, doe zo weinig mogelijk verwerking. Als u naar de opslag moet schrijven en wat routering moet uitvoeren, is het beter om twee consumentengroepen te gebruiken en twee gebeurtenisprocessors te hebben.

Controlepunten

Checkpointing is een proces waarmee een gebeurtenisprocessor de positie markeert of doorvoert van de laatst succesvol verwerkte gebeurtenis binnen een partitie. Het markeren van een controlepunt wordt meestal uitgevoerd binnen de functie die de gebeurtenissen verwerkt en plaatsvindt per partitie binnen een consumentengroep.

Als een gebeurtenisprocessor de verbinding met een partitie verbreekt, kan een ander exemplaar de verwerking van de partitie hervatten op het controlepunt dat eerder is doorgevoerd door de laatste processor van die partitie in die consumentengroep. Wanneer de processor verbinding maakt, geeft het de offset door aan de Event Hub om de leeslocatie te bepalen. Op deze manier kunt u controlepunten gebruiken om gebeurtenissen te markeren als 'voltooid' door downstreamtoepassingen en om tolerantie te bieden wanneer een gebeurtenisprocessor uitvalt. Het is mogelijk om terug te keren naar oudere gegevens door een lagere offset op te geven van dit controlepuntproces.

Draadveiligheid en processorinstanties

De functie die de gebeurtenissen verwerkt, wordt standaard sequentieel aangeroepen voor een bepaalde partitie. Volgende evenementen en aanroepen naar deze functie vanuit dezelfde partitiewachtrij worden achter de schermen in de rij geplaatst terwijl de evenementenpomp op de achtergrond op andere threads blijft draaien. Gebeurtenissen van verschillende partities kunnen gelijktijdig worden verwerkt en elke gedeelde status die wordt geopend tussen partities moet worden gesynchroniseerd.