Share via

Event Hubs a spolehlivost

  • Článek

Azure Event Hubs je škálovatelná služba zpracování událostí, která ingestuje a zpracovává velké objemy událostí a dat s nízkou latencí a vysokou spolehlivostí. Dokáže přijímat a zpracovávat miliony událostí za sekundu. Data odesílaná do centra událostí se dají transformovat a ukládat pomocí libovolného poskytovatele analýz v reálném čase nebo adaptérů dávkování a úložiště.

Další informace o používání služby Event Hubs najdete v dokumentaci k Azure Event Hubs, kde se dozvíte, jak pomocí služby Event Hubs ingestovat miliony událostí za sekundu z připojených zařízení a aplikací.

Informace o tom, jak použití služby Event Hubs vytvoří spolehlivější úlohu, najdete v tématu Azure Event Hubs – Geografické zotavení po havárii.

Následující části jsou specifické pro Azure Event Hubs a spolehlivost:

  • Na co dát pozor při navrhování
  • Kontrolní seznam konfigurace
  • Doporučené možnosti konfigurace
  • Zdrojové artefakty

Na co dát pozor při navrhování

Azure Event Hubs poskytuje smlouvu SLA o době provozu. Další informace najdete v tématu smlouva SLA pro službu Event Hubs.

Kontrolní seznam

Nakonfigurovali jste Azure Event Hubs se spolehlivostí?

  • Vytvořte zásady SendOnly a ListenOnly pro vydavatele a příjemce události.
  • Pokud používáte sadu SDK k odesílání událostí do služby Event Hubs, ujistěte se, že jsou správně zachyceny výjimky vyvolané zásadou opakování (EventHubsException nebo OperationCancelledException).
  • Ve scénářích s vysokou propustností použijte dávkové události.
  • Každý příjemce může číst události od jednoho do 32 oddílů.
  • Při vývoji nových aplikací použijte EventProcessorClient jako klientskou sadu SDK (.NET a Java) nebo EventHubConsumerClient (Python a JavaScript).
  • V rámci vaší strategie dostupnosti a zotavení po havárii v rámci celého řešení zvažte povolení možnosti geografického zotavení po havárii služby Event Hubs.
  • Pokud řešení obsahuje velký počet nezávislých vydavatelů událostí, zvažte použití vydavatelů událostí pro podrobné řízení přístupu.
  • Nepublikujte události do konkrétního oddílu.
  • Při častém publikování událostí používejte protokol AMQP, pokud je to možné.
  • Počet oddílů odráží stupeň podřízeného paralelismu, který můžete dosáhnout.
  • Zajistěte, aby každá aplikace, která využívá, používala samostatnou skupinu příjemců a aby na jednu skupinu příjemců byl jen jeden aktivní příjemce.
  • Při použití funkce Capture pečlivě zvažte konfiguraci časového okna a velikosti souboru, zejména v případě nízkého objemu událostí.

Doporučení ke konfiguraci

Při konfiguraci Azure Event Hubs zvažte následující doporučení pro optimalizaci spolehlivosti:

Doporučení Description
Pokud používáte sadu SDK k odesílání událostí do služby Event Hubs, ujistěte se, že jsou správně zachyceny výjimky vyvolané zásadou opakování (EventHubsException nebo OperationCancelledException). Pokud používáte HTTPS, ujistěte se, že je implementovaný správný vzor opakování.
Ve scénářích s vysokou propustností použijte dávkové události. Služba doručí odběratelům json pole s více událostmi místo pole s jednou událostí. Přijímající aplikace musí tato pole zpracovat.
Každý příjemce může číst události od jednoho do 32 oddílů. Aby bylo dosaženo maximálního škálování na straně spotřebovávající aplikace, měl by každý příjemce číst z jednoho oddílu.
Při vývoji nových aplikací použijte EventProcessorClient jako klientskou sadu SDK (.NET a Java) nebo EventHubConsumerClient (Python a JavaScript). EventProcessorHost byla zastaralá.
V rámci vaší strategie dostupnosti a zotavení po havárii v rámci celého řešení zvažte povolení možnosti geografického zotavení po havárii služby Event Hubs. Tato možnost umožňuje vytvořit sekundární obor názvů v jiné oblasti. Zprávy obdrží kdykoli pouze aktivní obor názvů. Zprávy a události se nereplikují do sekundární oblasti. Plánovaná doba obnovení regionálního převzetí služeb při selhání je až 30 minut. Ověřte, že tato plánovaná doba obnovení (RTO) odpovídá požadavkům zákazníka a odpovídá širší strategii dostupnosti. Pokud se vyžaduje vyšší rto, zvažte implementaci modelu převzetí služeb při selhání na straně klienta.
Pokud řešení obsahuje velký počet nezávislých vydavatelů událostí, zvažte použití vydavatelů událostí pro podrobné řízení přístupu. Vydavatelé událostí automaticky nastavují klíč oddílu na název vydavatele, takže tato funkce by měla být použita pouze v případě, že události pocházejí ze všech vydavatelů rovnoměrně.
Nepublikujte události do konkrétního oddílu. Pokud je řazení událostí nezbytné, implementujte řazení ve směru podřízených dat nebo místo toho použijte jinou službu zasílání zpráv.
Při častém publikování událostí používejte protokol AMQP, pokud je to možné. AMQP má vyšší náklady na síť při inicializaci relace, ale HTTPS vyžaduje režii protokolu TLS pro každý požadavek. AMQP má pro často používané zdroje vyšší výkon.
Počet oddílů odráží stupeň podřízeného paralelismu, který můžete dosáhnout. Pro dosažení maximální propustnosti při vytváření centra událostí použijte maximální počet oddílů (32). Maximální počet oddílů vám umožní vertikálně navýšit kapacitu na 32 souběžné entity zpracování a nabídne nejvyšší dostupnost odesílání a přijímání.
Při použití funkce Capture pečlivě zvažte konfiguraci časového okna a velikosti souboru, zejména v případě nízkého objemu událostí. Data Lake bude účtovat minimální velikost souboru pro úložiště (Gen1) nebo minimální velikost transakce (Gen2). Pokud nastavíte časové období tak nízké, že soubor nedosáhl minimální velikosti, budou se vám účtovat další poplatky.

Zdrojové artefakty

Pokud chcete najít obory názvů služby Event Hubs se skladovou položkou Basic , použijte následující dotaz:

Resources 
| where type == 'microsoft.eventhub/namespaces'
| where sku.name == 'Basic'
| project resourceGroup, name, sku.name

Další krok

Event Hubs a efektivita provozu