Vyrovnávání zatížení oddílů napříč několika instancemi vaší aplikace
Pokud chcete škálovat aplikaci pro zpracování událostí, můžete spustit několik instancí aplikace a mít mezi sebou vyrovnávání zatížení. Ve starších a zastaralých verzích EventProcessorHost můžete vyrovnávat zatížení mezi několika instancemi programu a událostmi kontrolního bodu při přijímání událostí. 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éž. Vývojový model je jednodušší pomocí událostí. Můžete se přihlásit k odběru událostí, které vás zajímají, registrací obslužné rutiny události. Pokud používáte starou verzi klientské knihovny, projděte si následující průvodce migrací: .NET, Java, Python a JavaScript.
Tento článek popisuje ukázkový scénář použití více instancí klientských aplikací ke čtení událostí z centra událostí. Poskytuje také podrobnosti o funkcích klienta procesoru událostí, které umožňují přijímat události z více oddílů najednou a vyrovnávat zatížení s jinými příjemci, kteří používají stejné centrum událostí a skupinu příjemců.
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 (filtrovat, agregovat atd.) a vyřadit agregaci do objektu blob úložiště, který se pak promítne na uživatelsky přívětivou webovou stránku.
Aplikace příjemce
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 ke zpracování událostí a udě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. Ve staré verzi sady SDK se jednalo o hostitele procesoru událostí (EventProcessorHost), který tyto funkce podporoval.
Pro většinu produkčních scénářů doporučujeme použít klienta procesoru událostí pro čtení a zpracování událostí. Klient procesoru je určený k zajištění robustního prostředí pro zpracování událostí napříč všemi oddíly centra událostí výkonným a odolným proti chybám a zároveň poskytuje způsob, jak kontrolovat jeho průběh. 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.
Vlastnictví oddílu
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. Nové instance se můžou připojit ke fondu zpracování a vertikálně navýšit kapacitu. Když dojde k výpadku instancí, ať už kvůli selháním nebo snížení kapacity, vlastnictví oddílu se elegantně převede na jiné aktivní procesory.
Záznamy vlastnictví oddílů v úložišti kontrolních bodů sledují obor názvů služby Event Hubs, název centra událostí, skupinu příjemců, identifikátor procesoru událostí (označovaný také jako vlastník), ID oddílu a čas poslední změny.
| Obor názvů služby Event Hubs | Název centra událostí | Skupina příjemců | Vlastník | ID oddílu | Čas poslední změny |
|---|---|---|---|---|---|
| mynamespace.servicebus.windows.net | myeventhub | myconsumergroup | 3be3f9d3-9d9e-4c50-9491-85ece8334ff6 | 0 | 2020-01-15T01:22:15 |
| mynamespace.servicebus.windows.net | myeventhub | myconsumergroup | f5cc5176-ce96-4bb4-bbaa-a0e3a9054ecf | 0 | 2020-01-15T01:22:17 |
| mynamespace.servicebus.windows.net | myeventhub | myconsumergroup | 72b980e9-2efc-4ca7-ab1b-ffd7bece8472 | 2 | 2020-01-15T01:22:10 |
| : | |||||
| : | |||||
| mynamespace.servicebus.windows.net | myeventhub | myconsumergroup | 844bd8fb-1f3a-4580-984d-6324f9e208af | 15 | 2020-01-15T01:22:00 |
Každá instance procesoru událostí získá vlastnictví oddílu a začne zpracovávat oddíl z posledního známého kontrolního bodu. Pokud dojde k selhání procesoru (virtuální počítač se vypne), ostatní instance ho zjistí tak, že se podívá na čas poslední změny. Jiné instance se pokusí získat vlastnictví oddílů, které dříve vlastní neaktivní instance. Úložiště kontrolních bodů zaručuje, že pouze jedna z instancí úspěšně deklaruje vlastnictví oddílu. V libovolném časovém okamžiku tedy existuje maximálně jeden procesor, který přijímá události z oddílu.
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í.
CheckPoint
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ů.
Při provedení kontrolního bodu pro označení události jako zpracované se přidá nebo aktualizuje položka v úložišti kontrolních bodů o posun a pořadové číslo události. Uživatelé by měli rozhodnout o frekvenci aktualizace kontrolního bodu. Aktualizace po úspěšném zpracování události může mít vliv na výkon a náklady, protože aktivuje operaci zápisu do podkladového úložiště kontrolních bodů. Kontrolní bod každé události také značí vzor zasílání zpráv ve frontě, pro který může být fronta Service Bus lepší volbou než centrum událostí. Myšlenkou služby Event Hubs je, že ve velkém měřítku získáte "aspoň jednou" doručení. Díky idempotentním podřízeným systémům je snadné se zotavit z selhání nebo restartování, které způsobí, že se stejné události přijímají vícekrát.
Při používání služby Azure Blob Storage jako úložiště kontrolních bodů postupujte podle těchto doporučení:
- Pro každou skupinu příjemců použijte samostatný kontejner. Můžete použít stejný účet úložiště, ale pro každou skupinu použít jeden kontejner.
- Nepoužívejte kontejner pro nic jiného a nepoužívejte účet úložiště pro nic jiného.
- Účet úložiště by měl být ve stejné oblasti jako nasazená aplikace. Pokud je aplikace místní, zkuste zvolit nejbližší možnou oblast.
Na stránce účtu úložiště na webu Azure Portal v části Blob Service se ujistěte, že jsou zakázaná následující nastavení.
- Hierarchický obor názvů
- Obnovitelné odstranění objektu blob
- Vytváření verzí
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é.
Související obsah
Podívejte se na následující rychlé starty: