Partycjonowane kolejki i tematy

Usługa Azure Service Bus używa wielu brokerów komunikatów do przetwarzania komunikatów i wielu magazynów komunikatów do przechowywania komunikatów. Tradycyjna kolejka lub temat jest obsługiwana przez jednego brokera komunikatów i przechowywana w jednym magazynie obsługi komunikatów. Partycje usługi Service Bus umożliwiają partycjonowanie kolejek i tematów lub jednostek obsługi komunikatów między wieloma brokerami komunikatów i magazynami komunikatów. Partycjonowanie oznacza, że ogólna przepływność partycjonowanej jednostki nie jest już ograniczona przez wydajność pojedynczego brokera komunikatów lub magazynu komunikatów. Ponadto tymczasowa awaria magazynu obsługi komunikatów nie renderuje partycjonowanej kolejki ani tematu niedostępnego. Partycjonowane kolejki i tematy mogą zawierać wszystkie zaawansowane funkcje usługi Service Bus, takie jak obsługa transakcji i sesji.

Uwaga

Istnieją pewne różnice między jednostkami SKU w warstwie Podstawowa/Standardowa i Premium, jeśli chodzi o partycjonowanie.

• Partycjonowanie jest dostępne podczas tworzenia jednostek dla wszystkich kolejek i tematów w jednostkach SKU w warstwie Podstawowa lub Standardowa. Przestrzeń nazw może mieć jednostki partycjonowane i nieudzielone.
• Partycjonowanie jest dostępne podczas tworzenia przestrzeni nazw dla jednostki SKU obsługi komunikatów w warstwie Premium, a wszystkie kolejki i tematy w tej przestrzeni nazw zostaną podzielone na partycje. Wszystkie wcześniej zmigrowane jednostki podzielone na partycje w przestrzeniach nazw Premium będą nadal działać zgodnie z oczekiwaniami.
• Gdy partycjonowanie jest włączone w jednostkach SKU w warstwie Podstawowa lub Standardowa, zawsze utworzymy 16 partycji.
• W przypadku włączenia partycjonowania w jednostce SKU Premium ilość partycji jest określana podczas tworzenia przestrzeni nazw.

Nie można zmienić opcji partycjonowania w żadnej istniejącej przestrzeni nazw, kolejce lub temacie; Opcję można ustawić tylko podczas tworzenia jednostki.

Jak to działa

Każda partycjonowana kolejka lub temat składa się z wielu partycji. Każda partycja jest przechowywana w innym magazynie obsługi komunikatów i obsługiwana przez innego brokera komunikatów. Po wysłaniu komunikatu do partycjonowanej kolejki lub tematu usługa Service Bus przypisuje komunikat do jednej z partycji. Wybór odbywa się losowo przez usługę Service Bus lub przy użyciu klucza partycji, który może określić nadawca.

Gdy klient chce odbierać komunikat z partycjonowanej kolejki lub z subskrypcji do tematu podzielonego na partycje, usługa Service Bus wysyła zapytanie o wszystkie partycje dla komunikatów, a następnie zwraca pierwszy komunikat uzyskany z dowolnego magazynu komunikatów do odbiorcy. Usługa Service Bus buforuje inne komunikaty i zwraca je, gdy odbiera więcej żądań odbierania. Klient odbierający nie zna partycjonowania; zachowanie klienta podzielonej na partycje kolejki lub tematu (na przykład odczyt, ukończenie, odroczenie, zakleszczenia, pobieranie wstępne) jest identyczne z zachowaniem jednostki regularnej.

Operacja podglądu jednostki niepartycyjnej zawsze zwraca najstarszy komunikat, ale nie w jednostce partycjonowanej. Zamiast tego zwraca najstarszy komunikat w jednej z partycji, których broker komunikatów odpowiedział jako pierwszy. Nie ma gwarancji, że zwrócony komunikat jest najstarszy we wszystkich partycjach.

Podczas wysyłania komunikatu do lub odbierania komunikatu z partycjonowanej kolejki lub tematu nie ma dodatkowych kosztów.

Uwaga

Operacja podglądu zwraca najstarszy komunikat z partycji na podstawie numeru sekwencji. W przypadku jednostek partycjonowanych numer sekwencji jest wystawiany względem partycji. Aby uzyskać więcej informacji, zobacz Sekwencjonowanie komunikatów i znaczniki czasu.

Korzystanie z kluczy partycji

Gdy komunikat jest umieszczany w kolejce partycjonowanej lub temacie, usługa Service Bus sprawdza obecność klucza partycji. Jeśli go znajdzie, wybiera partycję na podstawie tego klucza. Jeśli nie znajdzie klucza partycji, wybiera partycję na podstawie algorytmu wewnętrznego.

Używanie klucza partycji

Niektóre scenariusze, takie jak sesje lub transakcje, wymagają przechowywania komunikatów w określonej partycji. Wszystkie te scenariusze wymagają użycia klucza partycji. Wszystkie komunikaty używające tego samego klucza partycji są przypisane do tej samej partycji. Jeśli partycja jest tymczasowo niedostępna, usługa Service Bus zwraca błąd.

W zależności od scenariusza różne właściwości komunikatu są używane jako klucz partycji:

SessionId: jeśli komunikat ma ustawioną właściwość identyfikatora sesji, usługa Service Bus używa go jako klucza partycji. Dzięki temu wszystkie komunikaty należące do tej samej sesji są obsługiwane przez tego samego brokera komunikatów. Sesje umożliwiają usłudze Service Bus zagwarantowanie kolejności komunikatów oraz spójności stanów sesji.

PartitionKey: jeśli komunikat ma właściwość klucza partycji, ale nie właściwość identyfikatora sesji, usługa Service Bus używa wartości właściwości klucza partycji jako klucza partycji. Jeśli komunikat ma zarówno identyfikator sesji, jak i ustawiono właściwości klucza partycji, obie właściwości muszą być identyczne. Jeśli właściwość klucza partycji jest ustawiona na inną wartość niż właściwość identyfikatora sesji, usługa Service Bus zwraca nieprawidłowy wyjątek operacji. Właściwość klucza partycji powinna być używana, jeśli nadawca wysyła niezrozumiene komunikaty transakcyjne. Klucz partycji gwarantuje, że wszystkie komunikaty wysyłane w ramach transakcji są obsługiwane przez tego samego brokera obsługi komunikatów.

MessageId: Jeśli kolejka lub temat został utworzony za pomocą funkcji wykrywania duplikatów, a identyfikator sesji lub właściwości klucza partycji nie są ustawione, wartość właściwości identyfikatora komunikatu służy jako klucz partycji. (Biblioteki klienckie firmy Microsoft automatycznie przypisują identyfikator komunikatu, jeśli aplikacja wysyłająca nie jest). W takim przypadku wszystkie kopie tego samego komunikatu są obsługiwane przez tego samego brokera komunikatów. Ten identyfikator umożliwia usłudze Service Bus wykrywanie i eliminowanie zduplikowanych komunikatów. Jeśli funkcja wykrywania duplikatów nie jest włączona, usługa Service Bus nie uwzględnia właściwości identyfikatora komunikatu jako klucza partycji.

Nieużywanie klucza partycji

W przypadku braku klucza partycji usługa Service Bus dystrybuuje komunikaty w sposób okrężny do wszystkich partycji partycjonowanej kolejki lub tematu. Jeśli wybrana partycja nie jest dostępna, usługa Service Bus przypisuje komunikat do innej partycji. W ten sposób operacja wysyłania zakończy się pomyślnie pomimo tymczasowej niedostępności magazynu komunikatów. Jednak nie uzyskasz gwarantowanej kolejności zapewnianej przez klucz partycji.

Aby uzyskać bardziej szczegółowe omówienie kompromisu między dostępnością (bez klucza partycji) i spójnością (przy użyciu klucza partycji), zobacz Dostępność i spójność w usłudze Event Hubs. Z wyjątkiem identyfikatora partycji, który nie jest uwidaczniany dla użytkowników, te informacje dotyczą jednakowo partycjonowanych jednostek usługi Service Bus.

Aby dać usłudze Service Bus wystarczająco dużo czasu, aby umieścić komunikat w kolejce do innej partycji, wartość limitu czasu określona przez klienta wysyłającego komunikat musi być większa niż 15 sekund. Zalecana jest wartość domyślna 60 sekund.

Klucz partycji "przypina" komunikat do określonej partycji. Jeśli magazyn obsługi komunikatów, który zawiera tę partycję, jest niedostępny, usługa Service Bus zwraca błąd. W przypadku braku klucza partycji usługa Service Bus może wybrać inną partycję, a operacja zakończy się pomyślnie. Dlatego zaleca się, aby nie podawać klucza partycji, chyba że jest to wymagane.

Tematy zaawansowane

Używanie transakcji z jednostkami podzielonymi na partycje

Komunikaty wysyłane w ramach transakcji muszą określać klucz partycji. Klucz może być jedną z następujących właściwości: identyfikator sesji, klucz partycji lub identyfikator komunikatu. Wszystkie komunikaty wysyłane w ramach tej samej transakcji muszą określać ten sam klucz partycji. Jeśli spróbujesz wysłać komunikat bez klucza partycji w ramach transakcji, usługa Service Bus zwróci wyjątek nieprawidłowej operacji. Jeśli spróbujesz wysłać wiele komunikatów w ramach tej samej transakcji z różnymi kluczami partycji, usługa Service Bus zwróci wyjątek nieprawidłowej operacji. Na przykład:

CommittableTransaction committableTransaction = new CommittableTransaction();
using (TransactionScope ts = new TransactionScope(committableTransaction))
{
    ServiceBusMessage msg = new ServiceBusMessage("This is a message");
    msg.PartitionKey = "myPartitionKey";
    await sender.SendMessageAsync(msg); 
    ts.Complete();
}
committableTransaction.Commit();

Jeśli ustawiono dowolną z właściwości, które pełnią rolę klucza partycji, usługa Service Bus przypią komunikat do określonej partycji. To zachowanie występuje niezależnie od tego, czy jest używana transakcja. Zaleca się, aby nie określać klucza partycji, jeśli nie jest to konieczne.

Używanie transakcji w sesjach z partycjonowaną jednostkami

Aby wysłać komunikat transakcyjny do tematu lub kolejki obsługującej sesję, komunikat musi mieć ustawioną właściwość identyfikatora sesji. Jeśli właściwość klucza partycji jest również określona, musi być identyczna z właściwością identyfikatora sesji. Jeśli różnią się one, usługa Service Bus zwraca nieprawidłowy wyjątek operacji.

W przeciwieństwie do zwykłych (niepartych) kolejek lub tematów nie można użyć jednej transakcji do wysyłania wielu komunikatów do różnych sesji. Jeśli podjęto próbę, usługa Service Bus zwróci wyjątek nieprawidłowej operacji. Na przykład:

CommittableTransaction committableTransaction = new CommittableTransaction();
using (TransactionScope ts = new TransactionScope(committableTransaction))
{
    ServiceBusMessage msg = new ServiceBusMessage("This is a message");
    msg.SessionId = "mySession";
    await sender.SendMessageAsync(msg); 
    ts.Complete();
}
committableTransaction.Commit();

Automatyczne przekazywanie komunikatów przy użyciu partycjonowanych jednostek

Usługa Service Bus obsługuje automatyczne przekazywanie komunikatów z jednostek partycjonowanych do lub między nimi. Tę funkcję można włączyć podczas tworzenia lub aktualizowania kolejek i subskrypcji. Aby uzyskać więcej informacji, zobacz Włączanie przekazywania komunikatów. Jeśli komunikat określa klucz partycji (identyfikator sesji, klucz partycji lub identyfikator komunikatu), ten klucz partycji jest używany dla jednostki docelowej.

Zagadnienia i wskazówki

• Funkcje wysokiej spójności: jeśli jednostka używa takich funkcji jak sesje, wykrywanie duplikatów lub jawna kontrola klucza partycjonowania, operacje obsługi komunikatów są zawsze kierowane do określonej partycji. Jeśli którykolwiek z partycji ma duży ruch lub magazyn bazowy jest w złej kondycji, te operacje kończą się niepowodzeniem i zmniejsza się dostępność. Ogólnie rzecz biorąc, spójność jest nadal znacznie wyższa niż jednostki niepartycyjne; występuje tylko podzbiór ruchu, w przeciwieństwie do całego ruchu. Aby uzyskać więcej informacji, zobacz tę dyskusję na temat dostępności i spójności.
• Zarządzanie: operacje, takie jak Tworzenie, aktualizowanie i usuwanie, muszą być wykonywane na wszystkich partycjach jednostki. Jeśli jakakolwiek partycja jest w złej kondycji, może to spowodować błędy dla tych operacji. W przypadku operacji Pobierz informacje, takie jak liczba komunikatów, muszą być agregowane ze wszystkich partycji. Jeśli jakakolwiek partycja jest w złej kondycji, stan dostępności jednostki jest zgłaszany jako ograniczony.
• Scenariusze komunikatów o niskim woluminie: w przypadku takich scenariuszy, szczególnie w przypadku korzystania z protokołu HTTP, może być konieczne wykonanie wielu operacji odbierania w celu uzyskania wszystkich komunikatów. W przypadku żądań odbierania fronton wykonuje odbieranie na wszystkich partycjach i buforuje wszystkie odebrane odpowiedzi. Kolejne żądanie odbioru na tym samym połączeniu skorzystałoby z tego buforowania i opóźnienia odbioru są niższe. Jeśli jednak masz wiele połączeń lub używasz protokołu HTTP, dla każdego żądania zostanie ustanowione nowe połączenie. W związku z tym nie ma gwarancji, że wylądowałby na tym samym węźle. Jeśli wszystkie istniejące komunikaty są zablokowane i buforowane w innym frontonie, operacja odbierania zwraca wartość null. Komunikaty w końcu wygasną i można je otrzymać ponownie. Zalecane jest zachowanie aktywności HTTP. W przypadku korzystania z partycjonowania w scenariuszach o małym woluminie operacje odbierania mogą trwać dłużej niż oczekiwano. W związku z tym zalecamy, aby nie używać partycjonowania w tych scenariuszach. Usuń wszystkie istniejące partycjonowane jednostki i utwórz je ponownie przy użyciu funkcji partycjonowania wyłączone w celu zwiększenia wydajności.
• Przeglądaj/Zapoznaj się z komunikatami: Operacja podglądu nie zawsze zwraca liczbę komunikatów, o które prosi. Istnieją dwa typowe przyczyny tego zachowania. Jednym z powodów jest to, że zagregowany rozmiar kolekcji komunikatów przekracza maksymalny rozmiar. Innym powodem jest to, że w partycjonowanych kolejkach lub tematach partycja może nie mieć wystarczającej liczby komunikatów, aby zwrócić żądaną liczbę komunikatów. Ogólnie rzecz biorąc, jeśli aplikacja chce zajrzeć/przejrzeć określoną liczbę komunikatów, powinna wywołać operację podglądu wielokrotnie, dopóki nie uzyska tej liczby komunikatów lub nie ma więcej komunikatów do zajrzeć. Aby uzyskać więcej informacji, w tym przykłady kodu, zobacz Przeglądanie komunikatów.

Ograniczenia jednostek partycjonowanych

Obecnie usługa Service Bus nakłada następujące ograniczenia dotyczące partycjonowanych kolejek i tematów:

• W przypadku partycjonowanych przestrzeni nazw w warstwie Premium rozmiar komunikatu jest ograniczony do 1 MB, gdy komunikaty są wysyłane indywidualnie, a rozmiar partii jest ograniczony do 1 MB, gdy komunikaty są wysyłane w partii.

• Partycjonowane kolejki i tematy nie obsługują wysyłania komunikatów należących do różnych sesji w jednej transakcji.

• Usługa Service Bus obecnie umożliwia maksymalnie 100 partycjonowanych kolejek lub tematów na przestrzeń nazw dla jednostki SKU w warstwie Podstawowa i Standardowa. Każda partycjonowana kolejka lub temat zlicza limit przydziału 10 000 jednostek na przestrzeń nazw.

Następne kroki

Partycjonowanie można włączyć 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 partycjonowania (Podstawowa/Standardowa).

Zapoznaj się z podstawowymi pojęciami dotyczącymi specyfikacji obsługi komunikatów protokołu AMQP (Advanced Message Queueing Protocol) 1.0 w przewodniku po protokole AMQP 1.0.