Schalen met Event Hubs

Er zijn twee factoren die van invloed zijn op schalen met Event Hubs.

• Doorvoereenheden (standard-laag) of verwerkingseenheden (Premium-laag)
• Partities

Doorvoereenheden

Doorvoereenheden bepalen de doorvoercapaciteit van Event Hubs. Doorvoereenheden zijn vooraf gekochte eenheden van capaciteit. Eén doorvoereenheid biedt de volgende mogelijkheden:

• Inkomend verkeer: maximaal 1 MB per seconde of 1000 gebeurtenissen per seconde (afhankelijk van wat het eerst komt).
• Uitgaand verkeer: maximaal 2 MB per seconde of 4.096 gebeurtenissen per seconde.

Als u de limiet van de aangeschafte doorvoereenheden overschrijdt, wordt de ingress beperkt en genereert Event Hubs een EventHubsException met de reden ServiceBusy. Uitgaand verkeer veroorzaakt geen knelpuntexcepties, maar kan nog steeds niet verder gaan dan de capaciteit van de door u aangeschafte doorvoereenheden. Als u uitzonderingen voor publicatiesnelheid ontvangt of verwacht dat u een toename in uitgaand dataverkeer ziet, controleert u hoeveel doorvoereenheden u hebt aangeschaft voor de naamruimte. U kunt doorvoereenheden beheren op de pagina Schaal van de naamruimten in Azure Portal. U kunt doorvoereenheden ook programmatisch beheren met behulp van de Event Hubs-API's.

U koopt doorvoereenheden vooraf en betaalt per uur voor deze eenheden. Zodra u doorvoereenheden hebt gekocht, betaalt u minimaal één uur. U kunt maximaal 40 doorvoereenheden aanschaffen voor een Event Hubs-naamruimte en alle Event Hubs in die naamruimte delen deze doorvoereenheden. Alle partities en consumenten binnen elke Event Hub delen de totale capaciteit voor inkomend en uitgaand verkeer van deze doorvoereenheden, zodat meerdere consumenten die uit dezelfde partitie lezen, de beschikbare bandbreedte delen.

De functie voor automatisch vergroten van Event Hubs wordt automatisch opgeschaald door het aantal doorvoereenheden te verhogen om te voldoen aan de gebruiksbehoeften. Het verhogen van doorvoereenheden voorkomt beperkingsscenario's, waarin:

• Gegevensingressies overschrijden de ingestelde doorvoereenheden.
• Verzoekfrequenties voor uitgaande gegevens overtreffen de ingestelde doorvoereenheden.

De Event Hubs-service verhoogt de doorvoer wanneer de belasting hoger is dan de minimumdrempel, zonder dat aanvragen mislukken met ServerBusy-fouten.

Zie Doorvoereenheden automatisch schalen voor meer informatie over de functie voor automatisch vergroten.

Verwerkingseenheden

Event Hubs Premium biedt superieure prestaties en betere isolatie binnen een beheerde PaaS-omgeving met meerdere tenants. De resources in een Premium-laag worden geïsoleerd op cpu- en geheugenniveau, zodat elke tenantworkload geïsoleerd wordt uitgevoerd. Deze resourcecontainer wordt een verwerkingseenheid (PU) genoemd. U kunt 1, 2, 4, 6, 8, 10, 12 of 16 verwerkingseenheden kopen voor elke Event Hubs Premium-naamruimte.

Hoeveel u kunt opnemen en streamen met een verwerkingseenheid, is afhankelijk van verschillende factoren, zoals uw producenten, consumenten, het tarief waarmee u gegevens opneemt en verwerkt, en nog veel meer.

Event Hubs Premium-naamruimte met één PU en één Event Hub (100 partities) kan bijvoorbeeld een kerncapaciteit bieden van ongeveer 5-10 MB/s inkomend verkeer en 10-20 MB/s uitgaand verkeer voor zowel AMQP- als Kafka-workloads.

Zie Verwerkingseenheden configureren voor meer informatie over het configureren van PU's voor een premium-laagnaamruimte.

Partities

Event Hubs organiseert reeksen gebeurtenissen die naar een Event Hub worden verzonden naar een of meer partities. Als er nieuwere gebeurtenissen plaatsvinden, worden deze toegevoegd aan het einde van deze reeks.

Een partitie kan worden beschouwd als een doorvoerlogboek. Partities bevatten gebeurtenisgegevens die de volgende informatie bevatten:

• Hoofdtekst van de gebeurtenis
• Door de gebruiker gedefinieerde eigenschapsverzameling die de gebeurtenis beschrijft
• Metagegevens zoals de offset in de partitie, het nummer in de stroomreeks
• Tijdstempel aan de serverzijde waarop deze is geaccepteerd

Voordelen van het gebruik van partities

Event Hubs is ontworpen om te helpen bij het verwerken van grote hoeveelheden gebeurtenissen. Partitioneren draagt hier op twee manieren aan bij:

• Hoewel Event Hubs een PaaS-service is, is er daaronder een fysieke realiteit. Als u een logboek onderhoudt waarin de volgorde van gebeurtenissen behouden blijft, moeten deze gebeurtenissen samen worden bewaard in de onderliggende opslag en de bijbehorende replica's. Dit resulteert in een doorvoermaximum voor een dergelijk logboek. Partitionering maakt het mogelijk om meerdere parallelle logboeken te gebruiken voor dezelfde Event Hub en daarom de beschikbare capaciteit voor onbewerkte invoer-uitvoer (IO) te vermenigvuldigen.
• Uw eigen toepassingen moeten in staat zijn om het aantal gebeurtenissen dat naar een Event Hub wordt verzonden, bij te houden. Het kan complex zijn en vereist aanzienlijke, uitgeschaalde, parallelle verwerkingscapaciteit. De capaciteit van één proces voor het afhandelen van gebeurtenissen is beperkt, dus u hebt verschillende processen nodig. Partities zijn hoe uw oplossing deze processen voedt en toch zorgt ervoor dat elke gebeurtenis een duidelijke verwerkingseigenaar heeft.

Aantal partities

Het aantal partities wordt opgegeven op het moment van het maken van een Event Hub. Het moet tussen één en het maximumaantal partities zijn dat is toegestaan voor elke prijscategorie. Zie dit artikel voor de limiet voor het aantal partities voor elke laag.

U wordt aangeraden ten minste zoveel partities te kiezen als u verwacht dat deze vereist zijn tijdens de piekbelasting van uw toepassing voor die specifieke Event Hub.

Voor andere lagen dan de premium- en toegewezen lagen kunt u het aantal partities voor een Event Hub niet wijzigen nadat deze is gemaakt. Voor een Event Hub in een premium- of toegewezen laag kunt u het aantal partities verhogen nadat deze zijn gemaakt, maar u kunt ze niet verlagen. De distributie van streams tussen partities wordt gewijzigd wanneer deze wordt uitgevoerd als de toewijzing van partitiesleutels aan partities verandert. Probeer deze wijzigingen dus moeilijk te voorkomen als de relatieve volgorde van gebeurtenissen in uw toepassing van belang is.

Het instellen van het aantal partities op de maximaal toegestane waarde is verleidelijk, maar u moet er altijd rekening mee houden dat uw gebeurtenissenstromen zo moeten worden gestructureerd dat u wel kunt profiteren van meerdere partities. Als u absolute volgordebehoud nodig hebt voor alle gebeurtenissen of slechts een handvol substreams, kunt u mogelijk niet profiteren van veel partities. Daarnaast maken veel partities de verwerkingszijde complexer.

Het maakt niet uit hoeveel partities zich in een Event Hub bevinden als het gaat om prijzen. Dit is afhankelijk van het aantal prijseenheden (doorvoereenheden (RU's) voor de standard-laag, verwerkingseenheden (PU's) voor de Premium-laag en capaciteitseenheden (CA's) voor de toegewezen laag) voor de naamruimte of het toegewezen cluster. Een Event Hub van de standard-laag met 32 partities of met één partitie kost bijvoorbeeld exact dezelfde kosten wanneer de naamruimte is ingesteld op één TU-capaciteit. U kunt ook PU's of TU's schalen in uw naamruimte of CU's in uw toegewezen cluster, onafhankelijk van het aantal partities.

Een partitie is een mechanisme voor gegevensorganisatie dat parallelle publicatie en verbruik mogelijk maakt. Hoewel het ondersteuning biedt voor parallelle verwerking en schaalaanpassing, blijft de totale capaciteit beperkt door de schaaltoewijzing van de naamruimte. Schaaleenheden (doorvoereenheden voor de standard-laag, verwerkingseenheden voor de Premium-laag of capaciteitseenheden voor de toegewezen laag) en partities verdelen om optimale schaal te bereiken.

Begin met uw workloadprofiel: gemiddelde nettoladingsgrootte, gebeurtenissen per seconde en gevoeligheid voor doorvoeruitval of latentiepieken. Gebruik de onderstaande doorvoer per partitie als uitgangspunt en valideer vervolgens met belastingstests:

• Standard-laag: ~1 MB/s inkomend en ~2 MB/s uitgaand verkeer per partitie.
• Premium- en Dedicated-lagen: ~1-2 MB/s inkomend verkeer en ~2-5 MB/s uitgaand verkeer per partitie.

Maak een schatting van partities door uw verwachte inkomend en uitgaand verkeer te delen door de toepasselijke tarieven per partitie en het grotere resultaat te nemen. Als waargenomen doorvoer of latentie niet aan de verwachtingen voldoet, verhoogt u partities (alleen Premium- en Dedicated-lagen) en test u opnieuw.

Partities stellen ook het plafond in voor consumentenparalleliteit. Hoe dat plafond werkt, is afhankelijk van het type consument:

• Epoch-consumenten (exclusief) - Gebruikt door EventProcessorClient (.NET, Java) en EventHubConsumerClient (Python, JavaScript), wat het aanbevolen patroon is voor productie-AMQP-workloads. Slechts één epoch-consument kan tegelijkertijd eigenaar zijn van een bepaalde partitie in een consumentengroep. Als u meer processorexemplaren dan partities implementeert, worden er geen partities toegewezen aan de extra exemplaren en worden deze inactief totdat een bestaande eigenaar er een vrijgeeft. Als een nieuwe epoch-consument verbinding maakt met een hoger eigenaarsniveau, verbreekt de service de huidige eigenaar met een ConsumerDisconnected fout en neemt de nieuwe consument de verbinding over.
• Niet-epoch-consumenten — maximaal 5 niet-epoch ontvangers kunnen dezelfde partitie gelijktijdig binnen een consumentengroep lezen. Elke ontvanger ziet dezelfde gebeurtenissen (fan-out), zodat deze modus de verwerkingsdoorvoer per partitie niet verhoogt. Als u een epoch-consument verbindt met een partitie, wordt de verbinding met alle niet-epoch-consumenten op die partitie verbroken.
• Kafka-consumenten : Kafka-consumenten gebruiken het groepscoördinatieprotocol (group.id) in plaats van AMQP-epochs, maar het model voor partitieeigendom is gelijk: elke partitie wordt toegewezen aan precies één consumentlid binnen een consumentengroep tegelijk. Wanneer een nieuw lid zich aansluit of een bestaand lid vertrekt, herbalanceert de groep en worden partitietoewijzingen herverdeeld. Als er meer consumentenleden zijn dan partities, ontvangen de overtollige leden geen toewijzingen en blijven ze inactief totdat een toekomstige herverdeling een partitie vrij maakt. Als u onnodige herverdeling van tijdelijke verbroken verbindingen wilt verminderen, stelt u een uniek group.instance.id exemplaar per consument in (statisch lidmaatschap).

In de praktijk is het aantal partities gelijk aan het maximum aantal parallelle consumenten per consumentengroep , ongeacht of u AMQP-epoch-consumenten of Kafka-consumenten gebruikt. Factor dit in het aantal partities wanneer u van plan bent om uit te schalen.

Als uw toepassing een affiniteit heeft met een bepaalde partitie, is het verhogen van het aantal partities niet nuttig. Zie beschikbaarheid en consistentie voor meer informatie.

Toewijzing van gebeurtenissen aan partities

U kunt een partitiesleutel gebruiken om inkomende gebeurtenisgegevens toe te wijzen aan specifieke partities, zodat de gegevens kunnen worden geordend. De partitiesleutel is een door de afzender opgegeven waarde die aan een Event Hub wordt doorgegeven. Het wordt verwerkt via een statische hashfunctie, waarmee de partitietoewijzing wordt gemaakt. Als u bij het publiceren van een gebeurtenis geen partitiesleutel opgeeft, wordt er gebruikgemaakt van een round-robin-toewijzing.

De gebeurtenisuitgever is alleen op de hoogte van de partitiesleutel en niet van de partitie waarop de gebeurtenissen worden gepubliceerd. Deze ontkoppeling van sleutel en partitie schermt de afzender af, zodat deze niet te veel te weten hoeft te komen over de downstreamverwerking. Goede partitiesleutels zijn bijvoorbeeld een apparaatspecifieke of een gebruikersspecifieke identiteit, maar voor het groeperen van gerelateerde gebeurtenissen in dezelfde partitie kunnen ook andere kenmerken, zoals geografie, worden gebruikt.

Als u een partitiesleutel opgeeft, kunt u gerelateerde gebeurtenissen bijeenhouden in dezelfde partitie en in de exacte volgorde waarin ze zijn aangekomen. De partitiesleutel is een tekenreeks die is afgeleid van uw toepassingscontext en identificeert de relatie tussen de gebeurtenissen. Een reeks gebeurtenissen die wordt geïdentificeerd door een partitiesleutel is een stroom. Een partitie is een multiplex-logboekopslag voor veel van zulke stromen.

Gerelateerde inhoud

Zie de volgende artikelen voor meer informatie over Event Hubs:

• Doorvoereenheden automatisch schalen voor een standaardlaagnaamruimte
• Verwerkingseenheden configureren voor een naamruimte in de Premium-laag