Partitionbelastningsutjämning för händelsebearbetning

Belastningsutjämning för partitioner är en teknik i Azure Event Hubs som distribuerar händelsebearbetningsarbetsbelastningar över flera instanser av ditt program. Händelseprocessorklienten hanterar automatiskt partitionsägarskapet och samordnar arbetsdistributionen mellan alla aktiva konsumentinstanser.

I de nyare SDK-versionerna (5.0 och senare) hanterar EventProcessorClient (.NET och Java) eller EventHubConsumerClient (Python och JavaScript) belastningsutjämning automatiskt. Du prenumererar på de händelser som du är intresserad av genom att registrera en händelsehanterare.

Den här artikeln beskriver ett exempelscenario för att använda flera instanser av klientprogram för att läsa händelser från en händelsehubb. Den förklarar också viktiga begrepp som partitionsägarskap, kontrollpunkter och belastningsutjämning.

Exempelscenario

Som ett exempel kan du överväga ett hemsäkerhetsföretag som övervakar 100 000 hem. Varje minut hämtar den data från olika sensorer, till exempel en rörelsedetektor, öppen sensor för dörr/fönster, glasbrytsdetektor och så vidare, installerade i varje hem. Företaget tillhandahåller en webbplats för boende att övervaka aktiviteten i sitt hem i nära realtid.

Varje sensor skickar data till en händelsehubb. Händelsehubben har konfigurerats med 16 partitioner. I den förbrukande änden behöver du en mekanism som kan läsa dessa händelser, konsolidera dem (filtrera, aggregera och så vidare) och dumpa aggregeringen till en lagringsblob, som sedan projiceras till en användarvänlig webbsida.

Konsumentapplikation

När du utformar en konsument i en distribuerad miljö måste scenariot hantera följande krav:

• Skala: Skapa flera konsumenter, där varje konsument äger läsningen från några Event Hubs-partitioner.
• Belastningsutjämning: Öka eller minska konsumenterna dynamiskt. När till exempel en ny sensortyp (till exempel en kolmonoxiddetektor) läggs till i varje hem ökar antalet händelser. I så fall ökar operatorn (en människa) antalet konsumentinstanser. Sedan kan poolen med konsumenter balansera om antalet partitioner som de äger för att dela belastningen med de nyligen tillagda konsumenterna.
• Sömlöst återuppta vid fel: Om en konsument (konsument A) misslyckas (till exempel om den virtuella datorn som är värd för konsumenten plötsligt kraschar) kan andra konsumenter hämta de partitioner som ägs av konsument A och fortsätta. Fortsättningspunkten, som kallas för en kontrollpunkt eller förskjutning, bör också vara vid den exakta tidpunkt då konsument A misslyckades, eller något före det.
• Konsumera händelser: Medan de föregående tre punkterna handlar om hantering av konsumenten måste det finnas kod för att använda händelser och göra något användbart med det. Du kan till exempel aggregera den och ladda upp den till bloblagring.

Händelseprocessor eller konsumentklient

Du behöver inte skapa en egen lösning för att uppfylla dessa krav. Azure Event Hubs SDK:er tillhandahåller den här funktionen. I .NET eller Java SDK:er använder du en händelseprocessorklient (EventProcessorClient). I Python och JavaScript-SDK:er använder du EventHubConsumerClient. I den gamla versionen av SDK stödde händelseprocessorvärd (EventProcessorHost) dessa funktioner.

I de flesta produktionsscenarier använder du händelseprocessorklienten för att läsa och bearbeta händelser. Processorklienten ger en robust upplevelse för bearbetning av händelser över alla partitioner i en händelsehubb på ett högpresterande och feltolerant sätt samtidigt som det ger ett sätt att kontrollera dess förlopp. Händelseprocessorklienter kan samarbeta inom ramen för en konsumentgrupp för en viss händelsehubb. Klienter hanterar automatiskt distribution och balansering av arbete när instanser blir tillgängliga eller otillgängliga för gruppen.

Partitionsägarskap

En händelseprocessorinstans äger och bearbetar vanligtvis händelser från en eller flera partitioner. Systemet distribuerar ägarskapet för partitioner jämnt mellan alla aktiva händelseprocessorinstanser som är associerade med en kombination av händelsehubbar och konsumentgrupper.

Varje händelseprocessor har en unik identifierare och gör anspråk på ägandeskap av partitioner genom att lägga till eller uppdatera en post i en kontrollpunktsdatabas. Alla händelseprocessorinstanser kommunicerar regelbundet med den här lagringsplatsen för att uppdatera sitt eget bearbetningstillstånd och för att lära sig om andra aktiva instanser. Systemet använder dessa data för att balansera belastningen mellan de aktiva processorerna. Nya instanser kan ansluta sig till bearbetningspoolen för att skala upp. När instanser går ned, antingen på grund av fel eller för att skala ned, överför systemet korrekt partitionsägarskapet till andra aktiva processorer.

Partitionsägarposter i kontrollpunktslagret håller reda på Event Hubs-namnrymd, händelsehubbnamn, konsumentgrupp, händelseprocessoridentifierare (även kallat ägare), partitions-ID och den senaste ändrade tiden.

Varje händelseprocessorinstans hämtar ägarskapet för en partition och börjar bearbeta partitionen från den senast kända kontrollpunkten. Om en processor misslyckas (den virtuella datorn stängs av) identifierar andra instanser felet genom att titta på den senaste ändrade tiden. Andra instanser försöker få ägarskap för de partitioner som tidigare ägdes av den inaktiva instansen. Kontrollpunktlagringen garanterar att endast en av instanserna lyckas ta ägarskap för en partition. Vid en viss tidpunkt finns det alltså högst en processor som tar emot händelser från en partition.

Ta emot meddelanden

När du skapar en händelseprocessor anger du funktioner som bearbetar händelser och fel. Varje anrop till funktionen som bearbetar händelser levererar en enskild händelse från en specifik partition. Du måste hantera den här händelsen. Om du vill se till att konsumenten bearbetar varje meddelande minst en gång skriver du din egen kod med logik för återförsök. Men var försiktig med förgiftade meddelanden.

Bearbeta händelser relativt snabbt. Det vill: gör så lite bearbetning som möjligt. Om du behöver skriva till lagring och utföra viss routning är det bättre att använda två konsumentgrupper och ha två händelseprocessorer.

Kontrollpunkt

Checkpointing är en process där en händelseprocessor markerar eller bekräftar positionen för den senast framgångsrikt bearbetade händelsen i en partition. Att markera en kontrollpunkt sker vanligtvis i funktionen som bearbetar händelserna och inträffar per partition i en konsumentgrupp.

Om en händelseprocessor kopplas från en partition kan en annan instans återuppta bearbetningen av partitionen vid kontrollpunkten som den sista processorn av den partitionen i konsumentgruppen tidigare har fastställt. När processorn ansluter, skickar den förskjutningen till händelsehubben för att ange var den ska börja läsa. På så sätt kan du använda kontrollpunkter för att både markera händelser som "slutförda" av underordnade program och för att ge återhämtning när en händelseprocessor slutar fungera. Du kan återgå till äldre data genom att ange en lägre förskjutning från den här kontrollpunktsprocessen.

När kontrollpunkten markerar en händelse som bearbetad lägger den till eller uppdaterar en post i kontrollpunktlagringen med händelsens offset och sekvensnummer. Bestäm hur ofta kontrollpunkten ska uppdateras. Uppdatering efter varje lyckad bearbetad händelse kan få prestanda- och kostnadskonsekvenser eftersom den utlöser en skrivåtgärd till det underliggande kontrollpunktsarkivet. Kontrollpunkter för varje enskild händelse tyder också på ett mönster för köade meddelanden där en Service Bus-kö kan vara ett bättre alternativ än en händelsehubb. Tanken bakom Event Hubs är att du får garanterad minst en leverans i stor skala. Genom att göra dina nedströms system idempotenta blir det enkelt att återhämta sig från fel eller omstarter som leder till att samma händelser tas emot flera gånger.

Följ dessa rekommendationer när du använder Azure Blob Storage som kontrollpunktslager:

• Använd en separat container för varje konsumentgrupp. Du kan använda samma lagringskonto, men använda en container per grupp.
• Använd inte lagringskontot för något annat.
• Använd inte containern för något annat.
• Skapa lagringskontot i samma region som det distribuerade programmet. Om applikationen är lokal, försök att välja den region som är närmast.

På sidan Lagringskonto i Azure Portal i avsnittet Blob Service kontrollerar du att följande inställningar är inaktiverade.

• Hierarkisk namnrymd
• Mjuk borttagning av blob
• Versionshantering

Trådsäkerhet och processorinstanser

Som standard anropas funktionen som bearbetar händelser sekventiellt för en viss partition. Efterföljande händelser och anrop till funktionen från samma partitionskö placeras i vänteläge medan händelsepumpen fortsätter att köras i bakgrunden på andra trådar. Händelser från olika partitioner kan bearbetas samtidigt. Du måste synkronisera alla delade tillstånd som nås mellan partitioner.

Relaterat innehåll

Se följande snabbstarter:

• .NET Core
• Java
• Python
• JavaScript