Wstępne pobieranie komunikatów usługi Azure Service Bus

  • Artykuł

Po włączeniu funkcji pobierania wstępnego dla dowolnego z oficjalnych klientów usługi Service Bus odbiorca uzyskuje więcej komunikatów niż to, o co aplikacja początkowo poprosiła, aż do określonej liczby pobierania wstępnego. Gdy komunikaty są zwracane do aplikacji, klient uzyskuje więcej komunikatów w tle, aby wypełnić bufor pobierania wstępnego.

Włącz pobieranie z wyprzedzeniem

Aby włączyć funkcję przed pobraniem, ustaw wstępnie pobraną liczbę klienta kolejki lub subskrypcji na liczbę większą niż zero. Ustawienie wartości na zero powoduje wyłączenie pobierania wstępnego.

Ustaw właściwość count prefetch dla obiektów ServiceBusReceiver i ServiceBusProcessor .

Uwaga

Zestaw JAVA Script SDK nie obsługuje funkcji pobierania wstępnego .

Gdy komunikaty są dostępne w buforze pobierania wstępnego, wszystkie kolejne wywołania odbierania są natychmiast realizowane z buforu. Bufor jest uzupełniany w tle, gdy miejsce staje się dostępne. Jeśli nie ma dostępnych komunikatów do dostarczenia, operacja odbierania opróżni bufor, a następnie czeka lub blokuje zgodnie z oczekiwaniami.

Dlaczego pobieranie wstępne nie jest opcją domyślną?

Wstępne pobieranie przyspiesza przepływ komunikatów, ponieważ komunikat jest łatwo dostępny dla lokalnego pobierania, zanim aplikacja poprosi o podanie komunikatu. Ten zysk przepływności jest wynikiem kompromisu, który autor aplikacji musi jawnie wprowadzić.

W przypadku korzystania z trybu odbierania i usuwania wszystkie komunikaty, które są pobierane do buforu pobierania wstępnego, nie są już dostępne w kolejce. Komunikaty pozostają tylko w buforze pobierania w pamięci, dopóki nie zostaną odebrane do aplikacji. Jeśli aplikacja kończy się przed odebraniem komunikatów do aplikacji, te komunikaty są nieodwracalne (utracone).

W przypadku korzystania z trybu odbierania blokady podglądu komunikaty pobierane do buforu pobierania wstępnego są pobierane do buforu w stanie zablokowanym. Mają zegar limitu czasu dla tykania blokady. Jeśli bufor pobierania wstępnego jest duży, a przetwarzanie trwa tak długo, że blokady komunikatów wygasają podczas pozostawania w buforze pobierania wstępnego, a nawet podczas przetwarzania komunikatu przez aplikację, może wystąpić pewne mylące zdarzenia do obsługi przez aplikację. Aplikacja może uzyskać komunikat z wygasłą lub nieuchronnie wygasającą blokadą. Jeśli tak, aplikacja może przetworzyć komunikat, ale okaże się, że nie może ukończyć komunikatu z powodu wygaśnięcia blokady. Aplikacja może sprawdzić LockedUntilUtc właściwość (która podlega niesymetryczności zegara między brokerem a zegarem lokalnym).

Jeśli blokada komunikatu wygasła, aplikacja musi zignorować komunikat i nie powinna wykonywać żadnego wywołania interfejsu API w komunikacie. Jeśli komunikat nie wygasł, ale wygaśnięcie jest nieuchronne, blokada może zostać odnowiona i przedłużona do innego domyślnego okresu blokady. Jeśli blokada w trybie dyskretnym wygaśnie w buforze pobierania wstępnego, komunikat jest traktowany jako porzucony i jest ponownie udostępniany do pobierania z kolejki. Może to spowodować pobranie komunikatu do buforu pobierania wstępnego i umieszczonego na końcu. Jeśli bufor pobierania wstępnego nie może być zwykle przepracowany podczas wygasania komunikatów, komunikaty są wielokrotnie pobierane wstępnie, ale nigdy nie są dostarczane w stanie użytecznym (poprawnie zablokowanym) i są ostatecznie przenoszone do kolejki utraconych komunikatów po przekroczeniu maksymalnej liczby dostarczania.

Jeśli aplikacja jawnie porzuci komunikat, komunikat może być ponownie dostępny do pobrania z kolejki. Po włączeniu pobierania wstępnego komunikat zostanie ponownie pobrany do buforu pobierania wstępnego i umieszczony na końcu. Ponieważ komunikaty z buforu pobierania wstępnego są opróżniane w kolejności pierwszego wyjścia (FIFO), aplikacja może odbierać komunikaty poza kolejnością. Na przykład aplikacja może otrzymać komunikat o identyfikatorze 2, a następnie komunikat o identyfikatorze 1 (który został porzucony wcześniej) z buforu.

Jeśli potrzebujesz wysokiego stopnia niezawodności przetwarzania komunikatów, a przetwarzanie wymaga znacznej pracy i czasu, zalecamy użycie funkcji Pobierania wstępne w sposób konserwatywny lub w ogóle nie. Jeśli potrzebujesz wysokiej przepływności i przetwarzania komunikatów jest często tanie, pobieranie wstępne daje znaczne korzyści z przepływności.

Maksymalna liczba prefetch i czas trwania blokady skonfigurowany w kolejce lub subskrypcji muszą być zrównoważone, tak aby limit czasu blokady co najmniej przekracza skumulowany oczekiwany czas przetwarzania komunikatów dla maksymalnego rozmiaru buforu pobierania przed pobraniem oraz jeden komunikat. Jednocześnie limit czasu blokady nie powinien być tak długi, że komunikaty mogą przekraczać maksymalny czas wygaśnięcia, gdy zostaną przypadkowo porzucone, a więc wymaganie wygaśnięcia blokady przed ponownym wysłaniem.

Następne kroki

Wypróbuj przykłady w wybranym języku, aby zapoznać się z funkcjami usługi Azure Service Bus.

Przykłady dla starszych bibliotek klienckich .NET i Java:

30 września 2026 r. wycofamy biblioteki zestawu SDK usługi Azure Service Bus WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus i com.microsoft.azure.servicebus, które nie są zgodne z wytycznymi dotyczącymi zestawu Azure SDK. Zakończymy również obsługę protokołu SBMP, więc nie będzie można już używać tego protokołu po 30 września 2026 r. Przeprowadź migrację do najnowszych bibliotek zestawu Azure SDK, które oferują krytyczne aktualizacje zabezpieczeń i ulepszone możliwości przed tą datą.

Mimo że starsze biblioteki mogą być nadal używane poza 30 września 2026 r., nie będą już otrzymywać oficjalnej pomocy technicznej i aktualizacji od firmy Microsoft. Aby uzyskać więcej informacji, zobacz ogłoszenie o wycofaniu pomocy technicznej.