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.

Czas wygaśnięcia i wygasa o godzinie UTC

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.

Uwaga

Komunikaty, które wygasły, mogą nie zostać natychmiast usunięte przez brokera. Broker może zdecydować się na leniwe wygaśnięcie tych komunikatów, na podstawie tego, czy jednostka jest w aktywnym użyciu w momencie wygaśnięcia komunikatu. W związku z tym klienci mogą obserwować niepoprawną liczbę komunikatów podczas korzystania z funkcji wygasania komunikatów, a nawet zobaczyć te komunikaty podczas operacji podglądu. Jednak podczas odbierania komunikatów wygasła wiadomość nie zostanie uwzględniona.

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.

Zaplanowane komunikaty

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.

Termin wygasania o godzinie utc jest zgodnie z projektem. Jeśli czas wygaśnięcia komunikatu nie jest ustawiony i ustawiono tylko czas wygaśnięcia jednostki, wygasa-at-utc jest obliczoną wartością i nie jest obliczana w ścieżce Peek, ale jest obliczana w ścieżce Odbierz/Peeklock. Jeśli komunikat ma czas wygaśnięcia, to wygaśnie-at-utc jest obliczany podczas wysyłania i przechowywania komunikatu. Więc w tym przypadku Zobacz, czy zwraca poprawne wartości wygasa-at-utc .

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.

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 bezczynności w jednostce. 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.

Próżniactwo

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

Encja Co jest uważane za bezczynne
Queue
  • 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, oznacza to, że odbiornik wykonuje odbiory w kolejce lub subskrypcji i nie będą bezczynne.

Zestawy SDK

Właściwość time-to-live można ustawić przy użyciu zestawów SDK (Software Development Kit).

Powiązana zawartość

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.

Aby dowiedzieć się więcej o zaawansowanych funkcjach usługi Azure Service Bus, zobacz Omówienie funkcji zaawansowanych.