Skalning med Event Hubs

Det finns två faktorer som påverkar skalning med Event Hubs.

• Dataflödesenheter (standardnivå) eller bearbetningsenheter (premiumnivå)
• Partitioner

Genomflödesenheter

Dataflödeskapaciteten för Event Hubs styrs av genomflödesenheter. Genomflödesenheter är färdiga kapacitetsenheter. Med ett enda dataflöde kan du:

• Ingress: Upp till 1 MB per sekund eller 1 000 händelser per sekund (beroende på vilket som kommer först).
• Egress: Upp till 2 MB per sekund eller 4 096 händelser per sekund.

Utöver kapaciteten för köpta genomflödesenheter är den inkommande trafiken begränsad och en ServerBusyException returneras. Utgående trafik genererar inte begränsningsundantag, men är fortfarande begränsad till kapaciteten för de köpta genomflödesenheterna. Om du får felmeddelanden om publiceringsfrekvensen eller om du förväntar dig större utgående trafik kontrollerar du hur många genomflödesenheter du har köpt för namnområdet. Du kan hantera genomflödesenheter på bladet Skala för namnområdena på Azure-portalen. Du kan också hantera dataflödesenheter programmatiskt med hjälp av Event Hubs API:er.

Genomflödesenheter köps i förväg och faktureras per timme. När de väl har köpts debiteras de för minst en timme. Upp till 40 genomflödesenheter kan köpas för ett Event Hubs namnområde och delas mellan alla händelsehubar i det namnområdet.

Funktionen Automatisk ökning av Event Hubs skalas automatiskt upp genom att antalet dataflödesenheter ökas för att uppfylla användningsbehoven. Genomflödesenheter som ökar förhindrar begränsningsscenarier, där:

• Dataingressfrekvensen överskrider det inställda dataflödesaggregatet.
• Frekvensen för utgående dataflöden överskrider det inställda dataflödesaggregatet.

Tjänsten Event Hubs ökar dataflödet när belastningen ökar över det lägsta tröskelvärdet, utan att några begäranden misslyckas med ServerBusy-fel.

Mer information om funktionen automatisk blåsning finns i Skala dataflödesenheter automatiskt.

Bearbetningsenheter

Event Hubs Premium ger överlägsen prestanda och bättre isolering i en hanterad PaaS-miljö för flera olika miljöer. Resurserna på en Premium-nivå isoleras på processor- och minnesnivå så att varje klientarbetsbelastning körs isolerat. Den här resurscontainern kallas för en bearbetningsenhet(PU). Du kan köpa 1, 2, 4, 8 eller 16 bearbetningsenheter för varje Event Hubs Premium namnområde.

Hur mycket du kan mata in och strömma med en bearbetningsenhet beror på olika faktorer som dina producenter, konsumenter, hastigheten för inmatning och bearbetning och mycket mer. En bearbetningsenhet kan ungefär erbjuda kärnkapacitet på cirka 5–10 MB/s ingress och 10–20 MB/s utgående, eftersom vi har tillräckligt med partitioner så att lagringen inte är en begränsningsfaktor.

Mer information om hur du konfigurerar PUS:er för ett namnområde på premiumnivå finns i Konfigurera bearbetningsenheter.

Partitioner

Event Hubs ordnar sekvenser av händelser som skickas till en händelsehubb i en eller flera partitioner. När nyare händelser anländer läggs de till i slutet av den här sekvensen.

En partition kan ses som en "commit log" (genomförandelogg). Partitioner innehåller händelsedata som innehåller händelsens brödtext, en användardefinierad egenskapsdesk som beskriver händelsen, metadata som dess offset i partitionen, dess nummer i strömsekvensen och tidsstämpeln på tjänstsidan där den accepterades.

Fördelar med att använda partitioner

Event Hubs är utformat för att hjälpa till med bearbetning av stora mängder händelser, och partitionering hjälper till med detta på två sätt:

• Även om Event Hubs är en PaaS-tjänst finns det en fysisk verklighet under, och att upprätthålla en logg som bevarar ordningen på händelserna kräver att dessa händelser hålls tillsammans i den underliggande lagringen och dess repliker och att resulterar i ett dataflödestak för en sådan logg. Partitionering gör att flera parallella loggar kan användas för samma händelsehubb och därför multipliceras den tillgängliga råa I/O-dataflödeskapaciteten.
• Dina egna program måste kunna hålla koll på bearbetningen av mängden händelser som skickas till en händelsehubb. Det kan vara komplext och kräver betydande, utskalat, parallell bearbetningskapacitet. Kapaciteten för en enda process för att hantera händelser är begränsad, så du behöver flera processer. Partitioner är hur din lösning matar dessa processer och säkerställer ändå att varje händelse har en tydlig bearbetningsägare.

Antal partitioner

Antalet partitioner anges när du skapar en händelsehubb. Det måste vara mellan 1 och det maximala antalet partitioner som tillåts för varje prisnivå. Information om gränsen för antal partitioner för varje nivå finns i den här artikeln.

Vi rekommenderar att du väljer minst så många partitioner som du förväntar dig att krävs under programmets belastningstopp för just den händelsehubben. Du kan inte ändra antalet partitioner för en händelsehubb när den har skapats, förutom händelsehubben i ett dedikerat kluster och på premiumnivån. Antalet partitioner för en händelsehubb i ett dedikerat Event Hubs-kluster kan ökas när händelsehubben har skapats, men distributionen av strömmar mellan partitioner ändras när den är klar när mappningen av partitionsnycklar till partitioner ändras, så du bör försöka undvika sådana ändringar om den relativa ordningen på händelser är viktig i ditt program.

Det är lockande att ange antalet partitioner till det högsta tillåtna värdet, men tänk alltid på att dina händelseströmmar måste struktureras så att du verkligen kan dra nytta av flera partitioner. Om du behöver absolut ordningsföljd för alla händelser eller bara ett fåtal delströmmar kanske du inte kan dra nytta av många partitioner. Dessutom gör många partitioner bearbetningssidan mer komplex.

Det spelar ingen roll hur många partitioner som finns i en händelsehubb när det gäller priser. Det beror på antalet prisnivåer(dataflödesenheter (TUs) för standardnivån, bearbetningsenheter (PUS) för Premium-nivån och kapacitetsenheter (CUs) för den dedikerade nivån) för namnområdet eller det dedikerade klustret. Till exempel medför en händelsehubb på standardnivån med 32 partitioner eller med 1 partition exakt samma kostnad när namnområdet är inställt på 1 TU-kapacitet. Du kan också skala TUs eller PUs på namnområdet eller CUs för ditt dedikerade kluster oberoende av antalet partitioner.

Mappning av händelser till partitioner

Du kan använda en partitionsnyckel för att mappa inkommande händelsedata till specifika partitioner för att ordna data. Partitionsnyckeln är ett värde som avsändaren anger och som skickas till en händelsehubb. Den bearbetas via en statisk hash-funktion som skapar partitionstilldelningen. Om du inte anger en partitionsnyckel när du publicerar en händelse, används en tilldelning enligt resursallokeringsmodellen.

Händelseutfärdaren känner bara till sin partitionsnyckel, inte den partition som händelserna publiceras till. Frikopplingen av nyckeln och partitionen gör att avsändaren inte behöver känna till så mycket om bearbetningen nedströms. En identitet per enhet eller en användarunik identitet utgör en bra partitionsnyckel, men andra attribut, till exempel geografi, kan också användas för att gruppera relaterade händelser i en enda partition.

Om du anger en partitionsnyckel kan relaterade händelser förvaras tillsammans i samma partition och i exakt den ordning som de ankom. Partitionsnyckeln är en sträng som härleds från programkontexten och identifierar relationen mellan händelserna. En händelsesekvens som identifieras av en partitionsnyckel är en dataström. En partition är ett multiplexerat logglager för många sådana strömmar.

Nästa steg

Du kan lära dig mer om Event Hubs genom att gå till följande länkar:

• Skala dataflödesenheter automatiskt för ett namnområde på standardnivå
• Konfigurera bearbetningsenheter för ett namnområde på premiumnivå