Dostarczanie wiadomości push i ponawianie prób na temat przestrzeni nazw

Dostarczanie typu push w przestrzeniach nazw Event Grid zapewnia trwałe dostarczanie. Usługa Event Grid natychmiast próbuje dostarczyć każdy komunikat co najmniej raz dla każdej odpowiadającej subskrypcji. Jeśli punkt końcowy subskrybenta nie potwierdza otrzymania zdarzenia lub występuje błąd, usługa Event Grid ponawia próbę dostarczania na podstawie ustalonego harmonogramu ponowień i polityki ponowień. Domyślnie usługa Event Grid dostarcza jedno zdarzenie jednocześnie subskrybentowi.

Uwaga / Notatka

Usługa Event Grid nie gwarantuje kolejności dostarczania zdarzeń, więc subskrybenci mogą otrzymywać je w niewłaściwej kolejności.

Subskrypcja zdarzenia

Subskrypcja zdarzeń to zasób konfiguracyjny skojarzony z pojedynczym tematem przestrzeni nazw. Między innymi używasz subskrypcji zdarzeń, aby ustawić kryteria wyboru zdarzeń, aby zdefiniować kolekcję zdarzeń dostępną dla subskrybenta z całkowitego zestawu zdarzeń dostępnych w temacie. Korzystając z subskrypcji zdarzeń, zdefiniuj również docelowy punkt końcowy, do którego są wysyłane zdarzenia. Ponadto subskrypcja zdarzeń umożliwia ustawienie innych właściwości, takich jak maksymalna liczba ponownych prób dostarczania i czas życia zdarzeń, które definiują zachowanie działania dostarczania zdarzeń.

Harmonogram ponawiania prób

Gdy usługa Event Grid otrzymuje błąd próby dostarczenia zdarzenia, decyduje, czy powinna ponowić próbę dostarczenia na podstawie typu błędu.

Jeśli błąd zwrócony przez subskrybowany punkt końcowy jest błędem związanym z konfiguracją, którego nie można naprawić za pomocą ponownych prób, usługa Event Grid wysyła zdarzenie do skonfigurowanego miejsca docelowego utraconych komunikatów. Jeśli nie skonfigurowano kolejki martwych listów, zdarzenie zostanie odrzucone. Na przykład zdarzenie jest nieaktywne lub porzucone, gdy punkt końcowy skonfigurowany w subskrypcji zdarzeń nie może zostać osiągnięty, ponieważ został usunięty. Ponowienie dostawy nie występuje w następujących przypadkach i błędach:

Warunki:

  • ArgumentException
  • TimeoutException
  • UnauthorizedAccessException
  • OperationCanceledException
  • SocketException |

Kody błędów

  • 404 - NotFound
  • 401 - Unauthorized
  • 403 - Forbidden
  • 400 -BadRequest
  • 414 RequestUriTooLong

Uwaga / Notatka

Jeśli dla punktu końcowego nie skonfigurowano kolejki martwych listów, zdarzenia zostaną utracone po wystąpieniu powyższych błędów lub warunków. Rozważ skonfigurowanie kolejki dead-letter w subskrypcji zdarzeń, jeśli nie chcesz, aby tego rodzaju zdarzenia były pominięte. Nieaktywne zdarzenia zostaną porzucone, gdy nie znaleziono miejsca docelowego utraconych wiadomości.

Jeśli warunek lub błąd zwrócony przez subskrybowany punkt końcowy nie należy do wymienionych na powyższych listach, usługa Event Grid ponawia próbę na zasadzie podstawowego wysiłku, używając następującego harmonogramu wykładniczego ponawiania prób.

  • 0 sekund (natychmiastowe ponowienie próby)
  • 10 sekund
  • 30 sekund
  • 1 minuta
  • 5 minut

Po upływie 5 minut Event Grid ponawia próbę co 5 minut, dopóki zdarzenie nie zostanie dostarczone, nie zostanie osiągnięta maksymalna liczba prób ponownych lub nie wygaśnie czas życia zdarzenia.

Zasady ponawiania prób

Politykę ponawiania można dostosować przy użyciu następujących dwóch właściwości konfiguracji subskrypcji zdarzeń. Zdarzenie jest odrzucane (gdy nie skonfigurowano przetwarzania komunikatów o błędach) lub oznaczane jako komunikat o błędzie, jeśli dowolna właściwość osiągnie skonfigurowany limit.

  • Maksymalna liczba dostaw — wartość musi być liczbą całkowitą z zakresu od 1 do 10. Wartość domyślna to 10. W przypadku dostawy push ta właściwość definiuje maksymalną liczbę prób dostarczenia.
  • Przechowywanie — ta właściwość jest również znana jako event time to live. Wartość musi być wartością czasu trwania ISO 8601 z dokładnością minuty. Począwszy od momentu opublikowania zdarzenia, ta właściwość definiuje przedział czasu, po którym komunikat wygaśnie. Dozwolona minimalna wartość to "PT1M" (1 minuta). Dozwolona maksymalna wartość to 7 dni lub czas przechowywania tematu bazowego, w zależności od tego, która wartość jest niższa. Portal Azure oferuje proste środowisko użytkownika, w którym określasz liczbę całkowitą dni, godzin i minut.

Uwaga / Notatka

Jeśli ustawisz elementy Retention i Maximum delivery count, usługa Event Grid użyje ich do określenia, kiedy zatrzymać dostarczanie zdarzeń. Jeden zatrzymuje dostarczanie zdarzeń. Jeśli na przykład ustawisz 20 minut jako okres przechowywania i 10 maksymalnych prób dostarczenia, oznacza to, że jeśli zdarzenie nie zostanie dostarczone po 20 minutach lub nie zostanie dostarczone po 10 próbach, w zależności od tego, co nastąpi wcześniej, zdarzenie nie zostanie wyświetlone. Jednak ze względu na harmonogram ponawiania próby ustawienie maksymalnej liczby prób dostarczenia na 10 nie ma wpływu, ponieważ zdarzenia zostaną ponownie umieszczone po 20 minutach. Wynika to z faktu, że w minucie 20, próba dostarczenia #8 (0, 10s, 30s, 1m, 5m, 10m, 15m, 20m) występuje, ale w tym czasie zdarzenie jest martwe.

Dzielenie na partie danych wyjściowych

W przypadku używania webhooków jako docelowego punktu końcowego, usługa Event Grid domyślnie wysyła każde zdarzenie indywidualnie do subskrybentów. Usługę Event Grid można skonfigurować do przesyłania zdarzeń w partiach, aby poprawić wydajność protokołu HTTP w scenariuszach o wysokiej przepustowości. Przetwarzanie wsadowe jest domyślnie wyłączone i można je włączyć dla subskrypcji na zdarzenia.

W przypadku używania Event Hubs jako docelowego typu punktu końcowego, Event Grid zawsze grupuje zdarzenia, aby osiągnąć maksymalną efektywność i wydajność. Nie ma dostępnej konfiguracji zasad grupowania, ponieważ domyślnie usługa Event Grid obsługuje zachowanie grupowania podczas dostarczania do usługi Azure Event Hubs.

Zasady dzielenia na partie

Dostarczanie wsadowe ma dwa ustawienia:

  • Maksymalna liczba zdarzeń na partię — maksymalna liczba zdarzeń, które usługa Event Grid dostarcza na partię. Wartość musi być liczbą całkowitą z zakresu od 1 do 5000. Ta liczba nigdy nie jest przekraczana. Jednak mniej zdarzeń może być dostarczone, jeśli w momencie dostarczenia nie są dostępne żadne inne zdarzenia. Usługa Event Grid nie opóźnia zdarzeń w celu utworzenia partii, jeśli jest dostępna mniejsza liczba zdarzeń.
  • Preferowany rozmiar partii w kilobajtach — docelowy limit rozmiaru partii w kilobajtach. Wartość musi być liczbą z zakresu od 1 do 1024. Podobnie jak w przypadku maksymalnej liczby zdarzeń, rozmiar partii może być mniejszy, jeśli w momencie dostarczenia nie są dostępne wystarczające zdarzenia. Istnieje możliwość, że partia jest większa niż preferowany rozmiar partii, jeśli pojedyncze zdarzenie jest większe niż preferowany rozmiar. Jeśli na przykład preferowany rozmiar to 4 KB, a zdarzenie o rozmiarze 10 KB jest przesyłane do usługi Event Grid, to zdarzenie 10 KB jest dostarczane, a nie odrzucane.

Dostarczanie wsadowe jest konfigurowane dla poszczególnych subskrypcji zdarzeń za pośrednictwem portalu, interfejsu wiersza polecenia, programu PowerShell lub zestawów SDK.

Zachowanie przetwarzania wsadowego

  • Wszystkie lub żadne

    Usługa Event Grid działa z semantykami typu all-or-none. Nie obsługuje częściowego sukcesu dostawy wsadowej. Subskrybenci powinni zachować ostrożność, aby poprosić tylko o tyle zdarzeń w partii, ile są w stanie obsłużyć w ciągu trzydziestu sekund.

  • Optymistyczne grupowanie

    Ustawienia zasad przetwarzania wsadowego nie są ścisłymi ograniczeniami zachowania przetwarzania wsadowego i są przestrzegane w miarę możliwości. Przy niskich współczynnikach zdarzeń często obserwujesz, że rozmiar partii jest mniejszy niż żądane maksymalne zdarzenia na partię.

  • Wartość domyślna to WYŁĄCZONE

    Domyślnie usługa Event Grid dodaje tylko jedno zdarzenie do każdego żądania dostarczenia. Aby włączyć przetwarzanie wsadowe, należy ustawić jedno z ustawień wymienionych w zasadach przetwarzania wsadowego.

  • Wartości domyślne

    Nie jest konieczne określenie obu ustawień (maksymalna liczba zdarzeń na partię i Przybliżony rozmiar partii w kilobajtach) podczas tworzenia subskrypcji zdarzeń. Jeśli ustawiono tylko jedno ustawienie, usługa Event Grid używa wartości domyślnych. Zapoznaj się z poniższymi sekcjami, aby zapoznać się z wartościami domyślnymi i jak je zastąpić.

Azure Portal

Te ustawienia są widoczne na karcie Dodatkowe funkcje na stronie Subskrypcja zdarzeń lub po utworzeniu subskrypcji zdarzeń w opcji menu Konfiguracja podczas uzyskiwania dostępu do subskrypcji zdarzeń.

Zrzut ekranu przedstawiający kartę

Zdarzenia komunikatów martwych

Gdy usługa Event Grid nie może dostarczyć zdarzenia w określonym czasie lub po wielokrotnych próbach dostarczenia zdarzenia, wysyła zdarzenie na konto magazynowe. Ten proces jest znany jako utracony zapis. Grid zdarzeń umieszcza zdarzenie w martwych literach, gdy spełniony jest jeden z następujących warunków.

  • Zdarzenie nie jest dostarczane w okresie wygaśnięcia (przechowywanie zdefiniowane w subskrypcji zdarzeń).
  • Liczba prób dostarczenia eventu przekroczyła limit.

Jeśli zostanie spełniony, zdarzenie zostanie porzucone lub nieaktywne. Domyślnie usługa Event Grid nie włącza kolejki wiadomości niewysłanych (ang. dead-letter). Aby to włączyć, należy określić konto magazynu do przechowywania niedostarczonych zdarzeń podczas tworzenia subskrypcji zdarzeń. Odczytujesz zdarzenia z tego konta magazynu, aby realizować dostawy.

Usługa Event Grid wysyła zdarzenie do lokalizacji dead-letter, gdy wykonała wszystkie próby ponowienia. Jeśli usługa Event Grid otrzyma kod odpowiedzi 400 (nieprawidłowe żądanie) lub 413 (zbyt duża jednostka żądania), natychmiast planuje zdarzenie do oznaczania jako nierozwiązane. Te kody odpowiedzi wskazują, że dostarczanie zdarzenia nigdy nie powiedzie się.

Wygaśnięcie czasu życia (TTL) jest sprawdzane tylko podczas następnej zaplanowanej próby doręczenia. Tak więc, nawet jeśli czas wygaśnięcia wygaśnie przed kolejną zaplanowaną próbą dostarczenia, wygaśnięcie zdarzenia jest sprawdzane tylko w momencie kolejnej dostawy, a następnie utraconych wiadomości.

Pomiędzy ostatnią próbą dostarczenia zdarzenia a jego dostarczeniem do lokalizacji przechowywania błędnych komunikatów mija pięć minut opóźnienia. To opóźnienie ma na celu zmniejszenie liczby operacji w Blob Storage. Jeśli lokalizacja utraconych komunikatów jest niedostępna przez cztery godziny, zdarzenie zostanie porzucone.

Przed ustawieniem lokalizacji „dead-letter” musisz mieć konto magazynu z kontenerem. Punkt końcowy dla tego kontenera należy podać podczas tworzenia subskrypcji zdarzeń. Punkt końcowy ma format: /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/<storage-name>/blobServices/default/containers/<container-name>

Możesz chcieć otrzymywać powiadomienia, gdy zdarzenie zostało wysłane do lokalizacji utraconych wiadomości. Aby użyć usługi Event Grid do odpowiedzi na niedostarczone zdarzenia, utwórz subskrypcję zdarzeń dla magazynu obiektów blob z dziennikiem zdarzeń. Za każdym razem, gdy przechowalnia zbiorcza niesprzedanych wiadomości odbiera nieprzekazane zdarzenie, usługa Event Grid powiadamia mechanizm obsługi. Obsługa odpowiada za pomocą działań, które chcesz podjąć w celu uzgodnienia niedostarczonych zdarzeń.

Podczas konfigurowania utraconych komunikatów należy dodać tożsamość zarządzaną do odpowiedniej roli kontroli dostępu opartej na rolach (RBAC) na koncie usługi Azure Storage, która będzie przechowywać zdarzenia utraconych wiadomości. Aby uzyskać więcej informacji, zobacz Obsługiwane miejsca docelowe i role platformy Azure.

Formaty zdarzeń dostawy

Ta sekcja zawiera przykłady zdarzeń oraz zdarzeń odrzuconych, używając schematu CloudEvents 1.0, który wspiera format metadanych wiadomości w tematach nazwanych przestrzeni.

Schemat CloudEvents 1.0

Zdarzenie

{
    "id": "caee971c-3ca0-4254-8f99-1395b394588e",
    "source": "mysource",
    "dataversion": "1.0",
    "subject": "mySubject",
    "type": "fooEventType",
    "datacontenttype": "application/json",
    "data": {
        "prop1": "value1",
        "prop2": 5
    }
}

Zdarzenie utraconych komunikatów

[
  {
    "deadLetterProperties": {
      "deadletterreason": "Maximum delivery attempts was exceeded.",
      "deliveryattempts": 1,
      "deliveryresult": "Event was not acknowledged nor rejected.",
      "publishutc": "2023-11-01T20:33:51.4521467Z",
      "deliveryattemptutc": "2023-11-01T20:33:52.3692079Z"
    },
    "event": {
      "comexampleextension1": "value1",
      "id": "A234-1234-1234",
      "comexampleothervalue": "5",
      "datacontenttype": "text/xml",
      "specversion": "1.0",
      "time": "2018-04-05T17:31:00Z",
      "source": "/mycontext",
      "type": "com.example.someevent",
      "data": <your-event-data>
    }
  }
]

LastDeliveryOutcome: Okres próbny

Subskrypcja zdarzeń przechodzi w stan okresu próbnego przez usługę Event Grid na pewien okres czasu, jeśli dostarczanie zdarzeń do miejsca docelowego zacznie zawodzić. Czas próbny różni się w przypadku różnych błędów zwracanych przez docelowy punkt końcowy. Jeśli subskrypcja zdarzeń jest w stanie zawieszenia, zdarzenia mogą zostać oznaczone jako niedostarczalne lub pominięte bez próby dostarczenia, w zależności od kodu błędu, który powoduje to zawieszenie.

Błąd Czas trwania okresu próbnego
Zajęte 10 sekund
Nie znaleziono 5 minut
SocketError 30 sekund
ResolutionError 5 minut
Wyłączony 5 minut
Pełny 5 minut
Przekroczono limit czasu 10 sekund
Brak autoryzacji 5 minut
Zakazany 5 minut
NieprawidłowaDestynacjaFunkcjiAzure 10 minut

Uwaga / Notatka

Usługa Event Grid używa czasu trwania próbnego w celu lepszego zarządzania dostarczaniem, a czas trwania może ulec zmianie w przyszłości.

Stan dostarczania komunikatów

Usługa Event Grid używa kodów odpowiedzi HTTP do potwierdzenia otrzymania zdarzeń.

Kody powodzenia

Usługa Event Grid uwzględnia tylko następujące kody odpowiedzi HTTP jako pomyślne dostawy. Wszystkie inne kody stanu są uznawane za nieudane dostawy i będą odpowiednio ponawiane lub nieaktywne. Gdy usługa Event Grid otrzymuje pomyślny kod stanu, uznaje to za zakończenie dostarczenia.

  • 200 OK
  • 201 Utworzono
  • 202 Zaakceptowano
  • 203 Informacje nieautorytatywne
  • 204 Brak zawartości

Kody błędów

Wszystkie inne kody, które nie znajdują się w powyższym zestawie (200–204), są uznawane za błędy i w razie potrzeby zostaną ponowione próby. Niektóre z nich mają określone zasady ponawiania prób powiązane z nimi opisane poniżej. Wszystkie inne są zgodne ze standardowym harmonogramem ponawiania prób. Należy pamiętać, że ze względu na wysoce równoległy charakter architektury usługi Event Grid zachowanie ponawiania jest niedeterministyczne.

Kod stanu Zachowanie ponawiania prób
400 Nieprawidłowe żądanie Nie ponowiono próby
401 Brak autoryzacji Ponów próbę po upływie co najmniej 5 minut dla punktów końcowych zasobów platformy Azure
403 Zabronione Nie ponowiono próby
404 Nie znaleziono Ponów próbę po upływie co najmniej 5 minut dla punktów końcowych zasobów platformy Azure
408 - Limit czasu żądania Ponów próbę po upływie 2 minut lub więcej
413 Jednostka żądania jest za duża Nie ponowiono próby
Usługa 503 jest niedostępna Ponów próbę po upływie co najmniej 30 sekund
Wszystkie inne Ponów próbę po upływie co najmniej 10 sekund

Niestandardowe właściwości dostarczenia

Subskrypcje zdarzeń umożliwiają konfigurowanie nagłówków HTTP uwzględnionych w dostarczanych zdarzeniach. Ta funkcja umożliwia ustawianie niestandardowych nagłówków wymaganych przez miejsce docelowe. Podczas tworzenia subskrypcji zdarzeń można skonfigurować maksymalnie 10 nagłówków. Każda wartość nagłówka nie powinna być większa niż 4096 (4K) bajtów. Możesz ustawić nagłówki niestandardowe dla zdarzeń dostarczanych do następujących miejsc docelowych:

  • Webhooks
  • Azure Event Hubs

Następne kroki