Udostępnij za pośrednictwem

Kolejki, tematy i subskrypcje usługi Service Bus

  • Artykuł

Usługa Azure Service Bus obsługuje niezawodne kolejkowanie komunikatów i trwałe komunikaty publikowania/subskrybowania. Jednostki obsługi komunikatów, które tworzą podstawowe funkcje obsługi komunikatów w usłudze Service Bus, to kolejki, tematy i subskrypcje.

Ważne

Jeśli dopiero zaczynasz korzystać z usługi Azure Service Bus, zapoznaj się z tematem Co to jest usługa Azure Service Bus? przed przejściem do tego artykułu.

Kolejki

Kolejki umożliwiają dostarczanie komunikatów metodą pierwszy na wejściu — pierwszy na wyjściu (FIFO) do jednego lub większej liczby konkurencyjnych konsumentów. Oznacza to, że odbiorniki zwykle odbierają i przetwarzają komunikaty w kolejności, w jakiej zostały dodane do kolejki. I tylko jeden odbiorca komunikatu odbiera i przetwarza każdy komunikat.

Obraz przedstawiający sposób działania kolejek usługi.

Kluczową zaletą korzystania z kolejek jest tymczasowe oddzielenie składników aplikacji. Innymi słowy, producenci (nadawcy) i odbiorcy (odbiorcy) nie muszą jednocześnie wysyłać i odbierać komunikatów, ponieważ komunikaty są przechowywane trwale w kolejce. Ponadto producent nie musi czekać na odpowiedź od konsumenta, aby nadal przetwarzać i wysyłać wiadomości.

Powiązana korzyść to bilansowanie obciążenia, które umożliwia producentom i konsumentom wysyłanie i odbieranie komunikatów z różnymi stawkami. W wielu aplikacjach obciążenie systemu różni się w czasie. Jednak czas przetwarzania wymagany dla każdej jednostki pracy jest zwykle stały. Intermediating message producentów i konsumentów z kolejką oznacza, że aplikacja zużywającą musi być w stanie obsłużyć średnie obciążenie zamiast szczytowego obciążenia. Głębokość kolejki rośnie i zmniejsza się w zależności od zmian obciążenia przychodzącego. Ta funkcja pozwala zaoszczędzić pieniądze na ilości infrastruktury wymaganej do obsługi obciążenia aplikacji. Wraz ze wzrostem obciążenia można dodać więcej procesów roboczych do odczytu z kolejki. Każdy komunikat jest przetwarzany tylko przez jeden z procesów roboczych. Ponadto to równoważenie obciążenia oparte na ściąganiu umożliwia najlepsze wykorzystanie komputerów roboczych, nawet jeśli komputery robocze z przetwarzaniem komunikatów ściągania zasilania z własną maksymalną szybkością. Ten wzorzec jest często nazywany wzorcem konkurujących konsumentów.

Używanie kolejek do pośredniego między producentami komunikatów a konsumentami zapewnia nieodłączne luźne sprzężenie między składnikami. Ponieważ producenci i konsumenci nie znają się nawzajem, konsument może zostać uaktualniony bez wywierania żadnego wpływu na producenta.

Utwórz kolejki

Kolejki można tworzyć przy użyciu jednej z następujących opcji:

Następnie wysyłaj i odbieraj komunikaty przy użyciu klientów napisanych w językach programowania, w tym następujących:

Tryby odbierania

Można określić dwa różne tryby, w których użytkownicy mogą odbierać komunikaty z usługi Service Bus.

  • Odbieranie i usuwanie. W tym trybie, gdy usługa Service Bus odbiera żądanie od odbiorcy, oznacza komunikat jako używany i zwraca go do aplikacji konsumenta. Ten tryb jest najprostszym modelem. Najlepiej sprawdza się w scenariuszach, w których aplikacja nie może tolerować przetwarzania komunikatu, jeśli wystąpi awaria. Aby zrozumieć ten scenariusz, rozważ scenariusz, w którym konsument wystawia żądanie odbioru, a następnie ulega awarii przed jego przetworzeniem. Ponieważ usługa Service Bus oznacza komunikat jako używany, aplikacja rozpoczyna korzystanie z komunikatów po ponownym uruchomieniu. Zostanie pominięty komunikat, że został użyty przed awarią. Ten proces jest często wywoływany co najwyżej raz przetwarzania.
  • Zajrzyj do blokady. W tym trybie operacja odbierania staje się operacją dwuetapową, co umożliwia obsługę aplikacji, które nie tolerują brakujących komunikatów.

    1. Znajduje następny komunikat, który ma zostać użyty, blokuje go, aby uniemożliwić innym użytkownikom odbieranie go, a następnie zwraca komunikat do aplikacji.

    2. Po zakończeniu przetwarzania komunikatu aplikacja wysyła żądanie do usługi Service Bus dotyczące ukończenia drugiego etapu procesu odbierania. Następnie usługa oznacza komunikat jako wykorzystany.

      Jeśli aplikacja nie może przetworzyć komunikatu z jakiegoś powodu, może poprosić usługę Service Bus o porzucenie komunikatu. Usługa Service Bus odblokuje komunikat i udostępnia go ponownie przez tego samego konsumenta lub innego konkurencyjnego konsumenta. Po drugie, istnieje limit czasu skojarzony z blokadą. Jeśli aplikacja nie może przetworzyć komunikatu przed upływem limitu czasu blokady, usługa Service Bus odblokowuje komunikat i udostępnia go ponownie do odebrania.

      Jeśli aplikacja ulegnie awarii po zakończeniu przetwarzania komunikatu, ale zanim wyśle do usługi Service Bus żądanie ukończenia komunikatu, usługa Service Bus ponownie dostarcza komunikat do aplikacji po jej ponownym uruchomieniu. Ten proces jest często nazywany co najmniej jednokrotnym przetwarzaniem. Oznacza to, że każdy komunikat jest przetwarzany co najmniej raz. Jednak w niektórych sytuacjach ten sam komunikat może zostać ponownie dostarczony. Jeśli scenariusz nie może tolerować zduplikowanego przetwarzania, dodaj dodatkową logikę w aplikacji, aby wykryć duplikaty. Aby uzyskać więcej informacji, zobacz Wykrywanie duplikatów, które jest znane jako dokładnie jednokrotne przetwarzanie.

      Uwaga

      Aby uzyskać więcej informacji na temat tych dwóch trybów, zobacz Ustawianie operacji odbierania.

Tematy i subskrypcje

Kolejka umożliwia przetwarzanie komunikatu przez jednego użytkownika. W przeciwieństwie do kolejek, tematów i subskrypcji zapewniają formę komunikacji jeden do wielu w wzorcu publikowania i subskrybowania . Jest to przydatne w przypadku skalowania do dużej liczby adresatów. Każdy publikowany komunikat jest udostępniany każdej subskrypcji zarejestrowanej w temacie. Program Publisher wysyła wiadomość do tematu, a co najmniej jeden subskrybenci otrzymują kopię wiadomości.

Obraz przedstawiający temat usługi Service Bus z trzema subskrypcjami.

Wydawcy wysyłają komunikaty do tematu w taki sam sposób, jak wysyłają komunikaty do kolejki. Jednak użytkownicy nie odbierają komunikatów bezpośrednio z tematu. Zamiast tego konsumenci otrzymują komunikaty z subskrypcji tematu. Subskrypcja tematu przypomina kolejkę wirtualną, która odbiera kopie komunikatów wysyłanych do tematu. Konsumenci odbierają komunikaty z subskrypcji tak samo jak w przypadku odbierania komunikatów z kolejki. Funkcja wysyłania komunikatów kolejki jest mapowania bezpośrednio do tematu i jego funkcji odbierania komunikatów do subskrypcji. Między innymi ta funkcja oznacza, że subskrypcje obsługują te same wzorce opisane wcześniej w tej sekcji dotyczące kolejek: konkurencyjnych odbiorców, czasowego oddzielenia, bilansowania obciążenia i równoważenia obciążenia.

Subskrypcje mogą definiować komunikaty, które chcą otrzymywać z tematu. Komunikaty te są określone w formie co najmniej jednej nazwanej reguły subskrypcji. Każda reguła składa się z warunku filtru, który wybiera określone komunikaty i opcjonalnie zawiera akcję , która donotuje wybrany komunikat. Domyślnie subskrypcja tematu odbiera wszystkie komunikaty wysyłane do tematu. Subskrypcja ma początkową regułę domyślną z prawdziwym filtrem, który umożliwia wybranie wszystkich komunikatów do subskrypcji. Reguła domyślna nie ma skojarzonej akcji. Filtry można zdefiniować za pomocą reguł i akcji w subskrypcji, aby subskrypcja odbierała tylko podzbiór komunikatów wysyłanych do tematu.

Aby uzyskać więcej informacji na temat filtrów, filtrów i akcji.

Tworzenie tematów i subskrypcji

Tworzenie tematu jest podobne do tworzenia kolejki, jak opisano w poprzedniej sekcji. Tematy i subskrypcje można tworzyć przy użyciu jednej z następujących opcji:

Następnie wysyłaj komunikaty do tematu i odbieraj komunikaty z subskrypcji przy użyciu klientów napisanych w językach programowania, w tym następujących:

Reguły i akcje

W wielu scenariuszach komunikaty o określonych cechach muszą być przetwarzane na różne sposoby. Aby włączyć to przetwarzanie, możesz skonfigurować subskrypcje, aby znaleźć komunikaty, które mają żądane właściwości, a następnie wykonać pewne modyfikacje tych właściwości. Chociaż subskrypcje usługi Service Bus widzą wszystkie komunikaty wysyłane do tematu, możliwe jest skopiowanie tylko podzbioru tych komunikatów do kolejki subskrypcji wirtualnej. Takie filtrowanie odbywa się przy użyciu filtrów subskrypcji. Takie modyfikacje są nazywane akcjami filtru. Po utworzeniu subskrypcji można podać wyrażenie filtru, które działa we właściwościach komunikatu. Właściwości mogą być właściwościami systemu (na przykład Etykieta) i niestandardowymi właściwościami aplikacji (na przykład StoreName). Wyrażenie filtru SQL jest opcjonalne w tym przypadku. Bez wyrażenia filtru SQL każda akcja filtru zdefiniowana w subskrypcji jest wykonywana na wszystkich komunikatach dla tej subskrypcji.

Pełny przykład roboczy można znaleźć w przykładzie TopicFilters w witrynie GitHub. Aby uzyskać więcej informacji na temat filtrów, zobacz Temat filtry i akcje.

Jednostki usługi komunikatów Java (JMS) 2.0

Następujące jednostki są dostępne za pośrednictwem interfejsu API usługi komunikatów Java (JMS) 2.0.

  • Kolejki tymczasowe
  • Tematy tymczasowe
  • Udostępnione trwałe subskrypcje
  • Nieudostępniane trwałe subskrypcje
  • Udostępnione subskrypcje nietrwałe
  • Nieudostępne subskrypcje nietrwałe

Dowiedz się więcej o jednostkach JMS 2.0 i o sposobie ich używania.

Jednostki express

Jednostki ekspresowe zostały utworzone na potrzeby scenariuszy o wysokiej przepływności i zmniejszonych opóźnieniach. W przypadku jednostek ekspresowych, jeśli komunikat jest wysyłany do kolejki lub tematu, nie jest natychmiast przechowywany w magazynie obsługi komunikatów. Zamiast tego komunikat jest początkowo buforowany w pamięci. Komunikaty, które pozostają w jednostce, są zapisywane w magazynie komunikatów po opóźnieniu, w którym są one chronione przed utratą z powodu awarii.

W zwykłych jednostkach wszystkie operacje środowiska uruchomieniowego (takie jak Send, Complete, Abandon, Deadletter) są utrwalane w magazynie jako pierwsze i dopiero po potwierdzeniu tego do klienta jako pomyślnego. W jednostkach ekspresowych operacja środowiska uruchomieniowego jest potwierdzana klientowi jako pierwsza pomyślna, a dopiero później utrwalona w magazynie. W związku z tym w przypadku ponownego uruchomienia maszyny lub wystąpienia problemu ze sprzętem niektóre potwierdzone operacje środowiska uruchomieniowego mogą nie być w ogóle utrwalane. Oznacza to, że klient uzyskuje mniejsze opóźnienie i większą przepływność przy użyciu jednostek ekspresowych kosztem potencjalnej utraty danych i/lub ponownego pobierania komunikatów.

Ponadto w czasie wiele optymalizacji zostało wykonanych w usłudze Service Bus, co oznacza, że zalety przepływności i opóźnień jednostek ekspresowych są obecnie minimalne. Ponadto warstwa Premium usługi Service Bus nie obsługuje jednostek express. W związku z tym obecnie nie zaleca się używania tej funkcji.

Następne kroki

Wypróbuj przykłady w wybranym języku:

W przypadku przykładów korzystających ze starszych bibliotek klienckich .NET i Java skorzystaj z następujących linków:

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.