Funkcje i terminologia w usłudze Azure Event Hubs

  • Artykuł
  • Czas czytania: 16 min

Azure Event Hubs to skalowalna usługa przetwarzania zdarzeń, która pozyskuje i przetwarza duże ilości zdarzeń i danych, z małym opóźnieniem i wysoką niezawodnością. Zobacz Co to jest usługa Event Hubs? aby zapoznać się z omówieniem wysokiego poziomu.

Ten artykuł opiera się na informacjach w artykule omówienia i zawiera szczegółowe informacje techniczne i implementacji dotyczące składników i funkcji usługi Event Hubs.

Porada

Obsługa protokołu dla klientów platformy Apache Kafka (wersje >=1.0) zapewnia punkty końcowe sieci, które umożliwiają aplikacjom utworzonym do korzystania z platformy Apache Kafka z dowolnym klientem do korzystania z usługi Event Hubs. Większość istniejących aplikacji platformy Kafka można po prostu ponownie skonfigurować tak, aby wskazywała przestrzeń nazw centrum zdarzeń zamiast serwera rozruchowego klastra platformy Kafka.

Z perspektywy kosztów, nakładu pracy operacyjnej i niezawodności Azure Event Hubs to świetna alternatywa dla wdrażania i obsługi własnych klastrów kafka i zookeeper oraz ofert platformy Kafka jako usługa, które nie są natywne dla platformy Azure.

Oprócz korzystania z tych samych podstawowych funkcji co broker platformy Apache Kafka uzyskujesz również dostęp do funkcji usługi Azure Event Hub, takich jak automatyczne przetwarzanie wsadowe i archiwizowanie za pośrednictwem funkcji przechwytywania usługi Event Hubs, automatyczne skalowanie i równoważenie, odzyskiwanie po awarii, obsługa stref dostępności neutralnej pod względem kosztów, elastyczna i bezpieczna integracja sieci oraz obsługa wielu protokołów, w tym protokół AMQP-over-WebSocket.

Przestrzeń nazw

Przestrzeń nazw usługi Event Hubs to kontener zarządzania dla centrów zdarzeń (lub tematów w parlance platformy Kafka). Zapewnia on zintegrowane z systemem DNS punkty końcowe sieci oraz szereg funkcji kontroli dostępu i zarządzania integracją sieci, takich jak filtrowanie adresów IP, punkt końcowy usługi sieci wirtualnej i Private Link.

Obraz przedstawiający przestrzeń nazw usługi Event Hubs

Wydawcy zdarzeń

Każda jednostka, która wysyła dane do centrum zdarzeń, jest wydawcą zdarzeń (synonimem używanym z producentem zdarzeń). Wydawcy zdarzeń mogą publikować zdarzenia przy użyciu protokołu HTTPS lub AMQP 1.0 lub protokołu Kafka. Wydawcy zdarzeń używają autoryzacji opartej na usłudze Azure Active Directory z tokenami JWT wystawionymi przez OAuth2 lub tokenem sygnatury dostępu współdzielonego specyficznego dla centrum zdarzeń w celu uzyskania dostępu do publikowania.

Publikowanie zdarzenia

Zdarzenie można opublikować za pośrednictwem protokołu AMQP 1.0, protokołu Kafka lub PROTOKOŁU HTTPS. Usługa Event Hubs udostępnia interfejs API REST i biblioteki klienta .NET, Java, Python, JavaScript i Go do publikowania zdarzeń w centrum zdarzeń. W przypadku innych środowisk uruchomieniowych i platform można używać dowolnego klienta protokołu AMQP 1.0, na przykład Apache Qpid.

Decyzja o korzystaniu z protokołu AMQP lub HTTPS jest specyficzna dla scenariusza użycia. Protokół AMQP wymaga ustanowienia trwałego gniazda dwukierunkowego oprócz protokołu TLS lub SSL/ TLS. Protokół AMQP ma wyższe koszty sieci podczas inicjowania sesji, jednak protokół HTTPS wymaga dodatkowego obciążenia protokołu TLS dla każdego żądania. Protokół AMQP ma wyższą wydajność dla częstych wydawców i może osiągnąć znacznie mniejsze opóźnienia w przypadku użycia z asynchronicznym kodem publikowania.

Zdarzenia można publikować pojedynczo lub wsadowo. Pojedyncza publikacja ma limit wynoszący 1 MB, niezależnie od tego, czy jest to pojedyncze zdarzenie, czy partia. Zdarzenia publikowania większe niż ten próg zostaną odrzucone.

Przepływność usługi Event Hubs jest skalowana przy użyciu partycji i alokacji jednostek przepływności (zobacz poniżej). Najlepszym rozwiązaniem jest, aby wydawcy nie wiedzieli o określonym modelu partycjonowania wybranym dla centrum zdarzeń i określić tylko klucz partycji używany do spójnego przypisywania powiązanych zdarzeń do tej samej partycji.

Klucze partycji

Usługa Event Hubs zapewnia, że wszystkie zdarzenia współużytkujące wartość klucza partycji są przechowywane razem i dostarczane w kolejności przybycia. Jeśli klucze partycji są używane wraz z zasadami wydawcy, to tożsamość wydawcy i wartość klucza partycji muszą być zgodne. W przeciwnym razie wystąpi błąd.

Przechowywanie zdarzeń

Opublikowane zdarzenia są usuwane z centrum zdarzeń na podstawie konfigurowalnych zasad przechowywania na podstawie czasu. Oto kilka ważnych kwestii:

  • Wartość domyślna i najkrótszy możliwy okres przechowywania to 1 dzień (24 godziny).
  • W przypadku usługi Event Hubs w warstwie Standardowa maksymalny okres przechowywania wynosi 7 dni.
  • W przypadku usługi Event Hubs Premium i Dedykowane maksymalny okres przechowywania wynosi 90 dni.
  • Jeśli zmienisz okres przechowywania, dotyczy to wszystkich zdarzeń, w tym zdarzeń, które znajdują się już w centrum zdarzeń.

Usługa Event Hubs zachowuje zdarzenia dla skonfigurowanego czasu przechowywania, który ma zastosowanie we wszystkich partycjach. Zdarzenia są automatycznie usuwane po osiągnięciu okresu przechowywania. Jeśli określisz okres przechowywania jednego dnia, zdarzenie stanie się niedostępne dokładnie 24 godziny po zaakceptowaniu. Nie można jawnie usuwać zdarzeń.

Jeśli musisz archiwizować zdarzenia poza dozwolonym okresem przechowywania, możesz je automatycznie przechowywać w usłudze Azure Storage lub Azure Data Lake, włączając funkcję przechwytywania usługi Event Hubs. Jeśli konieczne jest wyszukiwanie lub analizowanie takich głębokich archiwów, można je łatwo zaimportować do Azure Synapse lub innych podobnych sklepów i platform analitycznych.

Przyczyną ograniczenia przechowywania danych w usłudze Event Hubs na podstawie czasu jest zapobieganie uwięzieniu dużych ilości historycznych danych klientów w magazynie głębokim, który jest indeksowany tylko przez sygnaturę czasową i umożliwia dostęp sekwencyjny. Filozofia architektury jest taka, że dane historyczne wymagają bogatszego indeksowania i bardziej bezpośredniego dostępu niż interfejs zdarzeń w czasie rzeczywistym zapewniany przez usługę Event Hubs lub Kafka. Aparaty strumieni zdarzeń nie nadają się do odegrania roli magazynów danych ani długoterminowych archiwów na potrzeby określania źródła zdarzeń.

Uwaga

Usługa Event Hubs jest aparatem strumienia zdarzeń w czasie rzeczywistym i nie jest przeznaczona do użycia zamiast bazy danych i/lub jako trwałego magazynu nieskończonie przechowywanych strumieni zdarzeń.

Im głębsza historia strumienia zdarzeń, tym więcej będzie potrzebnych indeksów pomocniczych, aby znaleźć konkretny historyczny fragment danego strumienia. Inspekcja ładunków zdarzeń i indeksowania nie mieści się w zakresie funkcji usługi Event Hubs (lub Apache Kafka). Bazy danych i wyspecjalizowane magazyny analityczne oraz aparaty, takie jak Azure Data Lake Store, Azure Data Lake Analytics i Azure Synapse, są w związku z tym znacznie lepiej dostosowane do przechowywania zdarzeń historycznych.

Funkcja Event Hubs Capture integruje się bezpośrednio z Azure Blob Storage i Azure Data Lake Storage oraz dzięki tej integracji umożliwia również przepływanie zdarzeń bezpośrednio do Azure Synapse.

Zasady wydawcy

Usługa Event Hubs umożliwia szczegółową kontrolę nad wydawcami zdarzeń za pomocą zasad wydawcy. Zasady wydawcy to funkcje środowiska uruchomieniowego zaprojektowane w celu ułatwienia działania dużej liczby niezależnych wydawców zdarzeń. Dzięki zasadom wydawcy każdy wydawca używa swojego unikatowego identyfikatora podczas publikowania zdarzeń w centrum zdarzeń przy użyciu następującego mechanizmu:

//<my namespace>.servicebus.windows.net/<event hub name>/publishers/<my publisher name>

Nie jest konieczne wcześniejsze tworzenie nazw wydawców, ale muszą one być zgodne z tokenem sygnatury dostępu współdzielonego użytym podczas publikowania zdarzenia w celu zapewnienia niezależnych tożsamości wydawcy. W przypadku korzystania z zasad wydawcy wartość PartitionKey musi być ustawiona na nazwę wydawcy. Aby zapewnić prawidłowe działanie, te wartości muszą być zgodne.

Przechwytywanie

Funkcja przechwytywania usługi Event Hubs umożliwia automatyczne przechwytywanie danych przesyłanych strumieniowo w usłudze Event Hubs i zapisywanie ich na wybranym koncie usługi Blob Storage lub na koncie Azure Data Lake Storage. Możesz włączyć przechwytywanie z Azure Portal i określić minimalny rozmiar i przedział czasu do wykonania przechwytywania. Za pomocą funkcji przechwytywania usługi Event Hubs należy określić własne konto i kontener Azure Blob Storage lub konto Azure Data Lake Storage, z których jeden jest używany do przechowywania przechwyconych danych. Przechwycone dane są zapisywane w formacie Apache Avro.

Obraz przedstawiający przechwytywanie danych usługi Event Hubs w usłudze Azure Storage lub Azure Data Lake Storage

Pliki utworzone przez funkcję Event Hubs Capture mają następujący schemat Avro:

Obraz przedstawiający strukturę przechwyconych danych

Uwaga

Jeśli nie używasz edytora kodu w Azure Portal, możesz przechwytywać dane przesyłane strumieniowo w usłudze Event Hubs na koncie Azure Data Lake Storage Gen2 w formacie Parquet. Aby uzyskać więcej informacji, zobacz Jak przechwytywać dane z usługi Event Hubs w formacie Parquet i Samouczek: przechwytywanie danych usługi Event Hubs w formacie Parquet i analizowanie za pomocą usługi Azure Synapse Analytics.

Partycje

Usługa Event Hubs organizuje sekwencje zdarzeń wysyłanych do centrum zdarzeń w co najmniej jednej partycji. Po nadejściu nowszych zdarzeń są one dodawane na końcu tej sekwencji.

Event Hubs

Partycja może być uważana za "dziennik zatwierdzania". Partycje przechowują dane zdarzeń zawierające treść zdarzenia, zdefiniowaną przez użytkownika torbę właściwości opisującą zdarzenie, metadane, takie jak przesunięcie w partycji, jego numer w sekwencji strumienia i sygnatura czasowa po stronie usługi, w której została zaakceptowana.

Diagram przedstawiający starszą lub nowszą sekwencję zdarzeń.

Zalety korzystania z partycji

Usługa Event Hubs została zaprojektowana w celu ułatwienia przetwarzania dużych ilości zdarzeń, a partycjonowanie pomaga w tym na dwa sposoby:

  • Mimo że usługa Event Hubs jest usługą PaaS, znajduje się pod nią rzeczywistość fizyczna i utrzymuje dziennik, który zachowuje kolejność zdarzeń, wymaga, aby te zdarzenia były przechowywane razem w magazynie bazowym i jego replikach oraz które skutkuje pułapem przepływności dla takiego dziennika. Partycjonowanie umożliwia używanie wielu dzienników równoległych dla tego samego centrum zdarzeń i w związku z tym mnożenie dostępnej pojemności nieprzetworzonej przepływności we/wy.
  • Twoje aplikacje muszą być w stanie nadążyć za przetwarzaniem ilości zdarzeń wysyłanych do centrum zdarzeń. Może to być złożone i wymaga znacznej, skalowanej w poziomie, równoległej pojemności przetwarzania. Pojemność pojedynczego procesu do obsługi zdarzeń jest ograniczona, więc potrzebujesz kilku procesów. Partycje są sposobem, w jaki rozwiązanie jest zasilane z tych procesów, a jednocześnie zapewnia, że każde zdarzenie ma jasnego właściciela przetwarzania.

Liczba partycji

Liczba partycji jest określona w momencie tworzenia centrum zdarzeń. Musi to być od 1 do maksymalnej liczby partycji dozwolonych dla każdej warstwy cenowej. Aby uzyskać limit liczby partycji dla każdej warstwy, zobacz ten artykuł.

Zalecamy wybranie co najmniej tylu partycji, zgodnie z oczekiwaniami, które są wymagane podczas szczytowego obciążenia aplikacji dla tego konkretnego centrum zdarzeń. Nie można zmienić liczby partycji dla centrum zdarzeń po jego utworzeniu z wyjątkiem centrum zdarzeń w dedykowanym klastrze i warstwie Premium. Liczba partycji centrum zdarzeń w dedykowanym klastrze usługi Event Hubs może zostać zwiększona po utworzeniu centrum zdarzeń, ale rozkład strumieni między partycjami zmieni się po zakończeniu mapowania kluczy partycji na partycje, dlatego należy spróbować uniknąć takich zmian, jeśli względna kolejność zdarzeń ma znaczenie w aplikacji.

Ustawienie liczby partycji na maksymalną dozwoloną wartość jest kuszące, ale zawsze należy pamiętać, że strumienie zdarzeń muszą być ustrukturyzowane tak, aby można było rzeczywiście korzystać z wielu partycji. Jeśli potrzebujesz zachowania bezwzględnej kolejności we wszystkich zdarzeniach lub tylko kilku podstreamach, możesz nie być w stanie korzystać z wielu partycji. Ponadto wiele partycji sprawia, że strona przetwarzania jest bardziej złożona.

Nie ma znaczenia, ile partycji znajduje się w centrum zdarzeń, jeśli chodzi o ceny. Zależy to od liczby jednostek cenowych (jednostek przepływności (TU) dla warstwy Standardowa, jednostek przetwarzania (PU) dla warstwy Premium i jednostek pojemności (CU ) dla dedykowanej warstwy) dla przestrzeni nazw lub dedykowanego klastra. Na przykład centrum zdarzeń warstwy Standardowa z 32 partycjami lub z 1 partycją ponosi dokładnie ten sam koszt, gdy przestrzeń nazw jest ustawiona na 1 pojemność tu. Ponadto można skalować jednostki TU lub jednostki PU w przestrzeni nazw lub jednostkach CU dedykowanego klastra niezależnie od liczby partycji.

Ponieważ partycja jest mechanizmem organizacji danych, który umożliwia publikowanie i używanie danych w sposób równoległy, zalecamy równoważenie jednostek skalowania (jednostek TU, jednostek PU lub jednostek CU) i partycji w celu osiągnięcia optymalnej skali. Ogólnie rzecz biorąc, zalecamy maksymalną przepływność wynoszącą 1 MB/s na partycję. W związku z tym regułą obliczania liczby partycji byłoby podzielenie maksymalnej oczekiwanej przepływności o 1 MB/s. Jeśli na przykład przypadek użycia wymaga 20 MB/s, zaleca się wybranie co najmniej 20 partycji w celu uzyskania optymalnej przepływności.

Jeśli jednak masz model, w którym aplikacja ma koligację z określoną partycją, zwiększenie liczby partycji może nie być korzystne. Aby uzyskać więcej informacji, zobacz dostępność i spójność.

Mapowanie zdarzeń na partycje

Klucz partycji służy do mapowania danych zdarzeń przychodzących na określone partycje na potrzeby organizowania danych. Klucz partycji to wartość podawana przez nadawcę przekazywana do centrum zdarzeń. Jest on przetwarzany przez statyczną funkcję tworzenia skrótu, za pomocą której tworzone jest przypisanie partycji. Jeśli nie określisz klucza partycji podczas publikowania zdarzenia, używane jest przypisanie działania okrężnego.

Wydawca zdarzeń ma informacje tylko o kluczu partycji, a nie partycji, na której publikowane są zdarzenia. To oddzielenie klucza od partycji powoduje, że nadawca nie musi wiedzieć zbyt dużo o przetwarzaniu podrzędnym. Unikatowa tożsamość urządzenia lub użytkownika stanowi dobry klucz partycji, ale inne atrybuty, takie jak lokalizacja geograficzna, mogą również zostać użyte do grupowania powiązanych zdarzeń w jedną partycję.

Określenie klucza partycji umożliwia przechowywanie powiązanych zdarzeń w tej samej partycji i w dokładnej kolejności, w jakiej zostały dostarczone. Klucz partycji jest ciągiem pochodzącym z kontekstu aplikacji i identyfikuje zniechętość zdarzeń. Sekwencja zdarzeń zidentyfikowanych przez klucz partycji jest strumieniem. Partycja to multipleksowany magazyn dzienników dla wielu takich strumieni.

Uwaga

Chociaż zdarzenia można wysyłać bezpośrednio do partycji, nie zalecamy jej, zwłaszcza gdy wysoka dostępność jest dla Ciebie ważna. Obniża dostępność centrum zdarzeń na poziomie partycji. Aby uzyskać więcej informacji, zobacz Dostępność i spójność.

Tokeny sygnatur dostępu współdzielonego

Usługa Event Hubs używa sygnatur dostępu współdzielonego, które są dostępne na poziomie przestrzeni nazw i centrum zdarzeń. Token sygnatury dostępu współdzielonego jest generowany na podstawie klucza sygnatury dostępu współdzielonego i jest skrótem SHA adresu URL zakodowanym w określonym formacie. Usługa Event Hubs może ponownie wygenerować skrót przy użyciu nazwy klucza (zasad) i tokenu, a tym samym uwierzytelnić nadawcę. Zwykle tokeny sygnatury dostępu współdzielonego dla wydawców zdarzeń są tworzone jedynie z uprawnieniami do wysyłania w określonym centrum zdarzeń. Ten mechanizm adresu URL tokenu sygnatury dostępu współdzielonego stanowi podstawę do identyfikacji wydawcy wprowadzoną w ramach zasad wydawcy. Aby uzyskać więcej informacji na temat pracy z sygnaturą dostępu współdzielonego, zobacz Shared Access Signature Authentication with Service Bus (Uwierzytelnianie za pomocą sygnatury dostępu współdzielonego przy użyciu usługi Service Bus).

Odbiorcy zdarzeń

Każda jednostka, która odczytuje dane zdarzenia z centrum zdarzeń, jest odbiorcą zdarzenia. Wszyscy odbiorcy usługi Event Hubs nawiązują połączenie za pomocą sesji protokołu AMQP 1.0, w ramach której zdarzenia są dostarczane, gdy tylko staną się dostępne. Klient nie musi sondować dostępności danych.

Grupy odbiorców

Mechanizm publikowania/subskrybowania usługi Event Hubs jest włączony za pośrednictwem grup odbiorców. Grupa odbiorców stanowi widok (stan, pozycja lub przesunięcie) całego centrum zdarzeń. Dzięki grupom odbiorców wiele aplikacji odbiorczych może mieć osobny widok strumienia zdarzeń i niezależnie odczytywać strumień we własnym tempie i przy użyciu własnego przesunięcia.

W architekturze przetwarzania strumieni każda aplikacja podrzędna odpowiada grupie odbiorców. Jeśli chcesz zapisać dane zdarzenia do magazynu długoterminowego, to ta aplikacja edytora magazynu odpowiada grupie odbiorców. Przetwarzanie złożonych zdarzeń może być wtedy wykonywane przez inną, oddzielną grupę odbiorców. Dostęp do partycji można uzyskać tylko za pośrednictwem grupy odbiorców. Zawsze istnieje domyślna grupa odbiorców w centrum zdarzeń i można utworzyć maksymalną liczbę grup odbiorców dla odpowiedniej warstwy cenowej.

W partycji na grupę odbiorców może znajdować się co najwyżej 5 równoczesnych czytelników; zaleca się jednak, aby na partycji na grupę odbiorców znajdował się tylko jeden aktywny odbiornik. W ramach jednej partycji każdy czytelnik otrzymuje wszystkie zdarzenia. Jeśli masz wielu czytelników na tej samej partycji, przetwarzasz zduplikowane zdarzenia. Musisz to zrobić w kodzie, co może nie być proste. Jednak jest to prawidłowe podejście w niektórych scenariuszach.

Niektórzy klienci oferowani przez zestawy SDK platformy Azure to inteligentni agenci konsumentów, którzy automatycznie zarządzają szczegółami zapewniającymi, że każda partycja ma jeden czytnik i czy wszystkie partycje dla centrum zdarzeń są odczytywane. Dzięki temu kod może skupić się na przetwarzaniu odczytanych zdarzeń z centrum zdarzeń, dzięki czemu może ignorować wiele szczegółów partycji. Aby uzyskać więcej informacji, zobacz Łączenie z partycją.

W poniższych przykładach przedstawiono konwencję identyfikatora URI grupy odbiorców:

//<my namespace>.servicebus.windows.net/<event hub name>/<Consumer Group #1>
//<my namespace>.servicebus.windows.net/<event hub name>/<Consumer Group #2>

Na poniższym rysunku przedstawiono architekturę przetwarzania strumienia usługi Event Hubs:

Architektura usługi Event Hubs

Przesunięcia strumienia

Przesunięcie to pozycja zdarzenia w partycji. Przesunięcie można traktować jako kursor po stronie klienta. Przesunięcie to numer bajtu zdarzenia. To przesunięcie umożliwi odbiorcy zdarzeń (czytnikowi) określenie punktu w strumieniu zdarzeń, od którego ma zostać rozpoczęte odczytywanie zdarzeń. Przesunięcie można określić jako sygnaturę czasową lub wartość przesunięcia. Odbiorcy są zobowiązani do przechowywania własnych wartości przesunięcia poza usługą Event Hubs. W ramach partycji każde zdarzenie zawiera przesunięcie.

Przesunięcie partycji

Tworzenie punktów kontrolnych

Tworzenie punktów kontrolnych jest procesem, za pomocą którego czytniki oznaczają lub zatwierdzają swoją pozycję w sekwencji zdarzeń partycji. Odpowiedzialność za tworzenie punktów kontrolnych spoczywa na odbiorcy i odbywa się dla każdej partycji w ramach grupy odbiorców. Ta odpowiedzialność oznacza, że dla każdej grupy odbiorców każdy czytnik partycji musi śledzić swoją bieżącą pozycję w strumieniu zdarzeń i może poinformować usługi, gdy uzna, że strumień danych jest pełny.

Jeśli czytnik rozłączy się od partycji, po swoim ponownym połączeniu rozpoczyna odczyt punktu kontrolnego, który został wcześniej przesłany przez ostatni czytnik tej partycji w danej grupie odbiorców. Gdy czytnik łączy się, przekazuje przesunięcie do centrum zdarzeń, aby określić lokalizację, w której chcesz rozpocząć odczytywanie. W ten sposób można użyć procesu tworzenia punktów kontrolnych zarówno do oznaczenia zdarzeń jako „ukończone” przez aplikacje podrzędne, jak i zapewnienia odporności zdarzenia na pracę w trybie failover między czytnikami działającymi na różnych komputerach. Istnieje możliwość powrotu do starszych danych przez określenie niższego przesunięcia z tego procesu tworzenia punktów kontrolnych. Dzięki temu mechanizmowi tworzenie punktów kontrolnych zapewnia zarówno odporność na pracę w trybie failover, jak i powtarzanie strumienia zdarzeń.

Ważne

Przesunięcia są dostarczane przez usługę Event Hubs. To odpowiedzialność konsumenta za punkt kontrolny w miarę przetwarzania zdarzeń.

Uwaga

Jeśli używasz Azure Blob Storage jako magazynu punktów kontrolnych w środowisku obsługującym inną wersję zestawu SDK obiektów blob usługi Storage niż zwykle dostępne na platformie Azure, musisz użyć kodu, aby zmienić wersję interfejsu API usługi Storage na określoną wersję obsługiwaną przez to środowisko. Jeśli na przykład korzystasz z usługi Event Hubs w usłudze Azure Stack Hub w wersji 2002, najwyższa dostępna wersja usługi Storage to wersja 2017-11-09. W takim przypadku należy użyć kodu w celu kierowania wersji interfejsu API usługi Storage do wersji 2017-11-09. Przykład sposobu określania docelowej wersji interfejsu API usługi Storage można znaleźć w poniższych przykładach w witrynie GitHub:

Kompaktowanie dzienników

Azure Event Hubs obsługuje kompaktowanie dziennika zdarzeń w celu zachowania najnowszych zdarzeń danego klucza zdarzenia. W przypadku zagęszczonych centrów zdarzeń/tematu platformy Kafka można użyć przechowywania z baesdami kluczy, a nie przy użyciu grubszego przechowywania opartego na czasie.

Aby uzyskać więcej informacji na temat kompaktowania dzienników, zobacz Log compaction (Kompaktowanie dzienników).

Typowe zadania odbiorców

Wszyscy użytkownicy usługi Event Hubs łączą się za pośrednictwem sesji amQP 1.0, kanału komunikacji dwukierunkowej obsługującej stan. Każda partycja zawiera sesję protokołu AMQP 1.0, która ułatwia transport zdarzeń posegregowanych według partycji.

Nawiązywanie połączenia z partycją

Podczas nawiązywania połączenia z partycjami często stosuje się mechanizm dzierżawy do koordynowania połączeń czytnika z określonymi partycjami. Dzięki temu każda partycja w grupie odbiorców może mieć tylko jeden aktywny czytnik. Punkty kontrolne, dzierżawy i zarządzanie czytelnikami są uproszczone przy użyciu klientów w zestawach SDK usługi Event Hubs, które pełnią rolę inteligentnych agentów konsumenckich. Są to:

Zdarzenia odczytywania

Po otwarciu sesji i linku protokołu AMQP 1.0 dla określonej partycji zdarzenia są dostarczane do klienta protokołu AMQP 1.0 przez usługę Event Hubs. Ten mechanizm dostarczania zapewnia wyższą przepływność i mniejsze opóźnienia niż mechanizmy oparte na ściąganiu, na przykład HTTP GET. Podczas wysyłania zdarzeń do klienta każde wystąpienie danych zdarzenia zawiera ważne metadane, takie jak przesunięcie i numer sekwencji, które są używane do ułatwienia tworzenia punktów kontrolnych sekwencji zdarzeń.

Dane zdarzenia:

  • Przesunięcie
  • Numer sekwencyjny
  • Treść
  • Właściwości użytkownika
  • Właściwości systemu

Twoim zadaniem jest zarządzanie przesunięciem.

Grupy aplikacji

Grupa aplikacji to kolekcja aplikacji klienckich łączących się z przestrzenią nazw usługi Event Hubs udostępniającą unikatowy warunek identyfikacji, taki jak kontekst zabezpieczeń — zasady dostępu współdzielonego lub identyfikator aplikacji usługi Azure Active Directory (Azure AD).

Azure Event Hubs umożliwia zdefiniowanie zasad dostępu do zasobów, takich jak zasady ograniczania przepustowości dla danej grupy aplikacji i sterowanie przesyłaniem strumieniowym zdarzeń (publikowanie lub używanie) między aplikacjami klienckimi i usługą Event Hubs.

Aby uzyskać więcej informacji, zobacz Zarządzanie zasobami dla aplikacji klienckich z grupami aplikacji.

Następne kroki

Aby uzyskać więcej informacji na temat usługi Event Hubs, skorzystaj z następujących linków: