Udostępnij za pośrednictwem

Sesje komunikatów

  • Artykuł

Sesje usługi Azure Service Bus umożliwiają wspólną i uporządkowaną obsługę niepowiązanych sekwencji powiązanych komunikatów. Sesje mogą być używane w pierwszym na, pierwszy na wyjęcie (FIFO) i wzorce odpowiedzi żądań . 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. Sesje są obsługiwane w warstwach Standardowa i Premium. Aby uzyskać różnice między tymi warstwami, zobacz Cennik usługi Service Bus.

Wzorzec pierwszy w, pierwszy na wyjęcie (FIFO)

Aby zrealizować gwarancję FIFO w przetwarzaniu komunikatów w kolejkach lub subskrypcjach 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.

Każdy nadawca może utworzyć sesję podczas przesyłania komunikatów do tematu lub kolejki, ustawiając właściwość identyfikatora sesji na określony przez aplikację identyfikator unikatowy dla sesji. 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 wchodzą w życie, gdy istnieje 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 ma jasne pojęcie, gdzie rozpoczyna się i kończy zestaw powiązanych komunikatów. Usługa Service Bus nie ustawia żadnych określonych reguł. Na przykład aplikacja może ustawić właściwość Label dla pierwszego komunikatu, aby komunikaty pośrednie do zawartości i ostatniego komunikatu zakończyły się. Względne położenie komunikatów zawartości można obliczyć jako bieżącą różnicę sekwencji komunikatów z początkowego elementu SequenceNumber.

Ważne

Gdy sesje są włączone w kolejce lub subskrypcji, aplikacje klienckie nie mogą już wysyłać/odbierać zwykłych komunikatów. Wszystkie komunikaty muszą być wysyłane w ramach sesji (przez ustawienie identyfikatora sesji) i odebrane przez zaakceptowanie sesji. Klienci mogą nadal zajrzeć do kolejki lub subskrypcji, która ma włączone sesje. Zobacz Przeglądanie komunikatów.

Interfejsy API dla sesji istnieją na 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 Następne kroki .

Funkcje sesji

Sesje zapewniają współbieżne demultiplexing przeplatanych strumieni komunikatów przy zachowaniu i zagwarantowaniu uporządkowanego dostarczania.

Diagram that shows how the Sessions feature preserves an ordered delivery.

Odbiorca sesji jest tworzony przez klienta akceptującego sesję. Gdy sesja jest akceptowana i przechowywana przez klienta, klient przechowuje wyłączną blokadę dla wszystkich komunikatów o identyfikatorze sesji tej sesji w kolejce lub subskrypcji. Przechowuje on blokady na wyłączność dla wszystkich komunikatów z identyfikatorem sesji, które docierają później.

Blokada jest zwalniana po wywołaniu metod zamknięcia odbiornika lub po wygaśnięciu blokady. Istnieją metody na odbiorniku, aby odnowić blokady, jak również. 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 w pliku, co oznacza, że aplikacja powinna zamknąć sesję tak szybko, jak nie potrzebuje go i/lub nie oczekuje żadnych dalszych komunikatów.

Gdy wielu równoległych odbiorów ściąga z kolejki, komunikaty należące do określonej sesji są wysyłane do określonego odbiorcy, który posiada obecnie blokadę dla tej sesji. W przypadku tej operacji przeplatany strumień komunikatów w jednej kolejce lub subskrypcji jest dokładnie demultiplexed do różnych odbiorników, 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.

Na poprzedniej ilustracji przedstawiono trzy współbieżne odbiorniki sesji. Jedna sesja z SessionId = 4 nie ma aktywnego klienta będącego właścicielem, co oznacza, że żadne komunikaty nie są dostarczane z tej konkretnej sesji. Sesja działa na wiele sposobów, takich jak kolejka podrzędna.

Blokada sesji przechowywana przez odbiornik sesji jest parasolem dla blokad komunikatów używanych przez tryb rozliczenia podglądu blokady . Tylko jeden odbiornik może mieć blokadę w sesji. Odbiornik może mieć wiele komunikatów w locie, ale komunikaty są odbierane w kolejności. Porzucenie komunikatu powoduje ponowne obsłużenie tego samego komunikatu przy użyciu następnej operacji odbierania.

Stan sesji komunikatu

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 względem sesji może być przechowywany wewnątrz stanu sesji lub stan sesji może wskazywać lokalizację magazynu lub rekord bazy danych, który przechowuje takie informacje.

Metody zarządzania stanem SetState sesji i 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 czyszczone (zwraca wartość null), nawet jeśli wszystkie komunikaty w sesji są używane.

Stan sesji przechowywany w kolejce lub w subskrypcji jest liczone do limitu przydziału magazynu 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 dostarczania na komunikat w kontekście sesji różni się nieznacznie od definicji w przypadku braku sesji. Oto tabela podsumowująca, gdy liczba dostaw jest zwiększana.

Scenariusz Czy liczba dostarczania 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ótkiej kolejki lub tematu, do których aplikacja 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 powinno istnieć żadne procedury obsługi sesji ani limit czasu określony w odbiorniku sesji dla kolejki, aby upewnić się, że odpowiedzi są dostępne do zablokowania i przetwarzania przez określone odbiorniki.

Sekwencjonowanie a 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 komunikaty i dwa odbiorcy.

  1. Użytkownik 1 odbiera komunikat 1.
  2. Użytkownik 2 odbiera komunikat 2.
  3. Użytkownik 2 kończy przetwarzanie komunikatu 2 i odbiera komunikat 3, podczas gdy użytkownik 1 nie jest jeszcze wykonywany z przetwarzaniem komunikatu 1.
  4. Użytkownik 2 kończy przetwarzanie komunikatu 3, ale konsument 1 nadal nie jest jeszcze wykonywany z przetwarzaniem 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 komunikatu 1, 2 i 3 do przetworzenia w 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.

Następne kroki

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.