Udostępnij za pośrednictwem

Azure Service Bus — wygaśnięcie komunikatu (czas wygaśnięcia)

  • Artykuł

Ładunek w komunikacie lub poleceniu lub zapytaniu, które komunikat przekazuje do odbiornika, prawie zawsze podlega jakiejś formie terminu wygaśnięcia na poziomie aplikacji. Po upływie takiego terminu zawartość nie jest już dostarczana lub żądana operacja nie jest już wykonywana.

W środowiskach programistycznych i testowych, w których kolejki i tematy są często używane w kontekście częściowych przebiegów aplikacji lub części aplikacji, pożądane jest również, aby komunikaty testowe osieroconych były automatycznie wyrzucane, aby następny przebieg testu mógł rozpocząć czyszczenie.

Uwaga

Jeśli nie znasz jeszcze pojęć związanych z usługą Service Bus, zobacz Pojęcia dotyczące usługi Service Bus i kolejki, tematy i subskrypcje usługi Service Bus.

Wygaśnięcie dowolnego komunikatu może być kontrolowane przez ustawienie właściwości systemowej czas wygaśnięcia , która określa względny czas trwania. Wygaśnięcie staje się bezwzględnym momentem, gdy komunikat jest umieszczany w kolejce do jednostki. W tym czasie właściwość expires-at-utc przyjmuje wartość enqueued-time-utc time-to-live + . Ustawienie czasu wygaśnięcia (TTL) dla komunikatu obsługiwanego przez brokera nie jest wymuszane, gdy nie ma aktywnie nasłuchiwania klientów.

Po upływie czasu wygaśnięcia i czasu utc komunikaty stają się niekwalifikowane do pobierania. Wygaśnięcie nie ma wpływu na komunikaty, które są obecnie zablokowane do dostarczania. Te komunikaty są nadal obsługiwane normalnie. Jeśli blokada wygaśnie lub komunikat zostanie porzucony, wygaśnięcie zostanie zastosowane natychmiast. Gdy komunikat jest zablokowany, aplikacja może mieć komunikat, który wygasł. Niezależnie od tego, czy aplikacja chce przejść do przodu z przetwarzaniem, czy też zdecyduje się zrezygnować z komunikatu, zależy od implementatora.

Bardzo niski czas wygaśnięcia w milisekundach lub sekundach może spowodować wygaśnięcie komunikatów przed odebraniem go przez aplikacje odbiorcy. Rozważ najwyższy czas wygaśnięcia, który działa dla aplikacji.

Uwaga

W przypadku zaplanowanych komunikatów należy określić czas kolejkowania, w którym komunikat ma zostać zmaterializowany w kolejce na potrzeby pobierania. Czas wysyłania komunikatu do usługi Service Bus różni się od czasu, w którym komunikat jest w kolejce. Czas wygaśnięcia komunikatu zależy od czasu w kolejce, a nie czasu, w którym komunikat jest wysyłany do usługi Service Bus. W związku z tym czas wygaśnięcia-at-utc jest nadal w kolejce i czas wygaśnięcia.

Jeśli na przykład ustawisz ScheduledEnqueueTimeUtc wartość 5 minut od UtcNow, a TimeToLive do 10 minut, komunikat wygaśnie po 5 + 10 = 15 minut od teraz. Komunikat materializuje się w kolejce po 5 minutach, a licznik 10 minut rozpoczyna się od tego czasu.

Wygaśnięcie na poziomie jednostki

Wszystkie komunikaty wysyłane do kolejki lub tematu podlegają domyślnemu wygaśnięciu ustawionemu na poziomie jednostki. Można go również ustawić w portalu podczas tworzenia i dostosowywać później. Domyślne wygaśnięcie jest używane dla wszystkich komunikatów wysyłanych do jednostki, w której czas wygaśnięcia nie jest jawnie ustawiony. Domyślne wygaśnięcie działa również jako limit wartości czasu wygaśnięcia. Komunikaty, które mają dłuższy czas wygaśnięcia niż wartość domyślna, są w trybie dyskretnym dostosowywane do domyślnej wartości czasu wygaśnięcia komunikatu przed ich zapisem w kolejce.

Uwaga

  • Domyślna wartość czasu wygaśnięcia dla komunikatu obsługiwanego przez brokera jest największą możliwą wartością podpisanej liczby całkowitej 64-bitowej, jeśli nie określono inaczej.
  • W przypadku jednostek obsługi komunikatów (kolejek i tematów) domyślny czas wygaśnięcia jest również największą możliwą wartością dla podpisanej liczby całkowitej 64-bitowej dla warstw Standardowa i Premium usługi Service Bus. W przypadku warstwy podstawowej domyślny (również maksymalny) czas wygaśnięcia wynosi 14 dni.
  • Jeśli temat określa mniejszy czas wygaśnięcia niż subskrypcja, zostanie zastosowany czas wygaśnięcia tematu.

Wygasłe komunikaty można opcjonalnie przenieść do kolejki utraconych komunikatów. To ustawienie można skonfigurować programowo lub przy użyciu witryny Azure Portal. Jeśli opcja zostanie wyłączona, wygasłe komunikaty zostaną porzucone. Wygasłe komunikaty przeniesione do kolejki utraconych komunikatów można odróżnić od innych komunikatów utraconych, oceniając właściwość przyczyny utraconych komunikatów, którą broker przechowuje w sekcji właściwości użytkownika.

Jeśli wiadomość jest chroniona przed wygaśnięciem podczas blokowania, a flaga jest ustawiona na jednostce, komunikat zostanie przeniesiony do kolejki utraconych komunikatów, ponieważ blokada zostanie porzucona lub wygaśnie. Jednak nie jest przenoszony, jeśli komunikat został pomyślnie rozstrzygnięty, co oznacza, że aplikacja pomyślnie go obsłużyła, pomimo nominalnego wygaśnięcia. Aby uzyskać więcej informacji o blokadach i rozliczeniach komunikatów, zobacz Transfery komunikatów, blokady i rozliczenia.

Kombinacja terminów wygaśnięcia i automatycznych (i transakcyjnych) utraconych komunikatów po wygaśnięciu jest cennym narzędziem do ustalenia, czy zadanie przydzielone programowi obsługi lub grupie procedur obsługi w terminie jest pobierane do przetwarzania w miarę osiągnięcia terminu.

Rozważmy na przykład witrynę internetową, która musi niezawodnie wykonywać zadania na zapleczu z ograniczonym skalowaniem, i która czasami doświadcza skoków ruchu lub chce być odizolowana od epizodów dostępności tego zaplecza. W regularnym przypadku program obsługi po stronie serwera dla przesłanych danych użytkownika wypycha informacje do kolejki, a następnie otrzymuje odpowiedź potwierdzając pomyślną obsługę transakcji w kolejce odpowiedzi. Jeśli występuje skok ruchu, a procedura obsługi zaplecza nie może przetworzyć elementów listy prac na czas, wygasłe zadania zostaną zwrócone w kolejce utraconych komunikatów. Interakcyjny użytkownik może zostać powiadomiony, że żądana operacja trwa nieco dłużej niż zwykle, a żądanie można następnie umieścić w innej kolejce dla ścieżki przetwarzania, w której wynik przetwarzania ostatecznego jest wysyłany do użytkownika pocztą e-mail.

Wygaśnięcie jednostek z obsługą sesji

W przypadku kolejek lub subskrypcji tematów z obsługą sesji komunikaty są blokowane na poziomie sesji. Jeśli czas wygaśnięcia któregokolwiek z komunikatów wygaśnie, wszystkie komunikaty związane z tej sesji zostaną porzucone lub nieaktywne na podstawie włączonego utraconych komunikatów w ustawieniu wygasania komunikatów w jednostce. Innymi słowy, jeśli w sesji istnieje jeden komunikat, który przeszedł czas wygaśnięcia, wszystkie komunikaty w sesji wygasły. Komunikaty wygasają tylko wtedy, gdy jest aktywny odbiornik.

Jednostki tymczasowe

Kolejki, tematy i subskrypcje usługi Service Bus można tworzyć jako jednostki tymczasowe, które są automatycznie usuwane, gdy nie były używane przez określony okres czasu.

Automatyczne czyszczenie jest przydatne w scenariuszach programowania i testowania, w których jednostki są tworzone dynamicznie i nie są czyszczone po użyciu, ze względu na przerwę w uruchomieniu testu lub debugowania. Jest to również przydatne, gdy aplikacja tworzy jednostki dynamiczne, takie jak kolejka odpowiedzi, do odbierania odpowiedzi z powrotem do procesu serwera internetowego lub do innego stosunkowo krótkotrwałego obiektu, w którym trudno jest niezawodnie wyczyścić te jednostki, gdy wystąpienie obiektu zniknie.

Ta funkcja jest włączona przy użyciu właściwości automatycznego usuwania w stanie bezczynności w przestrzeni nazw. Ta właściwość jest ustawiona na czas trwania, przez który jednostka musi być bezczynna (nieużywane), zanim zostanie automatycznie usunięta. Minimalna wartość tej właściwości to 5 minut.

Ważne

Ustawienie poziomu blokady usługi Azure Resource Manager na CanNotDeletewartość , w przestrzeni nazw lub na wyższym poziomie nie uniemożliwia usunięcia jednostek AutoDeleteOnIdle . Jeśli nie chcesz, aby jednostka została usunięta, ustaw AutoDeleteOnIdle właściwość na DataTime.MaxValue.

Lenistwa

Oto, co uważa się za bezczynność jednostek (kolejek, tematów i subskrypcji):

Encja Co jest uważane za bezczynne
Kolejka
  • Brak wysyłania
  • Brak odebranych
  • Brak aktualizacji kolejki
  • Brak zaplanowanych komunikatów
  • Brak przeglądania/przeglądania
Temat
  • Brak wysyłania
  • Brak aktualizacji tematu
  • Brak zaplanowanych komunikatów
  • Brak operacji dotyczących subskrypcji tematu (zobacz następny wiersz)
Subskrypcja
  • Brak odebranych
  • Brak aktualizacji subskrypcji
  • Brak nowych reguł dodanych do subskrypcji
  • Brak przeglądania/przeglądania

Ważne

Jeśli masz konfigurację automatycznego przesyłania dalej w kolejce lub subskrypcji, jest to równoważne z odebraniem odbiornika w kolejce lub subskrypcji i nie będą bezczynne.

Zestawy SDK

Następne kroki

Aby dowiedzieć się więcej o komunikatach usługi Service Bus, zobacz następujące artykuły: