Przetwarzanie zestawu powiązanych komunikatów w zdefiniowanej kolejności bez blokowania przetwarzania innych grup komunikatów.
Kontekst i problem
Aplikacje często muszą przetwarzać sekwencję komunikatów w kolejności ich nadejścia, jednocześnie będąc w stanie skalować w poziomie w celu obsługi zwiększonego obciążenia. W architekturze rozproszonej przetwarzanie tych komunikatów w kolejności nie jest proste, ponieważ procesy robocze mogą skalować niezależnie i często ściągać komunikaty niezależnie przy użyciu wzorca konkurujących odbiorców.
Na przykład system śledzenia zamówień otrzymuje rejestr zawierający zamówienia i odpowiednie operacje na tych zamówieniach. Te operacje mogą być wykonywane w celu utworzenia zamówienia, dodania transakcji do zamówienia, zmodyfikowania poprzedniej transakcji lub usunięcia zamówienia. W tym systemie operacje muszą być wykonywane w sposób pierwszy na pierwszy na wyjście (FIFO), ale tylko na poziomie zamówienia. Jednak początkowa kolejka odbiera rejestr zawierający transakcje dla wielu zamówień, które mogą być przeplatane.
Rozwiązanie
Wypychanie powiązanych komunikatów do kategorii w systemie kolejkowania i blokowanie odbiorników kolejki i ściąganie tylko z jednej kategorii— jeden komunikat naraz.
Oto jak wygląda ogólny wzorzec konwoju sekwencyjnego:
W kolejce komunikaty dla różnych kategorii mogą być przeplatane, jak pokazano na poniższym diagramie:
Problemy i kwestie do rozważenia
Podczas podejmowania decyzji o sposobie wdrożenia tego wzorca należy rozważyć następujące punkty:
- Jednostka kategorii/skali. Jaka właściwość przychodzących wiadomości można skalować w poziomie? W scenariuszu śledzenia kolejności ta właściwość jest identyfikatorem zamówienia.
- Throughput. Jaka jest docelowa przepływność komunikatów? Jeśli jest bardzo wysoka, może być konieczne ponowne rozważenie wymagań FIFO. Na przykład czy można wymusić komunikat początkowy/końcowy, posortować według czasu, a następnie wysłać partię do przetwarzania?
- Możliwości usługi. Czy wybór magistrali komunikatów umożliwia jednorazowe przetwarzanie komunikatów w kolejce lub kategorii kolejki?
- Możliwość rozwoju. Jak dodać nową kategorię komunikatów do systemu? Załóżmy na przykład, że opisany powyżej system rejestru jest konkretnym klientem. Jeśli musisz dołączyć nowego klienta, czy masz zestaw procesorów rejestru, które dystrybuują pracę na identyfikator klienta?
- Istnieje możliwość, że użytkownicy mogą odbierać komunikat z zamówienia ze względu na zmienne opóźnienie sieci podczas wysyłania komunikatów. Rozważ użycie numerów sekwencji w celu zweryfikowania kolejności. Możesz również dołączyć specjalną flagę "koniec sekwencji" w ostatnim komunikacie transakcji. Technologie przetwarzania strumieniowego, takie jak Spark lub Azure Stream Analytics, mogą przetwarzać komunikaty w kolejności w przedziale czasu.
Kiedy używać tego wzorca
Użyj tego wzorca, gdy:
- Masz komunikaty, które są dostarczane w kolejności i muszą być przetwarzane w tej samej kolejności.
- Przychodzące komunikaty są lub mogą być "podzielone na kategorie" w taki sposób, że kategoria staje się jednostką skalowania dla systemu.
Ten wzorzec może nie być odpowiedni dla:
- Scenariusze o bardzo wysokiej przepływności (miliony komunikatów na minutę lub sekundę), ponieważ wymaganie FIFO ogranicza skalowanie, które można wykonać przez system.
Projekt obciążenia
Architekt powinien ocenić, w jaki sposób wzorzec konwoju sekwencyjnego może być używany w projekcie obciążenia, aby sprostać celom i zasadom opisanym w filarach platformy Azure Well-Architected Framework. Na przykład:
| Filar | Jak ten wzorzec obsługuje cele filaru |
|---|---|
| Decyzje projektowe dotyczące niezawodności pomagają obciążeniu stać się odporne na awarię i zapewnić, że zostanie przywrócony do w pełni funkcjonalnego stanu po wystąpieniu awarii. | Ten wzorzec może wyeliminować warunki wyścigu, które są trudne do rozwiązywania problemów, kontrowersyjnej obsługi komunikatów lub innych obejść dotyczących niepoprawnie uporządkowanych komunikatów, które mogą prowadzić do awarii. - RE:02 Przepływy krytyczne - RE:07 Zadania w tle |
Podobnie jak w przypadku każdej decyzji projektowej, należy rozważyć wszelkie kompromisy w stosunku do celów innych filarów, które mogą zostać wprowadzone przy użyciu tego wzorca.
Przykład
Na platformie Azure ten wzorzec można zaimplementować przy użyciu sesji komunikatów usługi Azure Service Bus. Dla użytkowników możesz użyć usługi Logic Apps z łącznikiem podglądu usługi Service Bus lub usługą Azure Functions z wyzwalaczem usługi Service Bus.
W poprzednim przykładzie śledzenia zamówień należy przetworzyć każdy komunikat rejestru w kolejności odebrania i wysłać każdą transakcję do innej kolejki, w której kategoria jest ustawiona na identyfikator zamówienia. Transakcja nigdy nie będzie obejmować wielu zamówień w tym scenariuszu, więc konsumenci przetwarzają każdą kategorię równolegle, ale fiFO w kategorii.
Procesor ledge outs komunikaty przez usunięcie partii zawartości każdego komunikatu w pierwszej kolejce:
Procesor rejestru zajmuje się:
- Spacerując rejestrem po jednej transakcji naraz.
- Ustawianie identyfikatora sesji komunikatu tak, aby był zgodny z identyfikatorem zamówienia.
- Wysyłanie każdej transakcji rejestru do kolejki pomocniczej z identyfikatorem sesji ustawionym na identyfikator zamówienia.
Odbiorcy nasłuchują kolejki pomocniczej, w której przetwarzają wszystkie komunikaty z pasującymi identyfikatorami zamówień w kolejności z kolejki. Użytkownicy korzystają z trybu podglądu blokady .
Biorąc pod uwagę skalowalność, kolejka rejestru jest podstawowym wąskim gardłem. Różne transakcje opublikowane w rejestrze mogą odwoływać się do tego samego identyfikatora zamówienia. Komunikaty mogą jednak być rozsyłane po liczbie zamówień w środowisku bezserwerowym.
Następne kroki
Następujące informacje mogą być istotne w przypadku implementowania tego wzorca: