Škálování aplikace pro zpracování

3 min

Pokud chcete škálovat aplikaci pro zpracování událostí, můžete spustit několik instancí aplikace a vyrovnávat zatížení mezi sebou. Ve starších verzích umožňuje EventProcessorHost vyrovnávat zatížení mezi více instancemi programu a událostmi kontrolního bodu při příjmu. V novějších verzích (5.0 dál), EventProcessorClient (.NET a Java) nebo EventHubConsumerClient (Python a JavaScript) umožňuje provádět totéž.

Poznámka:

Klíčem ke škálování služby Event Hubs je myšlenka dělených příjemců. Na rozdíl od modelu konkurenčních spotřebitelů umožňuje model dělených příjemců vysoký rozsah odebráním kritického bodu kolize a usnadněním konce až do konce paralelismu.

Ukázkový scénář

Jako ukázkový scénář zvažte společnost zabezpečení domu, která monitoruje 100 000 domů. Každou minutu získává data z různých senzorů, jako je detektor pohybu, senzor otevření dveří/oken, detektor rozbití skla atd., nainstalovaný v každém domě. Společnost poskytuje web pro obyvatele, aby mohli sledovat aktivitu svého domova téměř v reálném čase.

Každý senzor nasdílí data do centra událostí. Centrum událostí je nakonfigurované s 16 oddíly. Na straně spotřeby potřebujete mechanismus, který může tyto události číst, konsolidovat a vyřadit agregaci do objektu blob úložiště, který se pak promítne na uživatelsky přívětivou webovou stránku.

Při návrhu příjemce v distribuovaném prostředí musí scénář zvládnout následující požadavky:

Škálování: Vytvořte více příjemců, přičemž každý příjemce přebírá vlastnictví čtení z několika oddílů služby Event Hubs.
Vyrovnávání zatížení: Dynamické zvýšení nebo snížení počtu příjemců Například když se do každého domu přidá nový typ senzoru (například detektor oxidu uhelnatého), zvýší se počet událostí. V takovém případě operátor (člověk) zvýší počet instancí spotřebitele. Fond příjemců pak může znovu vyvážit počet oddílů, které vlastní, a sdílet zatížení s nově přidanými příjemci.
Bezproblémový životopis při selhání: Pokud příjemce (příjemce A) selže (například virtuální počítač hostující příjemce náhle dojde k chybovému ukončení), můžou ostatní uživatelé vyzvednout oddíly vlastněné příjemcem A a pokračovat. Bod pokračování označovaný také jako kontrolní bod nebo posun by měl být přesně v okamžiku, kdy příjemce A selhal, nebo mírně před tím.
Využívání událostí: Zatímco předchozí tři body řeší správu příjemce, musí existovat kód, který bude využívat události a dělat s ním něco užitečného. Můžete ho například agregovat a nahrát do úložiště objektů blob.

Procesor událostí nebo klient příjemce

Pro splnění těchto požadavků nemusíte vytvářet vlastní řešení. Tyto funkce poskytují sady SDK služby Azure Event Hubs. V sadách .NET nebo Java SDK používáte klienta procesoru událostí (EventProcessorClient) a v sadách Python a JavaScript SDK použijete EventHubConsumerClient.

Pro většinu produkčních scénářů doporučujeme použít klienta procesoru událostí pro čtení a zpracování událostí. Klienti procesoru událostí můžou spolupracovat v kontextu skupiny příjemců pro dané centrum událostí. Klienti automaticky spravují distribuci a vyrovnávání práce, jakmile budou instance dostupné nebo nedostupné pro skupinu.

Sledování vlastnictví oddílů

Instance procesoru událostí obvykle vlastní a zpracovává události z jednoho nebo více oddílů. Vlastnictví oddílů je rovnoměrně rozděleno mezi všechny aktivní instance procesoru událostí přidružené ke kombinaci centra událostí a skupiny příjemců.

Každý procesor událostí má jedinečný identifikátor a vlastnictví deklarací identity oddílů přidáním nebo aktualizací položky v úložišti kontrolních bodů. Všechny instance procesoru událostí komunikují s tímto úložištěm pravidelně, aby aktualizovaly svůj vlastní stav zpracování a dozvěděly se o dalších aktivních instancích. Tato data se pak používají k vyrovnávání zatížení mezi aktivními procesory.

Příjem zpráv

Při vytváření procesoru událostí zadáte funkce, které zpracovávají události a chyby. Každé volání funkce, která zpracovává události, doručí jednu událost z konkrétního oddílu. Je to vaše zodpovědnost za zpracování této události. Pokud chcete zajistit, aby příjemce alespoň jednou zpracuje každou zprávu, musíte napsat vlastní kód s logikou opakování. Ale buďte opatrní ohledně otrávených zpráv.

Doporučujeme dělat věci poměrně rychle. To znamená, že zpracování je co nejmenší. Pokud potřebujete zapisovat do úložiště a provádět nějaké směrování, je lepší použít dvě skupiny příjemců a mít dva procesory událostí.

Vytváření kontrolních bodů

Vytváření kontrolních bodů je proces, pomocí kterého procesor událostí označí nebo potvrdí pozici poslední úspěšně zpracovávané události v rámci oddílu. Označení kontrolního bodu se obvykle provádí v rámci funkce, která zpracovává události a probíhá na základě jednotlivých oddílů v rámci skupiny příjemců.

Pokud se procesor událostí odpojí od oddílu, může jiná instance pokračovat ve zpracování oddílu na kontrolním bodu, který byl dříve potvrzen posledním procesorem tohoto oddílu v této skupině příjemců. Když se procesor připojí, předá posun do centra událostí a určí umístění, ve kterém se má začít číst. Tímto způsobem můžete pomocí kontrolního bodu označit události jako dokončené podřízenými aplikacemi a zajistit odolnost při výpadku procesoru událostí. Ke starším datům se můžete vrátit zadáním nižšího posunu z tohoto procesu vytváření kontrolních bodů.

Zabezpečení vláken a instance procesoru

Ve výchozím nastavení se funkce, která zpracovává události, volá postupně pro daný oddíl. Následné události a volání této funkce ze stejné fronty oddílů na pozadí, protože čerpadlo událostí pokračuje v spouštění na pozadí na jiných vláknech. Události z různých oddílů je možné zpracovávat souběžně a všechny sdílené stavy, ke kterým se přistupuje napříč oddíly, musí být synchronizované.