Sekwencyjny wzorzec konwoju

Grupuj powiązane komunikaty według klucza kategorii i przetwarzaj poszczególne grupy sekwencyjnie, jeden komunikat jednocześnie, jednocześnie przetwarzając różne grupy.

Ten wzorzec rozwiązuje napięcie między utrzymywaniem poprawności pierwszego wyjścia (FIFO) w każdej grupie logicznej i skalowaniem współbieżnego przetwarzania między grupami. Architektura zapewnia, że ograniczenia kolejności nie stają się wąskim gardłem w skali całego systemu.

Kontekst i problem

Aplikacje często muszą przetwarzać powiązane komunikaty w kolejności ich nadejścia, przy jednoczesnym skalowaniu horyzontalnym, aby obsłużyć większe obciążenie. W architekturze rozproszonej spełnienie tego wymagania jest trudne, ponieważ procesy robocze niezależnie pobierają komunikaty ze współdzielonej kolejki. Gdy wielu pracowników rywalizuje o wiadomości, jak we wzorcu Competing Consumers, kolejność przestaje być zachowywana.

Rozważ system śledzenia zamówień, który odbiera strumień operacji, takich jak tworzenie zamówienia, dodawanie transakcji, modyfikowanie poprzedniej transakcji i usuwanie zamówienia. Operacje każdego zamówienia muszą być przetwarzane w kolejności FIFO, ponieważ zastosowanie ich poza kolejnością doprowadziłoby do uszkodzenia stanu zamówienia. Jednak kolejka przychodząca przeplata operacje z wielu zamówień. Pojedynczy konsument, który wymusza globalne zamawianie, staje się wąskim gardłem, a wielu odbiorców może przetwarzać operacje tego samego zamówienia poza sekwencją.

Proste podejścia do tego problemu można podzielić na inny sposób:

• Pojedynczy konsument. Pojedynczy odbiorca zachowuje kolejność komunikatów, ponieważ przetwarza jeden komunikat naraz, ale nie może skalować w celu obsługi zwiększonej przepływności.

• Wielu konkurencyjnych odbiorców. Wielu użytkowników skaluje przepływność, ściągając komunikaty równolegle, ale tracą gwarancje porządkowania poszczególnych grup. Dwa procesy robocze mogą pobierać kolejne komunikaty dla tego samego zamówienia i przetwarzać je jednocześnie lub w niewłaściwej kolejności, co prowadzi do uszkodzenia stanu zamówienia.

Solution

Wzorzec Sequential Convoy dzieli powiązane komunikaty na kategorie i przetwarza każdą kategorię sekwencyjnie, po jednym komunikacie naraz, podczas gdy same kategorie są przetwarzane równolegle.

Wzorzec działa przez przypisanie każdego komunikatu klucza kategorii, który identyfikuje grupę, do którą należy. Broker komunikatów używa tego klucza do partycjonowania komunikatów w grupach logicznych. W każdej grupie broker wymusza kolejność FIFO, tak aby konsument, który zablokuje grupę, odbierał komunikaty dokładnie w takiej kolejności, w jakiej zostały umieszczone w kolejce. Różne grupy mogą być przetwarzane jednocześnie przez różnych konsumentów, dzięki czemu system skaluje się poziomo między grupami bez naruszania kolejności w obrębie każdej pojedynczej grupy.

W Azure sesje komunikatów Azure Service Bus zapewniają wbudowaną implementację tego wzorca.

Na poniższym diagramie przedstawiono ogólny wzorzec konwoju sekwencyjnego.

Diagram przepływa od lewej do prawej i przedstawia trzy składniki. Po skrajnej lewej stronie znajduje się pole oznaczone etykietą „producer”. Strzałka prowadzi od producenta do centralnego pola oznaczonego jako „queue”. Z kolejki trzy strzałki wskazują po prawej stronie, z których każda ma etykietę o nazwie kategorii. Górna strzałka ma etykietę „kategoria A” i wskazuje ramkę oznaczoną etykietą „odbiorca A” w prawym górnym rogu. Środkowa strzałka jest oznaczona jako kategoria B i wskazuje prostokąt oznaczony jako „konsument B” po prawej stronie, pośrodku. Dolna strzałka ma etykietę „kategoria C” i wskazuje pole z etykietą „konsument C” w prawym dolnym rogu. Trzy oddzielne linie prowadzące od kolejki do trzech odbiorców ilustrują, że kolejka partycjonuje komunikaty według klucza kategorii. Kieruje komunikaty każdej kategorii wyłącznie do odpowiedniego konsumenta, co pozwala każdemu odbiorcy przetwarzać swoje strumienie komunikatów równolegle i w kolejności FIFO bez zakłócania siebie.

W kolejce komunikaty dla różnych kategorii mogą być przeplatane, jak pokazano na poniższym diagramie.

Diagram przedstawia wnętrze pojedynczej kolejki renderowanej jako szeroki prostokątny obszar. Wewnątrz kolejki cztery poziome pasy są ułożone pionowo i ponumerowane od 1 do 4 przy prawej krawędzi, a każdy z nich ma strzałkę skierowaną w prawo, wskazującą kierunek przepływu komunikatów. Na pasie 1 znajdują się cztery bloki komunikatów rozłożone na całej szerokości kolejki, co wskazuje na dużą liczbę komunikatów w tej kategorii. Ścieżka 2 również zawiera cztery bloki komunikatów, rozmieszczone na całej szerokości. Pas 3 zawiera trzy bloki wiadomości, a pas 4 zawiera pojedynczy blok wiadomości umieszczony bliżej prawej strony kolejki. Zróżnicowane pozycje i gęstości bloków komunikatów na poszczególnych pasach ilustrują, że komunikaty ze wszystkich czterech kategorii napływają naprzemiennie do tej samej współdzielonej kolejki. Pomimo tego przeplatania komunikaty każdej kategorii zachowują kolejność przybycia od lewej do prawej w odpowiednim pasie ruchu, pokazując, że kolejność FIFO dla kategorii jest zachowywana nawet w przypadku, gdy różne kategorie mają jedną strukturę kolejki.

Ten wzorzec zapewnia kilka kluczowych korzyści:

• Przetwarzanie uporządkowane na grupę. Komunikaty w każdej kategorii są przetwarzane ściśle sekwencyjnie, co zapobiega warunkom wyścigu, modyfikacjom stanu wykonywanym poza kolejnością oraz konieczności stosowania obejść związanych ze zmianą kolejności.

• Skalowanie poziome między grupami. Każda kategoria jest niezależną jednostką współbieżności. Dodanie odbiorców zwiększa przepustowość proporcjonalnie do liczby aktywnych kategorii, bez naruszania gwarancji kolejności.

• Oddzielenie producenta-konsumenta. Producenci umieszczają wiadomości w kolejce, nie wiedząc, który konsument je przetworzy ani kiedy. Konsumenci są niezależnie skalowalni i zamienialni.

Problemy i zagadnienia

Podczas podejmowania decyzji o zaimplementowaniu tego wzorca należy wziąć pod uwagę następujące kwestie:

• Kategoria i jednostka skalowania. Określ, na podstawie której właściwości przychodzących komunikatów można skalować horyzontalnie. Klucz kategorii definiuje jednostkę równoległości: każda odrębna wartość klucza staje się grupą niezależnie przetwarzalną. W scenariuszu śledzenia zamówienia ta właściwość jest identyfikatorem zamówienia. Wybór klucza, który jest zbyt ogólny (na przykład jednego identyfikatora klienta dla wszystkich zamówień), ogranicza równoległość, natomiast wybór klucza, który jest zbyt szczegółowy, nie zapewnia istotnych korzyści w zakresie porządkowania.

• Limity przepływności. Oceń docelową przepływność komunikatów. Ponieważ ten wzorzec wymusza przetwarzanie sekwencyjne w każdej kategorii, przepływność na kategorię jest ograniczona przez czas przetwarzania pojedynczego komunikatu. Zoptymalizuj czas przetwarzania pojedynczego komunikatu, na przykład przez zastosowanie asynchronicznych operacji wejścia/wyjścia lub grupowania zapisów do systemów podrzędnych, ponieważ czas ten bezpośrednio określa maksymalną przepustowość w każdej kategorii. Jeśli ogólne wymaganie dotyczące przepływności jest bardzo wysokie, należy rozważyć, czy w całym cyklu życia komunikatów konieczne jest ścisłe porządkowanie FIFO. Alternatywy obejmują wymuszenie komunikatu początkowego i końcowego w celu wyznaczenia granic sekwencji albo sortowanie komunikatów według znacznika czasu w ramach okna przetwarzania wsadowego, a następnie wysłanie partii do przetwarzania równoległego.

• Możliwości usługi. Sprawdź, czy wybrany broker komunikatów obsługuje jednorazowe przetwarzanie komunikatów w kolejce lub kategorii kolejki. Nie wszystkie usługi obsługi komunikatów zapewniają blokowanie na poziomie sesji lub gwarancje FIFO w ramach partycji. Jeśli broker nie obsługuje natywnie tej możliwości, konsument musi zaimplementować własną logikę koordynacji, która zwiększa złożoność i ryzyko duplikowania przetwarzania, nieodebranych komunikatów lub wykonywania poza kolejnością. Obsługa sesji może również ograniczać wybór warstwy komunikatów lub SKU, co wpływa na koszty.

• Zdolność do ewolucji. Zaplanuj dodawanie nowych kategorii komunikatów do systemu. Wzorzec musi uwzględniać wzrost kardynalności kategorii bez konieczności wprowadzania zmian strukturalnych dla konsumentów. Załóżmy na przykład, że opisany wcześniej system rejestru jest specyficzny dla jednego klienta. Jeśli musisz wdrożyć nowego klienta, powinieneś móc dodać zestaw procesorów rejestru, które rozdzielają pracę według identyfikatora klienta, bez konieczności przeprojektowywania topologii kolejki.

• Dostarczanie komunikatów w niewłaściwej kolejności. Komunikaty mogą docierać poza kolejnością z powodu zmiennych opóźnień sieciowych między producentem a brokerem, zanim zacznie obowiązywać porządkowanie sesji brokera. Rozważ użycie numerów sekwencji w celu zweryfikowania kolejności w każdej kategorii. Możesz również uwzględnić flagę końca sekwencji w ostatnim komunikacie transakcji, aby użytkownicy mogli wykryć, kiedy sekwencja zostanie ukończona.

• Obsługa błędnych komunikatów. Komunikat, który wielokrotnie kończy się niepowodzeniem przetwarzania w ramach sesji, blokuje wszystkie kolejne komunikaty w tej sesji, ponieważ wzorzec wymusza ścisłe kolejność sekwencyjne. Zaprojektuj strategię wykrywania problematycznych komunikatów, na przykład przez śledzenie liczby prób dostarczenia, i przenoś je do kolejki komunikatów martwych po przekroczeniu określonego limitu ponowień, aby pozostałe komunikaty w sesji mogły być dalej przetwarzane.

• Dostępność brokera. Broker komunikatów jest współdzieloną zależnością dla wszystkich kategorii. Jego dostępność i trwałość bezpośrednio wpływają na gwarancje niezawodności wzorca. Oceń mechanizmy odporności na poziomie brokera, takie jak strefy dostępności i geograficzne odzyskiwanie po awarii, w oparciu o wymagania dotyczące dostępności obciążenia i dostępny budżet, ponieważ konfiguracje zapewniające większą trwałość zwykle wiążą się z wyższymi kosztami.

• Poprawność klucza producenta. Wzorzec zakłada, że producenci poprawnie ustawiają klucz kategorii (identyfikator sesji) dla każdego komunikatu. Jeśli producent ustawia nieprawidłowy klucz, przypadkowo lub z powodu usterki, komunikat kieruje do nieprawidłowej sesji i uszkodzi stan tej grupy. Upewnij się, że producenci przypisują klucze kategorii w sposób spójny, i rozważ dodanie logiki walidacji kluczy po stronie odbiorcy, jeśli skutki błędnie skierowanej wiadomości są poważne.

• Złożoność operacyjna. Monitorowanie przetwarzania opartego na sesjach wiąże się z większym narzutem operacyjnym niż standardowe korzystanie z kolejki. Operatorzy potrzebują wglądu w zaległości w sesjach (liczbę aktywnych sesji oraz liczbę komunikatów oczekujących w każdej sesji), aby zidentyfikować kategorie, które pozostają w tyle. Sesje z komunikatami utraconymi wymagają oddzielnego przepływu pracy monitorowania i korygowania w celu zbadania komunikatów, rozwiązania głównej przyczyny i ponownego odtworzenia poprawionych komunikatów z powrotem do sesji.

• Rywalizacja o blokadę sesji i opóźnienie. Blokowanie sesji powoduje dodatkowe opóźnienia, ponieważ każdy odbiorca musi uzyskać wyłączną blokadę sesji przed przetworzeniem komunikatów. Gdy użytkownik przechowuje blokadę sesji, żaden inny użytkownik nie może przetwarzać komunikatów z tej sesji, nawet jeśli konsument jest powolny lub tymczasowo zatrzymany. Jeśli czas trwania blokady jest zbyt krótki, wygaśnięcie blokady może spowodować ponowne przetwarzanie komunikatów. Jeśli czas trwania blokady jest za długi, zatrzymany konsument opóźni odzyskiwanie. Dostosuj czas trwania blokady sesji na podstawie oczekiwanego czasu przetwarzania komunikatów i zaimplementuj odnawianie blokady na potrzeby długotrwałych operacji.

• Skalowanie po stronie konsumenta i koszty. Równoległość między sesjami przekłada się na współbieżne wystąpienia konsumentów. W modelu bezserwerowym, takim jak Azure Functions, każda aktywna sesja odpowiada współbieżnemu wykonaniu, a w modelu dedykowanym — instancji lub wątkowi. Liczba aktywnych sesji ma zatem bezpośredni wpływ na koszt obliczeniowy. Planuj limity skalowania odbiorców i mechanizmy kontroli współbieżności, aby zrównoważyć przepustowość względem kosztów.

Kiedy należy używać tego wzorca

Użyj tego wzorca, gdy:

• Komunikaty są dostarczane w kolejności i muszą być przetwarzane w tej samej kolejności.
• Komunikaty można podzielić na kategorie, aby każda kategoria stała się niezależną jednostką skalowania dla systemu.

Ten wzorzec może nie być odpowiedni w następujących przypadkach:

• Oczekujesz scenariuszy o bardzo wysokiej przepływności (miliony komunikatów na minutę), ponieważ wymaganie FIFO ogranicza skalowanie, które system może osiągnąć.

• Kolejność komunikatów nie jest wymagana. Gdy komunikaty mogą być przetwarzane niezależnie, w dowolnej kolejności, wzorzec konkurencyjnych konsumentów zapewnia prostsze skalowanie w poziomie bez narzutu związanego z koordynacją wymaganą przez blokowanie sesji.

Projektowanie obciążenia pracy

Oceń, jak użyć wzorca Sequential Convoy w projekcie obciążenia roboczego, aby uwzględnić cele i zasady omówione w filarach platformy Azure Well-Architected Framework. Poniższa tabela zawiera wskazówki dotyczące tego, jak ten wzorzec obsługuje cele poszczególnych filarów.

Filar	Jak ten wzorzec obsługuje cele filaru
Decyzje projektowe dotyczące niezawodności pomagają obciążeniom stały się odporne na awarię i zapewniają, że zostanie ono przywrócone do w pełni funkcjonalnego stanu po wystąpieniu awarii.	Ten wzorzec wykorzystuje porządkowanie FIFO oparte na sesjach, aby wyeliminować warunki wyścigu, logikę obsługi komunikatów podatną na konflikty oraz inne obejścia problemu nieprawidłowej kolejności komunikatów, które mogą prowadzić do nieprawidłowego działania. - RE:02 Przepływy krytyczne - RE:07 Zadania w tle

Jeśli ten wzorzec wprowadza kompromisy w ramach filaru, rozważ je przed celami innych filarów.

Example

W Azure można zaimplementować ten wzorzec przy użyciu sesji komunikatów Service Bus. Po stronie odbiorców można używać usługi Azure Logic Apps z łącznikiem Service Bus PeekLock albo usługi Azure Functions z wyzwalaczem Service Bus.

Gdy producent ustawia właściwość komunikatuSessionId, Service Bus grupuje wszystkie komunikaty, które mają ten sam identyfikator sesji w jednej sesji logicznej. Konsument akceptuje sesję i uzyskuje do niej blokadę wyłączną. Ta blokada gwarantuje, że tylko jeden odbiorca przetwarza komunikaty dla tej sesji w danym momencie oraz że komunikaty są dostarczane w kolejności FIFO. Inni użytkownicy mogą jednocześnie akceptować i przetwarzać różne sesje, zapewniając równoległą przepływność między grupami.

W przykładzie śledzenia zamówień system przetwarza każdy komunikat księgi w kolejności, w jakiej jest on odbierany, i wysyła każdą transakcję do kolejnej kolejki, gdzie jako kategorię ustawiono identyfikator zamówienia. Transakcja nigdy nie obejmuje wielu zamówień w tym scenariuszu, więc konsumenci przetwarzają poszczególne kategorie równolegle, ale w obrębie każdej z nich zgodnie z FIFO.

Procesor księgi rozsyła komunikaty, rozbijając na partie zawartość każdej wiadomości w pierwszej kolejce:

Diagram przepływa od lewej do prawej w pięciu etapach. Po lewej stronie znajduje się pole z etykietą „producer”. Strzałka prowadzi od producenta do pola oznaczonego etykietą „ledger queue”. Strzałka prowadzi od kolejki rejestru do pola oznaczonego jako „ledger processor”. Strzałka prowadzi od procesora rejestru do pola oznaczonego etykietą „kolejka transakcji”. Z kolejki transakcji trzy strzałki wskazują po prawej stronie, z których każda ma etykietę z kategorią sesji. Górna strzałka jest opisana etykietą „transakcje zamówienia A” i wskazuje na pole oznaczone etykietą „procesor zamówień A”. Środkowa strzałka jest opisana etykietą „transakcje zamówienia B” i wskazuje na pole oznaczone etykietą „procesor zamówień B”. Dolna strzałka jest opisana etykietą „transakcje zamówienia C” i wskazuje na pole oznaczone etykietą „procesor zamówień C”. Diagram ilustruje przejście z przetwarzania szeregowego do równoległego: producent wysyła wszystkie komunikaty sekwencyjnie przez kolejkę rejestru i procesor rejestru, a procesor rejestru ustawia identyfikator sesji każdego komunikatu na odpowiadający mu identyfikator zamówienia przed umieszczeniem go w kolejce transakcji. Następnie kolejka transakcji kieruje komunikaty każdego zamówienia wyłącznie do odpowiadającego mu procesora zamówień, co pozwala procesorowi zamówień A, procesorowi zamówień B i procesorowi zamówień C przetwarzać swoje sesje równolegle i w kolejności FIFO.

Procesor rejestru wykonuje trzy kroki:

1. Przechodzi przez księgę po jednej transakcji naraz.
2. Ustawia identyfikator sesji komunikatu, aby był zgodny z identyfikatorem zamówienia.
3. Wysyła każdą transakcję księgi do kolejki podrzędnej z identyfikatorem sesji ustawionym na identyfikator zamówienia.

Konsumenci nasłuchują kolejki wtórnej i przetwarzają wszystkie komunikaty, których identyfikatory zamówień są zgodne, w kolejności FIFO. Konsumenci korzystają z trybu peek-lock.

Kolejka rejestru jest punktem przejścia szeregowo-równoległym: wszystkie transakcje przechodzą przez nią sekwencyjnie przed rozpoczęciem przetwarzania równoległego opartego na sesji. Ten etap serializacji jest głównym wąskim gardłem skalowalności, ponieważ ogranicza przepustowość całego dalszego potoku przetwarzania. Jednak po przekazaniu komunikatów przez procesor rejestru do kolejki pomocniczej użytkownicy mogą skalować niezależnie między sesjami, po jednym na identyfikator zamówienia.

Technologie pomocnicze

• Sesje komunikatów usługi Service Bus: grupuje komunikaty według identyfikatora sesji i wymusza przetwarzanie FIFO w każdej sesji. Sesje komunikatów to podstawowy mechanizm Azure implementowania wzorca konwoju sekwencyjnego.

• Wyzwalacz usługi Service Bus w Azure Functions: obsługuje wyzwalacze oparte na sesjach, które umożliwiają instancjom funkcji przetwarzanie komunikatów z jednej sesji naraz.

• Łącznik Service Bus dla usługi Logic Apps: Udostępnia łącznik Service Bus z obsługą trybu peek-lock do obsługi kolejek z włączoną obsługą sesji w przetwarzaniu opartym na przepływie pracy.

Współautorzy

Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Główny autor:

• Naga Venkata Cheruvu | Starszy architekt rozwiązań chmurowych i infrastruktury AI

Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Powiązane zasoby

• Wzorzec konkurujących odbiorców: wielu użytkowników ściąga komunikaty z udostępnionej kolejki równolegle, co zwiększa przepływność, ale usuwa gwarancje porządkowania poszczególnych komunikatów. Wzorzec Sequential Convoy rozwiązuje problem z zachowaniem kolejności wprowadzany przez wzorzec Competing Consumers. Rozwiązuje to lukę, dzieląc komunikaty na sesje z kluczami kategorii i przetwarzając sekwencyjnie każdą sesję.

• Wzorzec równoważenia obciążenia oparty na kolejce: kolejka buforuje zadania między producentami a konsumentami, aby pochłaniać nagłe skoki i wyrównywać nierównomierne obciążenie. Wzorzec sekwencyjnego konwoju bazuje na tym buforowaniu, dodając partycjonowanie oparte na sesjach, dzięki czemu kolejka równoważy obciążenie między kategoriami, a jednocześnie zachowuje kolejność FIFO w obrębie każdej kategorii.

• Wzorzec kolejki priorytetowej: komunikaty są kierowane do oddzielnych kolejek lub określonego priorytetu w kolejce, dzięki czemu praca o wyższym priorytecie jest przetwarzana przed pracą o niższym priorytecie. Gdy konieczne jest również zachowanie kolejności w obrębie poziomu priorytetu, wzorzec Sequential Convoy można połączyć z kolejkowaniem według priorytetów, aby wymusić przetwarzanie FIFO w ramach każdej sesji identyfikowanej kluczem priorytetu.

• Peek-Lock Komunikat (odczyt niedestrukcyjny): ta operacja niepodziealnie pobiera i blokuje komunikat z kolejki lub subskrypcji na potrzeby przetwarzania.

• Jak zapewnić uporządkowane dostarczanie skorelowanych komunikatów w usłudze Logic Apps przy użyciu sesji Service Bus: we wpisie na blogu opisano obsługę wzorca Sequential Convoy w usłudze Logic Apps.