Dela via

Event Hubs och tillförlitlighet

  • Artikel

Azure Event Hubs är en skalbar händelsebearbetningstjänst som matar in och bearbetar stora mängder händelser och data, med låg svarstid och hög tillförlitlighet. Den kan ta emot och behandla miljoner händelser per sekund. Data som skickas till en händelsehubb kan omvandlas och lagras med hjälp av valfri realtidsanalysprovider eller batchbearbetning och lagringskort.

Mer information om hur du använder Event Hubs finns i Azure Event Hubs dokumentation för att lära dig hur du använder Event Hubs för att mata in miljontals händelser per sekund från anslutna enheter och program.

Information om hur användning av Event Hubs skapar en mer tillförlitlig arbetsbelastning finns i Azure Event Hubs – Geo-haveriberedskap.

Följande avsnitt är specifika för Azure Event Hubs och tillförlitlighet:

  • Designöverväganden
  • Checklista för konfiguration
  • Rekommenderade konfigurationsalternativ
  • Källartefakter

Designöverväganden

Azure Event Hubs tillhandahåller ett serviceavtal för drifttid. Mer information finns i SLA för Event Hubs.

Checklista

Har du konfigurerat Azure Event Hubs med tillförlitlighet i åtanke?

  • Skapa SendOnly- och ListenOnly-principer för händelseutgivaren respektive konsumenten.
  • När du använder SDK:t för att skicka händelser till Event Hubs kontrollerar du att undantagen som genereras av återförsöksprincipen (EventHubsException eller OperationCancelledException) fångas korrekt.
  • I scenarier med högt dataflöde använder du batchbaserade händelser.
  • Varje konsument kan läsa händelser från en till 32 partitioner.
  • När du utvecklar nya program använder du EventProcessorClient (.NET och Java) eller EventHubConsumerClient (Python och JavaScript) som klient-SDK.
  • Som en del av din lösningsomfattande tillgänglighets- och haveriberedskapsstrategi bör du överväga att aktivera haveriberedskapsalternativet event hubs geo.
  • När en lösning har ett stort antal oberoende händelseutgivare bör du överväga att använda Event Publishers för detaljerad åtkomstkontroll.
  • Publicera inte händelser till en specifik partition.
  • När du publicerar händelser ofta använder du AMQP-protokollet när det är möjligt.
  • Antalet partitioner återspeglar graden av nedströmsparallellitet som du kan uppnå.
  • Se till att varje program som förbrukar använder en separat konsumentgrupp och att endast en aktiv mottagare per konsumentgrupp finns på plats.
  • När du använder capture-funktionen bör du noga överväga konfigurationen av tidsfönstret och filstorleken, särskilt med låga händelsevolymer.

Konfigurationsrekommendationer

Överväg följande rekommendationer för att optimera tillförlitligheten när du konfigurerar Azure Event Hubs:

Rekommendation Description
När du använder SDK:t för att skicka händelser till Event Hubs kontrollerar du att undantagen som genereras av återförsöksprincipen (EventHubsException eller OperationCancelledException) fångas korrekt. När du använder HTTPSkontrollerar du att ett korrekt återförsöksmönster implementeras.
I scenarier med högt dataflöde använder du batchbaserade händelser. Tjänsten levererar en json matris med flera händelser till prenumeranterna, i stället för en matris med en händelse. Det tidskrävande programmet måste bearbeta dessa matriser.
Varje konsument kan läsa händelser från en till 32 partitioner. För att uppnå maximal skalning på sidan av det förbrukande programmet bör varje konsument läsa från en enda partition.
När du utvecklar nya program använder du EventProcessorClient (.NET och Java) eller EventHubConsumerClient (Python och JavaScript) som klient-SDK. EventProcessorHost har blivit inaktuell.
Som en del av din lösningsomfattande tillgänglighets- och haveriberedskapsstrategi bör du överväga att aktivera haveriberedskapsalternativet event hubs geo. Med det här alternativet kan du skapa ett sekundärt namnområde i en annan region. Endast det aktiva namnområdet tar emot meddelanden när som helst. Meddelanden och händelser replikeras inte till den sekundära regionen. RTO för den regionala redundansväxlingen är upp till 30 minuter. Bekräfta att denna RTO överensstämmer med kundens krav och passar i den bredare tillgänglighetsstrategin. Om en högre RTO krävs bör du överväga att implementera ett redundansmönster på klientsidan.
När en lösning har ett stort antal oberoende händelseutgivare bör du överväga att använda Event Publishers för detaljerad åtkomstkontroll. Händelseutgivare ställer automatiskt in partitionsnyckeln till utgivarens namn, så den här funktionen bör endast användas om händelserna kommer från alla utgivare jämnt.
Publicera inte händelser till en specifik partition. Om det är viktigt att beställa händelser implementerar du beställning nedströms eller använder en annan meddelandetjänst i stället.
När du publicerar händelser ofta använder du AMQP-protokollet när det är möjligt. AMQP har högre nätverkskostnader när sessionen initieras, men HTTPS kräver TLS-omkostnader för varje begäran. AMQP har högre prestanda för frekventa utfärdare.
Antalet partitioner återspeglar graden av nedströmsparallellitet som du kan uppnå. För maximalt dataflöde använder du det maximala antalet partitioner (32) när du skapar händelsehubben. Det maximala antalet partitioner gör att du kan skala upp till 32 samtidiga bearbetningsentiteter och erbjuder den högsta tillgängligheten för att skicka och ta emot.
När du använder capture-funktionen bör du noga överväga konfigurationen av tidsfönstret och filstorleken, särskilt med låga händelsevolymer. Data Lake debiteras för minimal filstorlek för lagring (gen1) eller minimal transaktionsstorlek (gen2). Om du ställer in tidsfönstret så lågt att filen inte har nått minsta storlek medför du extra kostnad.

Källartefakter

Använd följande fråga för att hitta Event Hubs-namnområden med Basic SKU:

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

Nästa steg

Event Hubs och driftskvalitet