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 händelsehubbar styrs av dataflödesenheter. Dataflödesenheter är förköpt kapacitetsenheter. Med en enda dataflödesenhet kan du:
- Ingress: Upp till 1 MB per sekund eller 1 000 händelser per sekund (beroende på vilket som inträffar först).
- Utgående: Upp till 2 MB per sekund eller 4 096 händelser per sekund.
Utöver kapaciteten för de köpta dataflödesenheterna begränsas ingressen och Event Hubs genererar en ServerBusyException. Utgående genererar inte begränsningsfel, men är fortfarande begränsad till kapaciteten för de köpta dataflö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 dataflödesenheter på sidan Skala för namnrymderna i Azure-portalen. Du kan också hantera dataflödesenheter programmatiskt med hjälp av Event Hubs-API:erna.
Dataflödesenheter förköps och faktureras per timme. När de väl har köpts debiteras de för minst en timme. Upp till 40 dataflödesenheter kan köpas för ett händelsehubb-namnområde och delas mellan alla händelsehubbar i namnområdet.
Funktionen Auto-inflate i Event Hubs skalas automatiskt upp genom att öka antalet dataflödesenheter för att uppfylla användningsbehoven. Genom att öka dataflödesenheter förhindrar du begränsningsscenarier, där:
- Data inkommande priser överskrider angivna dataflödesenheter.
- Datautgående begärandefrekvenser överskrider angivna dataflödesenheter.
Event Hubs-tjänsten ökar dataflödet när belastningen ökar över minimitröskelvärdet, utan att några begäranden misslyckas med ServerBusy-fel.
Mer information om funktionen autoinflate finns i Skala dataflödesenheter automatiskt.
Bearbetningsenheter
Event Hubs Premium ger överlägsen prestanda och bättre isolering i en hanterad PaaS-miljö med flera klientorganisationer. Resurserna på en Premium-nivå är isolerade på cpu- 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, till exempel dina producenter, konsumenter, hur snabbt du matar in och bearbetar och mycket mer.
Event Hubs Premium-namnrymd med en PU och en händelsehubb (100 partitioner) kan till exempel ungefär erbjuda kärnkapacitet på ~5–10 MB/s ingress och 10–20 MB/s utgående för både AMQP- eller Kafka-arbetsbelastningar.
Mer information om hur du konfigurerar PUs för ett premiumnivånamnområde finns i Konfigurera bearbetningsenheter.
Kommentar
Mer information om kvoter och gränser finns i Azure Event Hubs – kvoter och gränser.
Partitioner
Event Hubs organiserar sekvenser av händelser som skickas till en händelsehubb till en eller flera partitioner. När nyare händelser kommer läggs de till i slutet av den här sekvensen.
En partition kan ses som en incheckningslogg. Partitioner innehåller händelsedata som innehåller följande information:
- Brödtext för händelsen
- Användardefinierad egenskapsväska som beskriver händelsen
- Metadata, till exempel dess förskjutning i partitionen, dess nummer i strömsekvensen
- Tidsstämpel 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. För att upprätthålla en logg som bevarar händelseordningen måste dessa händelser hållas samman i den underliggande lagringen och dess repliker och det 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 multiplicera den tillgängliga I/O-dataflödeskapaciteten (Raw Input-Output).
- Dina egna program måste kunna hantera bearbetningen av mängden händelser som skickas till en händelsehubb. Det kan vara komplext och kräver betydande, utskalad, parallell bearbetningskapacitet. Kapaciteten för en enskild 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 en händelsehubb skapas. Det måste vara mellan en och det maximala antalet partitioner som tillåts för varje prisnivå. För gränsen för antal partitioner för varje nivå, se den här artikeln.
Vi rekommenderar att du väljer minst så många partitioner som du förväntar dig som krävs under programmets högsta belastning för den specifika händelsehubben. För andra nivåer än premium- och dedikerade nivåer kan du inte ändra antalet partitioner för en händelsehubb när den har skapats. För en händelsehubb på en premium- eller dedikerad nivå kan du öka antalet partitioner när det har skapats, men du kan inte minska dem. Fördelningen av strömmar mellan partitioner ändras när mappningen av partitionsnycklar till partitioner ändras, så du bör försöka undvika sådana ändringar om den relativa händelseordningen är viktig i ditt program.
Det är frestande att ange antalet partitioner till det högsta tillåtna värdet, men kom alltid ihåg att händelseströmmarna måste struktureras så att du verkligen kan dra nytta av flera partitioner. Om du behöver absolut ordningsbevarande för alla händelser eller bara en handfull underströ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 prisenheter (dataflödesenheter (TUs) för standardnivån, bearbetningsenheter (PUs) för premiumnivå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 en partition exakt samma kostnad när namnområdet är inställt på en TU-kapacitet. Du kan också skala TUs eller PUs på ditt namnområde eller CUS för ditt dedikerade kluster oberoende av partitionsantalet.
Eftersom partition är en mekanism för dataorganisation som gör att du kan publicera och använda data parallellt. Vi rekommenderar att du balanserar skalningsenheter (dataflödesenheter för standardnivån, bearbetningsenheter för premiumnivån eller kapacitetsenheter för den dedikerade nivån) och partitioner för att uppnå optimal skalning. I allmänhet rekommenderar vi ett maximalt dataflöde på 1 MB/s per partition. Därför skulle en tumregel för att beräkna antalet partitioner vara att dividera det maximala förväntade dataflödet med 1 MB/s. Om ditt användningsfall till exempel kräver 20 MB/s rekommenderar vi att du väljer minst 20 partitioner för att uppnå optimalt dataflöde.
Men om du har en modell där ditt program har en tillhörighet till en viss partition är det inte fördelaktigt att öka antalet partitioner. Mer information finns i tillgänglighet och konsekvens.
Mappning av händelser till partitioner
Du kan organisera data med hjälp av en partitionsnyckel som mappar inkommande händelsedata till specifika partitioner. Partitionsnyckeln är ett värde som avsändaren anger och som skickas till en händelsehubb. Den bearbetas via en statisk hashningsfunktion, vilket 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.
Genom att ange en partitionsnyckel kan relaterade händelser hållas samman i samma partition och i exakt den ordning som de anlände. Partitionsnyckeln är en sträng som härleds från programkontexten och identifierar sambandet mellan händelserna. En sekvens med händelser som identifieras av en partitionsnyckel är en ström. En partition är ett multiplexat loggarkiv för många sådana strömmar.
Kommentar
Du kan skicka händelser direkt till partitioner, men vi rekommenderar det inte, särskilt inte när hög tillgänglighet är viktig för dig. Den nedgraderar tillgängligheten för en händelsehubb till partitionsnivå. Mer information finns i Tillgänglighet och konsekvens.
Nästa steg
Du kan lära dig mer om Event Hubs genom att gå till följande länkar: