Udostępnij za pośrednictwem

Omówienie kolejek

  • Artykuł

W tej sekcji przedstawiono ogólne i podstawowe pojęcia dotyczące komunikacji w kolejce. Kolejne sekcje zawierają szczegółowe informacje na temat sposobu, w jaki pojęcia dotyczące kolejkowania opisane tutaj są manifestowane w programie Windows Communication Foundation (WCF).

Podstawowe pojęcia dotyczące kolejkowania

Podczas projektowania aplikacji rozproszonej wybór odpowiedniego transportu do komunikacji między usługami i klientami jest ważny. Kilka czynników wpływa na rodzaj transportu do użycia. Jeden ważny czynnik — izolacja między usługą, klientem i transportem — określa użycie transportu w kolejce lub bezpośredniego transportu, takiego jak TCP lub HTTP. Ze względu na charakter bezpośrednich transportów, takich jak TCP i HTTP, komunikacja zostanie całkowicie zatrzymana, jeśli usługa lub klient przestaną działać lub jeśli sieć ulegnie awarii. Usługa, klient i sieć muszą być uruchomione w tym samym czasie, aby aplikacja działała. Transporty w kolejce zapewniają izolację, co oznacza, że w przypadku awarii usługi lub klienta lub połączenia komunikacyjne między nimi kończą się niepowodzeniem, klient i usługa mogą nadal działać.

Kolejki zapewniają niezawodną komunikację nawet z awariami w komunikujących się stronom lub sieci. Kolejki przechwytują i dostarczają komunikaty wymieniane między komunikującymi się stronami. Kolejki są zwykle wspierane przez jakiś rodzaj magazynu, który może być niestabilny lub trwały. Kolejki przechowują komunikaty od klienta w imieniu usługi, a następnie przekazują te komunikaty do usługi. Kolejki pośrednie zapewniają izolację awarii przez jedną ze stron, co czyni go preferowanym mechanizmem komunikacji dla systemów wysokiej dostępności i odłączonych usług. Pośrednicość wiąże się z kosztem dużego opóźnienia. Opóźnienie to opóźnienie czasu między czasem, przez który klient wysyła komunikat, a czasem odebrania go przez usługę. Oznacza to, że po wysłaniu komunikatu nie wiadomo, kiedy ten komunikat może zostać przetworzony. Większość aplikacji w kolejce radzi sobie z dużym opóźnieniem. Na poniższej ilustracji przedstawiono koncepcyjny model komunikacji w kolejce.

Model of queued communication

Model koncepcyjny komunikacji w kolejce

W rzeczywistości kolejka jest koncepcją rozproszoną. W związku z tym mogą być lokalne dla strony lub zdalne dla obu stron. Zazwyczaj kolejka jest lokalna dla usługi. W tej konfiguracji klient nie może zależeć od łączności z kolejką zdalną, aby był stale dostępny. Podobnie kolejka musi być dostępna niezależnie od dostępności odczytu usługi z kolejki. Menedżer kolejek zarządza kolekcją kolejek. Odpowiada za akceptowanie komunikatów wysyłanych do kolejek z innych menedżerów kolejek. Odpowiada również za zarządzanie łącznością z kolejkami zdalnymi i przesyłanie komunikatów do tych zdalnych kolejek. Aby zapewnić dostępność kolejek pomimo niepowodzeń aplikacji klienta lub usługi, menedżer kolejek jest zwykle uruchamiany jako usługa zewnętrzna.

Gdy klient wysyła komunikat do kolejki, adresuje komunikat do kolejki docelowej, która jest kolejką zarządzaną przez menedżera kolejek usługi. Menedżer kolejek na kliencie wysyła komunikat do kolejki transmisji (lub wychodzącej). Kolejka transmisji to kolejka w menedżerze kolejek klienta, która przechowuje komunikaty do transmisji do kolejki docelowej. Menedżer kolejek następnie znajduje ścieżkę do menedżera kolejki, który jest właścicielem kolejki docelowej i przesyła do niego komunikat. Aby zapewnić niezawodną komunikację, menedżerowie kolejek implementują niezawodny protokół transferu, aby zapobiec utracie danych. Docelowy menedżer kolejek akceptuje komunikaty adresowane do kolejek docelowych, których jest właścicielem i przechowuje komunikaty. Usługa wysyła żądania odczytu z kolejki docelowej, w którym czasie menedżer kolejek dostarcza komunikat do aplikacji docelowej. Poniższa ilustracja przedstawia komunikację między czterema stronami.

Queued Application Diagram

Komunikacja w kolejce w typowym scenariuszu wdrażania

W związku z tym menedżer kolejek zapewnia wymaganą izolację, aby nadawca i odbiorca mógł niezależnie zakończyć się niepowodzeniem bez wpływu na rzeczywistą komunikację. Zaletą dodatkowej pośredniości zapewnianej przez kolejki jest również umożliwienie odczytu wielu wystąpień aplikacji z tej samej kolejki, dzięki czemu praca w rolnictwie między węzłami zapewnia większą przepływność. W związku z tym nie rzadko zdarza się, że kolejki są używane do osiągnięcia wymagań dotyczących wyższej skali i przepływności.

Kolejki i transakcje

Transakcje umożliwiają grupowanie zestawu operacji, dzięki czemu w przypadku niepowodzenia jednej operacji wszystkie operacje kończą się niepowodzeniem. Przykładem sposobu korzystania z transakcji jest to, że osoba korzysta z bankomatu do przeniesienia 1000 USD ze swojego konta oszczędnościowego do konta ewidencjonowania. Obejmuje to następujące operacje:

  • Wypłata 1000 USD z konta oszczędnościowego.

  • Wpłacenie 1000 USD na konto kontrolne.

Jeśli pierwsza operacja powiedzie się, a 1000 USD zostanie wycofane z konta oszczędnościowego, ale druga operacja zakończy się niepowodzeniem, 1000 USD zostanie utracony, ponieważ został już wycofany z konta oszczędnościowego. Aby zachować konta w prawidłowym stanie, jeśli jedna operacja zakończy się niepowodzeniem, obie operacje muszą zakończyć się niepowodzeniem.

W przypadku obsługi komunikatów transakcyjnych komunikaty mogą być wysyłane do kolejki i odbierane z kolejki w ramach transakcji. W związku z tym, jeśli komunikat jest wysyłany w transakcji i transakcja zostanie wycofana, wynik jest taki, jakby komunikat nigdy nie został wysłany do kolejki. Podobnie jeśli komunikat zostanie odebrany w transakcji i transakcja zostanie wycofana, wynik jest taki, jakby komunikat nigdy nie został odebrany. Komunikat pozostaje w kolejce do odczytania.

Ze względu na duże opóźnienie podczas wysyłania komunikatu nie wiesz, jak długo trwa dotarcie do kolejki docelowej, ani nie wiesz, jak długo trwa przetwarzanie komunikatu przez usługę. W związku z tym nie chcesz używać pojedynczej transakcji do wysyłania komunikatu, odbierania komunikatu, a następnie przetwarzania komunikatu. Spowoduje to utworzenie transakcji, która nie jest zatwierdzona przez nieokreślony czas. Gdy klient i usługa komunikują się za pośrednictwem kolejki przy użyciu transakcji, są zaangażowane dwie transakcje: jedna na kliencie i jedna w usłudze. Poniższa ilustracja przedstawia granice transakcji w typowej komunikacji w kolejce.

Queue with transactions

Komunikacja w kolejce przedstawiająca oddzielne transakcje na potrzeby przechwytywania i dostarczania

Transakcja klienta przetwarza i wysyła komunikat. Po zatwierdzeniu transakcji komunikat znajduje się w kolejce transmisji. W usłudze transakcja odczytuje komunikat z kolejki docelowej, przetwarza komunikat, a następnie zatwierdza transakcję. Jeśli podczas przetwarzania wystąpi błąd, komunikat zostanie wycofany i umieszczony w kolejce docelowej.

Asynchroniczna komunikacja przy użyciu kolejek

Kolejki zapewniają asynchroniczne środki komunikacji. Aplikacje, które wysyłają komunikaty przy użyciu kolejek, nie mogą czekać na odebranie i przetworzenie komunikatu przez odbiorcę z powodu dużego opóźnienia wprowadzonego przez menedżera kolejek. Komunikaty mogą pozostawać w kolejce przez dłuższy czas niż aplikacja. Aby tego uniknąć, aplikacja może określić wartość Czas wygaśnięcia w komunikacie. Ta wartość określa, jak długo komunikat powinien pozostać w kolejce transmisji. Jeśli ta wartość czasu zostanie przekroczona, a komunikat nadal nie został wysłany do kolejki docelowej, komunikat można przenieść do kolejki utraconych komunikatów.

Gdy nadawca wyśle komunikat, powrót z operacji wysyłania oznacza, że komunikat został wysłany tylko do kolejki transmisji w nadawcy. W związku z tym, jeśli wystąpił błąd podczas pobierania komunikatu do kolejki docelowej, aplikacja wysyłająca nie może natychmiast o tym wiedzieć. Aby zanotować takie błędy, komunikat, który zakończył się niepowodzeniem, jest przenoszony do kolejki utraconych komunikatów.

Wszelkie błędy, takie jak komunikat nieosiągujący się do kolejki docelowej lub wygasający czas wygaśnięcia, muszą być przetwarzane oddzielnie. W związku z tym nie jest rzadkością, ponieważ aplikacje w kolejce zapisują dwa zestawy logiki:

  • Normalna logika klienta i usługi wysyłania i odbierania komunikatów.

  • Logika kompensacji do obsługi komunikatów z nieudanej transmisji lub dostarczania.

W poniższych sekcjach omówiono te pojęcia.

Programowanie kolejek utraconych listów

Kolejki utraconych komunikatów zawierają komunikaty, które nie dotarły do kolejki docelowej z różnych powodów. Przyczyny mogą wahać się od wygasłych komunikatów do problemów z łącznością uniemożliwiających transfer komunikatu do kolejki docelowej.

Zazwyczaj aplikacja może odczytywać komunikaty z kolejki utraconych komunikatów na całym systemie, określać, co poszło nie tak, i podejmować odpowiednie działania, takie jak poprawianie błędów i ponowne wysyłanie komunikatu lub zanotowanie go.

Programowanie kolejki komunikatów otrutych

Po przesłaniu komunikatu do kolejki docelowej usługa może wielokrotnie nie przetworzyć komunikatu. Na przykład aplikacja odczytując komunikat z kolejki w ramach transakcji i aktualizując bazę danych może tymczasowo odłączyć bazę danych. W takim przypadku transakcja zostanie wycofana, zostanie utworzona nowa transakcja, a komunikat zostanie ponownie odczytany z kolejki. Druga próba może zakończyć się powodzeniem lub niepowodzeniem. W niektórych przypadkach, w zależności od przyczyny błędu, komunikat może wielokrotnie nie dostarczać do aplikacji. W tym przypadku wiadomość jest uważana za "truciznę". Takie komunikaty są przenoszone do kolejki trucizny, którą można odczytać za pomocą aplikacji obsługującej truciznę.

Zobacz też