Partycjonowane kolejki i topiki

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ługiwany przez jednego brokera komunikatów i jeden magazyn wiadomości. 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 komunikatów nie powoduje niedostępności partycjonowanej kolejki ani tematu. Partycjonowane kolejki i tematy mogą zawierać wszystkie zaawansowane funkcje usługi Service Bus, takie jak obsługa transakcji i sesji.

Nie można zmienić opcji partycjonowania w żadnej istniejącej przestrzeni nazw, kolejce ani 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 komunikatów i zarządzana przez innego brokera komunikatów. Podczas wysyłania komunikatu do partycjonowanej kolejki lub tematu usługa Service Bus przypisuje komunikat do jednej z partycji. Usługa Service Bus wybiera partycję losowo lub używa klucza partycji określonego przez nadawcę.

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. Zwraca pierwszy komunikat pobierany 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 w jednostce niepartycyjnej zawsze zwraca najstarszy komunikat, ale nie w jednostce partycjonowanej. Zamiast tego zwraca najstarszą wiadomość z jednej z partycji, której broker wiadomości odpowiedział jako pierwszy. Nie ma gwarancji, że zwrócony komunikat jest najstarszy we wszystkich partycjach.

Nie ma dodatkowych kosztów podczas wysyłania lub odbierania wiadomości z partycjonowanej kolejki lub tematu.

Korzystanie z kluczy partycji

Usługa Service Bus sprawdza obecność klucza partycji, gdy kolejujesz komunikat do partycjonowanej kolejki lub tematu. 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. Usługa Service Bus przypisuje wszystkie komunikaty, które używają tego samego klucza partycji 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 ten sam broker komunikatów obsługuje wszystkie komunikaty należące do tej samej sesji. Korzystając z sesji, usługa Service Bus gwarantuje kolejność komunikatów, a także spójność 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 w komunikacie zostały ustawione zarówno identyfikator sesji, jak i 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. Użyj właściwości klucza partycji, jeśli nadawca wysyła transakcyjne komunikaty nieświadome sesji. Klucz partycji zapewnia, że ten sam broker obsługi komunikatów obsługuje wszystkie komunikaty wysyłane w ramach transakcji.

MessageId: Jeśli utworzysz kolejkę lub temat z funkcją wykrywania duplikatów i nie ustawisz właściwości identyfikatora sesji lub klucza partycji, wartość właściwości identyfikatora komunikatu będzie służyć jako klucz partycji. (Biblioteki klienckie firmy Microsoft automatycznie przypisują identyfikator ID komunikatu, jeśli aplikacja wysyłająca tego nie robi). W takim przypadku ten sam broker wiadomości obsługuje wszystkie kopie tego samego komunikatu. 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

Jeśli nie określisz 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. Nie uzyskujesz jednak 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 na umieszczenie wiadomości w innej partycji, czas wyczekiwania określony przez klienta wysyłającego wiadomość musi być dłuższy niż 15 sekund. Zalecana jest wartość domyślna 60 sekund.

Klucz partycji "przypina" komunikat do określonej partycji. Jeśli magazyn wiadomości, 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. W związku z tym nie należy podawać klucza partycji, chyba że jest to wymagane.

Tematy zaawansowane

Używanie transakcji z partycjonowanymi jednostkami

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, 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 ustawisz dowolną z właściwości, które służą jako klucz partycji, usługa Service Bus przypnie komunikat do określonej partycji. To zachowanie występuje niezależnie od tego, czy używasz transakcji. Nie należy określać klucza partycji, jeśli nie jest to konieczne.

Używanie transakcji w sesjach z partycjonowanymi jednostkami

Aby wysłać komunikat transakcyjny do tematu lub kolejki obsługującej sesję, ustaw właściwość identyfikatora sesji w komunikacie. Jeśli określisz właściwość klucza partycji, musi być taka sama jak właściwość identyfikatora sesji. Jeśli różnią się one, usługa Service Bus zwraca nieprawidłowy wyjątek operacji.

Jednak w przeciwieństwie do zwykłych (niepartycjonowanych) kolejek lub topiców, nie można użyć jednej transakcji do wysyłania wielu komunikatów do różnych sesji. Jeśli spróbujesz wykonać tę operację, 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 zawsze są 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. Tylko podzbiór ruchu napotyka problemy, 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 prowadzić do awarii 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ń odbiorczych frontend wykonuje operacje odbierania na wszystkich partycjach i buforuje całość otrzymanych odpowiedzi. Kolejne żądanie odbioru na tym samym połączeniu korzysta z tego buforowania, a opóźnienia odbioru są mniejsze. 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 ląduje 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. Zaleca się korzystanie z funkcji keep-alive w 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 nie używaj partycjonowania w tych scenariuszach. Usuń wszystkie istniejące jednostki partycjonowane i utwórz je ponownie z wyłączonym partycjonowaniem, aby zwiększyć wydajność.
• Przeglądaj/Zerknij na komunikaty: Operacja podglądania nie zawsze zwraca liczbę komunikatów, o którą się żąda. Dwa typowe przyczyny wyjaśniają to zachowanie. 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ą ich ilość. Ogólnie rzecz biorąc, jeśli aplikacja chce przejrzeć określoną liczbę komunikatów, powinna wywołać operację przeglądania wielokrotnie, dopóki nie uzyska tej liczby komunikatów lub nie ma więcej komunikatów do przejrzenia. 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:

• 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 wątków w przestrzeni nazw dla warstw 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).

Aby dowiedzieć się więcej na temat podstawowych pojęć dotyczących specyfikacji obsługi komunikatów protokołu ADVANCED Message Queuing Protocol ( AMQP) 1.0, zobacz przewodnik po protokole AMQP 1.0.