Udostępnij za pośrednictwem

Sesje komunikatów

  • Artykuł

Sesje usługi Azure Service Bus umożliwiają wspólne i uporządkowane przetwarzanie niezwiązanych sekwencji powiązanych komunikatów. Sesje mogą być używane w pierwsze weszło, pierwsze wyszło (FIFO) i wzorce żądanie-odpowiedź. W tym artykule pokazano, jak używać sesji do implementowania tych wzorców podczas korzystania z usługi Service Bus.

Uwaga

Warstwa Podstawowa usługi Service Bus nie obsługuje sesji. Poziomy Standardowy i Premium obsługują sesje. Aby uzyskać różnice pomiędzy tymi poziomami, zobacz Cennik usługi Service Bus.

Wzorzec "pierwsze weszło, pierwsze wyszło" (FIFO)

Aby uzyskać przetwarzanie FIFO w przetwarzaniu komunikatów z kolejek lub subskrypcji usługi Service Bus, użyj sesji. Usługa Service Bus nie określa charakteru relacji między komunikatami, a także nie definiuje określonego modelu określania, gdzie rozpoczyna się lub kończy sekwencja komunikatów.

Nadawca może zainicjować sesję podczas przesyłania komunikatów do tematu lub kolejki, ustawiając właściwość identyfikatora sesji na unikatowy identyfikator zdefiniowany przez aplikację. Na poziomie protokołu AMQP 1.0 ta wartość jest mapowania na właściwość group-id .

W przypadku kolejek lub subskrypcji obsługujących sesje, sesje rozpoczynają się, gdy pojawi się co najmniej jeden komunikat z identyfikatorem sesji. Gdy sesja istnieje, nie ma zdefiniowanego czasu ani interfejsu API, gdy sesja wygaśnie lub zniknie. Teoretycznie można odebrać komunikat dla sesji dzisiaj, następny komunikat w ciągu roku, a jeśli identyfikator sesji jest zgodny, sesja jest taka sama z perspektywy usługi Service Bus.

Zazwyczaj jednak aplikacja definiuje, gdzie rozpoczyna się i kończy zestaw powiązanych komunikatów. Usługa Service Bus nie nakłada żadnych określonych reguł. Na przykład aplikacja może ustawić właściwość Label dla pierwszego komunikatu jako początkowego, dla komunikatów pośrednich jako zawartości i ostatniego komunikatu na końcu. Względne położenie komunikatów zawartości można obliczyć jako różnicę bieżącego SequenceNumber komunikatu i początkowego komunikatu SequenceNumber.

Ważne

Gdy sesje są włączone w kolejce lub subskrypcji, aplikacje klienckie nie mogą już wysyłać/odbierać zwykłych komunikatów. Klienci muszą wysyłać komunikaty w ramach sesji, ustawiając identyfikator sesji i odbierając je, akceptując sesję. Klienci mogą nadal podejrzeć kolejkę lub subskrypcję z włączonymi sesjami. Zobacz Przeglądanie komunikatów.

API dla sesji są dostępne w klientach kolejki i subskrypcji. Istnieje model imperatywny, który kontroluje, kiedy sesje i komunikaty są odbierane, oraz model oparty na procedurze obsługi, który ukrywa złożoność zarządzania pętlą odbierania.

W przypadku przykładów użyj linków w sekcji Przykłady .

Funkcje sesji

Sesje umożliwiają równoczesne demultipleksowanie przeplatanych strumieni komunikatów, zapewniając uporządkowane i gwarantowane dostarczanie.

Diagram pokazujący, jak funkcja sesji zachowuje uporządkowaną dostawę.

Klient tworzy odbiornik sesji w celu zaakceptowania sesji. Gdy klient akceptuje i utrzymuje sesję, posiada wyłączną blokadę na wszystkie komunikaty z identyfikatorem tej sesji w kolejce lub subskrypcji. Utrzymuje wyłączne blokady dla wszystkich komunikatów z identyfikatorem sesji, które przychodzą później.

Blokada jest zwalniana po wywołaniu metod zamknięcia odbiornika lub po wygaśnięciu blokady. Istnieją również metody na odbiorniku, aby odnowić blokady. Zamiast tego możesz użyć funkcji automatycznego odnawiania blokady, w której można określić czas trwania, przez który chcesz nadal odnawiać blokadę. Blokada sesji powinna być traktowana jak blokada wyłączna na pliku, co oznacza, że aplikacja powinna zamknąć sesję tak szybko, jak tylko przestanie być potrzebna i/lub nie będzie oczekiwać żadnych dalszych wiadomości.

Gdy wielu równoczesnych odbiorców pobiera z kolejki, komunikaty należące do określonej sesji są wysyłane do określonego odbiorcy, który aktualnie posiada blokadę dla tej sesji. W przypadku tej operacji przeplatany strumień komunikatów w jednej kolejce lub subskrypcji jest dokładnie zdemultipleksowany na różne odbiorniki, a te odbiorniki mogą również działać na różnych maszynach klienckich, ponieważ zarządzanie blokadą odbywa się po stronie usługi wewnątrz usługi Service Bus.

Poprzednia ilustracja przedstawia trzy odbiorniki sesji działające równocześnie. Jedna sesja o wartości SessionId = 4 nie ma aktywnego klienta właściciela, co oznacza, że z tej konkretnej sesji nie są przesyłane żadne komunikaty. Sesja działa na wiele sposobów, takich jak kolejka podrzędna.

Blokada sesji posiadana przez odbiornik sesji jest parasolem dla blokad komunikatów używanych przez tryb rozliczenia peek-lock. Tylko jeden odbiornik może mieć blokadę na sesję. Odbiornik może mieć wiele wiadomości w locie, ale są one odbierane w kolejności. Porzucenie komunikatu powoduje ponowne obsłużenie tego samego komunikatu przy użyciu następnej operacji odbierania.

Stan sesji wiadomości

Gdy przepływy pracy są przetwarzane w systemach w chmurze o wysokiej dostępności na dużą skalę, procedura obsługi przepływu pracy skojarzona z określoną sesją musi być w stanie odzyskać sprawność po nieoczekiwanych awariach i może wznowić częściowo ukończoną pracę nad innym procesem lub maszyną, z której rozpoczęto pracę.

Funkcja stanu sesji umożliwia zdefiniowaną przez aplikację adnotację sesji komunikatu wewnątrz brokera, dzięki czemu zarejestrowany stan przetwarzania względem tej sesji staje się natychmiast dostępny, gdy sesja zostanie nabyta przez nowy procesor.

Z perspektywy usługi Service Bus stan sesji komunikatu jest nieprzezroczystym obiektem binarnym, który może przechowywać dane o rozmiarze jednego komunikatu, czyli 256 KB dla usługi Service Bus Standard i 100 MB dla usługi Service Bus Premium. Stan przetwarzania w odniesieniu do sesji może być przechowywany wewnątrz stanu sesji, lub stan sesji może wskazywać miejsce przechowywania lub rekord w bazie danych, który przechowuje takie informacje.

Metody zarządzania stanem sesji, SetStatei GetState, można znaleźć w obiekcie odbiornika sesji. Sesja, która wcześniej nie miała stanu sesji, zwraca odwołanie o wartości null dla elementu GetState. Poprzednio ustawiony stan sesji można wyczyścić, przekazując wartość null do SetState metody w odbiorniku.

Stan sesji pozostaje tak długo, jak nie jest wyczyszczony (zwraca wartość null), nawet jeśli wszystkie komunikaty w sesji są przetworzone.

Stan sesji przechowywany w kolejce lub w subskrypcji jest liczony do kwoty przechowywania tej jednostki. Po zakończeniu pracy aplikacji z sesją zaleca się, aby aplikacja oczyściła stan zachowany, aby uniknąć kosztów zarządzania zewnętrznego.

Wpływ liczby dostaw

Definicja liczby dostarczeń na wiadomość w kontekście sesji różni się nieznacznie od definicji w przypadku, gdy sesji brak. Oto tabela podsumowująca, gdy liczba dostaw jest zwiększana.

Scenariusz Czy liczba dostarczeń komunikatu jest zwiększana
Sesja jest akceptowana, ale blokada sesji wygasa (z powodu przekroczenia limitu czasu) Tak
Sesja jest akceptowana, komunikaty w sesji nie są ukończone (nawet jeśli są zablokowane), a sesja jest zamknięta Nie.
Sesja jest akceptowana, komunikaty są ukończone, a następnie sesja jest jawnie zamknięta Nie dotyczy (jest to standardowy przepływ. W tym miejscu komunikaty są usuwane z sesji)

Wzorzec odpowiedzi na żądanie

Wzorzec odpowiedzi na żądanie jest dobrze ugruntowanym wzorcem integracji, który umożliwia aplikacji nadawcy wysyłanie żądania i umożliwia odbiorcy prawidłowe wysyłanie odpowiedzi z powrotem do aplikacji nadawcy. Ten wzorzec zazwyczaj wymaga krótkotrwałej kolejki lub tematu, na które aplikacja może wysyłać odpowiedzi. W tym scenariuszu sesje zapewniają proste rozwiązanie alternatywne z porównywalną semantyką.

Wiele aplikacji może wysyłać żądania do jednej kolejki żądań z określonym parametrem nagłówka ustawionym w celu unikatowego zidentyfikowania aplikacji nadawcy. Aplikacja odbiorcy może przetwarzać żądania przychodzące w kolejce i wysyłać odpowiedzi w kolejce z włączoną sesją, ustawiając identyfikator sesji na unikatowy identyfikator, który nadawca wysłał w komunikacie żądania. Aplikacja, która wysłała żądanie, może następnie odbierać komunikaty o określonym identyfikatorze sesji i prawidłowo przetwarzać odpowiedzi.

Uwaga

Aplikacja, która wysyła początkowe żądania, powinna wiedzieć o identyfikatorze sesji i użyć jej do zaakceptowania sesji, aby sesja, w której oczekuje odpowiedzi, została zablokowana. Dobrym pomysłem jest użycie identyfikatora GUID, który jednoznacznie identyfikuje wystąpienie aplikacji jako identyfikator sesji. Nie powinna istnieć procedura obsługi sesji ani limit czasu określony w odbiorniku sesji dla kolejki, w celu zapewnienia, że odpowiedzi są dostępne do zablokowania i przetwarzania przez określone odbiorniki.

Sekwencjonowanie vs. sesje

Numer sekwencji samodzielnie gwarantuje kolejność kolejkowania i kolejność wyodrębniania komunikatów, ale nie kolejność przetwarzania, która wymaga sesji.

Załóżmy, że w kolejce znajdują się trzy wiadomości i dwóch odbiorców.

  1. Użytkownik 1 odbiera komunikat 1.
  2. Użytkownik 2 odbiera komunikat 2.
  3. Konsument 2 kończy przetwarzanie komunikatu 2 i odbiera komunikat 3, podczas gdy konsument 1 jeszcze nie skończył przetwarzania komunikatu 1.
  4. Konsument 2 kończy przetwarzanie komunikatu 3, ale konsument 1 nadal nie zakończył przetwarzania komunikatu 1.
  5. Na koniec użytkownik 1 kończy przetwarzanie komunikatu 1.

Komunikaty są przetwarzane w tej kolejności: komunikat 2, komunikat 3 i komunikat 1. Jeśli potrzebujesz, aby komunikaty 1, 2 i 3 były przetworzone w odpowiedniej kolejności, musisz użyć sesji.

Jeśli komunikaty muszą być pobierane tylko w kolejności, nie trzeba używać sesji. Jeśli komunikaty muszą być przetwarzane w kolejności, użyj sesji. Ten sam identyfikator sesji powinien być ustawiony na komunikaty, które należą do siebie, które mogą być komunikatami 1, 4 i 8 w zestawie oraz 2, 3 i 6 w innym zestawie.

Wygaśnięcie wiadomości

W przypadku kolejek lub subskrypcji tematów z obsługą sesji komunikaty są blokowane na poziomie sesji. Jeśli czas wygaśnięcia (TTL) dla dowolnego komunikatu wygaśnie, wszystkie komunikaty związane z tej sesji zostaną porzucone lub utracony na podstawie utraconych komunikatów włączonych w przypadku ustawienia 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. Aby uzyskać więcej informacji, zobacz Wygaśnięcie komunikatu.

Przykłady

Sesje komunikatów można włączyć podczas tworzenia kolejki przy użyciu witryny Azure Portal, programu PowerShell, interfejsu wiersza polecenia, szablonu usługi Resource Manager, platformy .NET, języka Java, języka Python i języka JavaScript. Aby uzyskać więcej informacji, zobacz Włączanie sesji komunikatów.

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

Powiązana zawartość