Delen via

Partitiebelasting verdelen over meerdere exemplaren van uw toepassing

  • Artikel

Als u de toepassing voor gebeurtenisverwerking wilt schalen, kunt u meerdere exemplaren van de toepassing uitvoeren en de taakverdeling tussen zichzelf laten verdelen. In de oudere en afgeschafte versies EventProcessorHost kunt u de belasting verdelen tussen meerdere exemplaren van uw programma en controlepunten bij het ontvangen van de gebeurtenissen. In de nieuwere versies (5.0 en hoger), EventProcessorClient (.NET en Java) of EventHubConsumerClient (Python en JavaScript) kunt u hetzelfde doen. Het ontwikkelingsmodel wordt eenvoudiger gemaakt met behulp van gebeurtenissen. U kunt zich abonneren op de gebeurtenissen waarin u geïnteresseerd bent door een gebeurtenis-handler te registreren. Als u de oude versie van de clientbibliotheek gebruikt, raadpleegt u de volgende migratiehandleidingen: .NET, Java, Python en JavaScript.

In dit artikel wordt een voorbeeldscenario beschreven voor het gebruik van meerdere exemplaren van clienttoepassingen om gebeurtenissen van een Event Hub te lezen. U krijgt ook informatie over functies van de gebeurtenisprocessorclient, waarmee u gebeurtenissen van meerdere partities tegelijk kunt ontvangen en taken kunt verdelen met andere consumenten die gebruikmaken van dezelfde Event Hub en consumentengroep.

Notitie

De sleutel om te schalen voor Event Hubs is het idee van gepartitioneerde consumenten. In tegenstelling tot het patroon van concurrerende consumenten maakt het gepartitioneerde consumentenpatroon grootschalig door het knelpunt van conflicten te verwijderen en end-to-end parallellisme te vergemakkelijken.

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 dat deze gebeurtenissen kan lezen, samenvoegen (filteren, aggregeren, enzovoort) en de aggregaties dumpen naar een opslagblob, die vervolgens wordt geprojecteerd op een gebruiksvriendelijke webpagina.

Consumententoepassing

Wanneer u een consument ontwerpt in een gedistribueerde omgeving, moet het scenario de volgende vereisten afhandelen:

  1. Schaal: Maak meerdere consumenten, waarbij elke consument eigenaar wordt van het lezen van een paar Event Hubs-partities.
  2. Taakverdeling: verhoog of verminder de gebruikers dynamisch. 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.
  3. Probleemloos hervatten bij storingen: als een consument (consument A) mislukt (bijvoorbeeld de virtuele machine die als host fungeert voor de consument), kunnen andere consumenten de partities ophalen die eigendom zijn van consument A en doorgaan. Ook moet het vervolgpunt, een controlepunt of offset genoemd, precies zijn op het punt waarop consument A is mislukt, of iets daarvoor.
  4. Gebeurtenissen verbruiken: terwijl de vorige drie punten betrekking hebben op het beheer van de consument, moet er code zijn om gebeurtenissen te gebruiken en er iets mee te doen. Bijvoorbeeld aggregeren en uploaden naar blobopslag.

Gebeurtenisprocessor 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 EventHubConsumerClientu . In de oude versie van SDK was het de gebeurtenisprocessorhost (EventProcessorHost) die deze functies ondersteunde.

Voor de meeste productiescenario's raden we u aan de gebeurtenisprocessorclient te gebruiken voor het lezen en verwerken van gebeurtenissen. De processorclient is bedoeld om een robuuste ervaring te bieden voor het verwerken van gebeurtenissen in alle partities van een Event Hub op een performante en fouttolerante manier en biedt een manier om de voortgang ervan te controleren. Event Processor-clients kunnen samenwerken binnen de context van een consumentengroep voor een bepaalde Event Hub. Clients beheren automatisch distributie en taakverdeling wanneer exemplaren beschikbaar of niet beschikbaar zijn voor de groep.

Eigendom van partitie

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 id en claimt eigendom van partities door een vermelding toe te voegen of bij te werken in een controlepuntarchief. Alle exemplaren van gebeurtenisprocessor communiceren periodiek met dit archief om de eigen verwerkingsstatus bij te werken 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. Nieuwe exemplaren kunnen lid worden van de verwerkingsgroep om omhoog te schalen. Wanneer exemplaren uitvallen vanwege fouten of omlaag schalen, wordt het eigendom van de partitie correct overgedragen naar andere actieve processors.

Eigendomsrecords partitioneren in het controlepuntarchief houden de Event Hubs-naamruimte, event hub-naam, consumentengroep, gebeurtenisprocessor-id (ook wel eigenaar genoemd), partitie-id en de laatste wijzigingstijd bij.

Event Hubs-naamruimte Event hub-naam Consumentengroep Eigenaar Partitie-id Laatst gewijzigd tijdstip
mynamespace.servicebus.windows.net myeventhub myconsumergroup 3be3f9d3-9d9e-4c50-9491-85ece8334ff6 0 2020-01-15T01:22:15
mynamespace.servicebus.windows.net myeventhub myconsumergroup f5cc5176-ce96-4bb4-bbaa-a0e3a9054ecf 1 2020-01-15T01:22:17
mynamespace.servicebus.windows.net myeventhub myconsumergroup 72b980e9-2efc-4ca7-ab1b-ffd7bece8472 2 2020-01-15T01:22:10
:
:
mynamespace.servicebus.windows.net myeventhub myconsumergroup 844bd8fb-1f3a-4580-984d-6324f9e208af 15 2020-01-15T01:22:00

Elk gebeurtenisprocessorexemplaren krijgt het eigendom van een partitie en begint met het verwerken van de partitie vanaf het laatst bekende controlepunt. Als een processor mislukt (VM wordt afgesloten), detecteren andere exemplaren deze door naar de laatste wijzigingstijd te kijken. Andere exemplaren proberen het eigendom te krijgen van de partities die eerder eigendom zijn van het inactieve exemplaar. Het controlepuntarchief garandeert dat slechts één van de exemplaren het eigendom van een partitie kan claimen. Op een bepaald moment is er dus maximaal één processor die gebeurtenissen van een partitie ontvangt.

Berichten ontvangen

Wanneer u een gebeurtenisprocessor maakt, geeft u 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.

Controlepunt

Controlepunten zijn een proces waarmee een gebeurtenisprocessor de positie van de laatst verwerkte gebeurtenis binnen een partitie markeert of doorvoert. 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, wordt de offset doorgegeven aan de Event Hub om de locatie op te geven waarop moet worden gelezen. 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.

Wanneer het controlepunt wordt uitgevoerd om een gebeurtenis te markeren als verwerkt, wordt een vermelding in het controlepuntarchief toegevoegd of bijgewerkt met het offset- en volgnummer van de gebeurtenis. Gebruikers moeten de frequentie bepalen van het bijwerken van het controlepunt. Bijwerken na elke verwerkte gebeurtenis kan gevolgen hebben voor de prestaties en kosten, omdat er een schrijfbewerking naar het onderliggende controlepuntarchief wordt geactiveerd. Controlepunten voor elke gebeurtenis wijzen ook op een berichtenpatroon in de wachtrij waarvoor een Service Bus-wachtrij een betere optie kan zijn dan een Event Hub. Het idee achter Event Hubs is dat u 'ten minste één keer' levering krijgt op grote schaal. Door uw downstreamsystemen idempotent te maken, kunt u eenvoudig herstellen van fouten of opnieuw opstarten, waardoor dezelfde gebeurtenissen meerdere keren worden ontvangen.

Volg deze aanbevelingen wanneer u Azure Blob Storage gebruikt als controlepuntarchief:

  • Gebruik een afzonderlijke container voor elke consumentengroep. U kunt hetzelfde opslagaccount gebruiken, maar één container per groep gebruiken.
  • Gebruik de container niet voor iets anders en gebruik het opslagaccount niet voor iets anders.
  • Het opslagaccount moet zich in dezelfde regio bevinden als waarin de geïmplementeerde toepassing zich bevindt. Als de toepassing on-premises is, probeert u de dichtstbijzijnde regio te kiezen.

Controleer op de pagina Opslagaccount in Azure Portal in de sectie Blob-service of de volgende instellingen zijn uitgeschakeld.

  • Hiërarchische naamruimte
  • Blob voorlopig verwijderen
  • Versiebeheer

Threadbeveiligings- en processorexemplaren

De functie die gebeurtenissen verwerkt, wordt standaard sequentieel aangeroepen voor een bepaalde partitie. Volgende gebeurtenissen en aanroepen naar deze functie vanuit dezelfde partitiewachtrij achter de schermen als de gebeurtenispomp 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.

Gerelateerde inhoud

Bekijk de volgende quickstarts: