1 / 14

Systemy rozproszone

Uniwersytet Łódzki Katedra Informatyki. W. Bartkiewicz. Systemy rozproszone. Wykład 7. Kolejki komunikatów. Katedra Informatyki. Przesyłanie komunikatów Trwała komunikacja asynchroniczna.

carly-walls
Télécharger la présentation

Systemy rozproszone

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Uniwersytet Łódzki Katedra Informatyki W. Bartkiewicz Systemy rozproszone Wykład 7. Kolejki komunikatów

  2. Katedra Informatyki Przesyłanie komunikatówTrwała komunikacja asynchroniczna • Obecnie skupimy się na środowiskach warstwy pośredniej wspomagających trwałą komunikację asynchroniczną opartą na komunikatach. • W komunikacji asynchronicznej nadawca bezpośrednio po przedłożeniu komunikatu do wysłania, kontynuuje pracę. Oznacza to, że komunikat zostaje zapamiętany w lokalnym buforze komputera nadawczego, albo w pierwszym serwerze komunikacyjnym. • W komunikacji synchronicznej nadawca jest blokowany do czasu przechowania komunikatu w lokalnym buforze komputera odbiorczego lub do chwili rzeczywistego doręczenia do odbiorcy. Najsilniejsza postać komunikacji synchronicznej polega na blokowaniu nadawcy do czasu przetworzenia komunikatu przez odbiorcę.

  3. Katedra Informatyki Przesyłanie komunikatówTrwała komunikacja asynchroniczna • Przypomnijmy, że w komunikacji przejściowej (transient) komunikat przechowywany jest w systemie komunikacji tylko na czas działania aplikacji nadawczej i odbiorczej. • Ściślej mówiąc, jeśli serwer komunikacyjny nie może dostarczyć komunikatu serwera do następnego serwera lub do odbiorcy, to komunikat jest odrzucany. Wszystkie usługi z poziomu transportu z reguły reprezentują tylko komunikację przejściową. • W komunikacji trwałej (persistent) z kolei, komunikat przedłożony do przesłania odbiorcy jest pamiętany przez system tak długo, jak trzeba aby dostarczyć go odbiorcy. Aplikacja nadawcza nie musi kontynuować działania po przedłożeniu komunikatu. Aplikacja odbiorcza również nie musi działać w czasie przedłożenia komunikatu.

  4. Katedra Informatyki Systemy kolejkowania komunikatówTrwała komunikacja asynchroniczna • Środowiska warstwy pośredniej, dostarczające rozwiniętych środków trwałej komunikacji asynchronicznej nazywamy systemami kolejkowania komunikatów (message queuing systems) lub komunikatową warstwą pośrednią (Message Oriented Middleware – MOM). • Istota tych systemów polega na zastosowaniu zasobów pamięciowych do przechowywania komunikatów w fazie pośredniej, bez wymagania aktywności nadawcy i odbiorcy podczas transmisji. • Aplikacje wstawiają komunikaty do specjalnych kolejek, przy czym w zasadzie kolejki skojarzone są z aplikacjami odbiorczymi. • Aplikacje nadawcze zazwyczaj wysyłają więc komunikaty do prywatnej kolejki aplikacji odbiorczej, możliwe jest jednak współdzielenie jednej kolejki przez wiele aplikacji. • Komunikat musi być odpowiednio zaadresowany. W praktyce adresowanie wykonuje się za pomocą ogólnosystemowej niepowtarzalnej nazwy kolejki docelowej.

  5. Katedra Informatyki Systemy kolejkowania komunikatów Trwała komunikacja asynchroniczna • Nadawca otrzymuje na ogół tylko gwarancję, że komunikat zostanie w końcu wstawiony do kolejki odbiorcy. Nie daje się żadnych gwarancji co do chwili, kiedy to nastąpi, a nawet nie zapewnia się, że komunikat zostanie rzeczywiście przeczytany.To w całości zależy od zachowania odbiorcy. • Taka semantyka zachowania umożliwia komunikację luźno powiązaną. Nadawca i odbiorca mogą działać zupełnie niezależnie. Komunikat po zdeponowaniu w kolejce pozostaje w niej do chwili usunięcia bez względu na to, czy odbiorca jest aktywny. • Komunikaty mogą w zasadzie zawierać dowolne dane. Ich rozmiar może być czasami ograniczony. System obsługi kolejki może jednak dbać o dzielenie wielkich komunikatów na części i ich powtórne składanie w sposób zupełnie przezroczysty dla aplikacji.

  6. Katedra Informatyki Systemy kolejkowania komunikatów Trwała komunikacja asynchroniczna • Podstawowy interfejs kolejki w systemie kolejkowania komunikatów obejmuje zazwyczaj cztery operacje: • Put – dołącz komunikat do określonej kolejki. • Get – pobierz komunikat, zablokuj się jeśli kolejka jest pusta. • Pull – sprawdź czy w kolejce są komunikaty, jeśli tak to pobierz jeden z nich. Jeśli kolejka jest pusta, się nie blokuj się. • Notify – zainstaluj procedurę obsługi, która będzie wywoływana gdy w kolejce pojawi się komunikat. • Systemy kolejek komunikatów umożliwiają zazwyczaj pobieranie komunikatów według różnych kryteriów: FIFO, z zastosowaniem priorytetów, dopasowywania wzorca, itp. • Większość systemów kolejkowania umożliwia również procesowi zainstalowanie procedury obsługi na zasadzie funkcji przywołania (callback function). Jest ona uaktywniana zawsze przy dołączaniu nowego komunikatu. Przywołania można też stosować do automatycznego uruchamiania procesu, który pobierze komunikat.

  7. Katedra Informatyki Systemy kolejkowania komunikatów Ogólna architektura • Każdy nadawca wstawia komunikat do kolejki lokalnej, na swojej maszynie. Kolejkę taka nazywamy źródłową (source queue). • Komunikat zawiera jednak specyfikację kolejki docelowej (destination queue), do której powinien zostać przeniesiony. Odbiorca działa na tej samej maszynie na której zainstalowana jest kolejka docelowa. Odpowiednie przekazanie komunikatu między kolejkami realizowane jest przez system kolejkowania komunikatów. • Zbiór kolejek jest więc rozproszony w systemie na wielu maszynach. Aby system kolejkowania mógł przekazywać komunikaty, musi utrzymywać odwzorowanie kolejek na miejsca w sieci. • W praktyce oznacza to, że system kolejkowania komunikatów powinien utrzymywać (być może rozproszoną) bazę danych nazw kolejek z przypisanymi im adresami w sieci.

  8. Katedra Informatyki Systemy kolejkowania komunikatów Ogólna architektura • Kolejkami administrują zarządcy kolejek (queue managers). Na ogół zarządca kolejki ma charakter lokalny, tzn. współpracuje z aplikacją, która bezpośrednio wysyła lub odbiera komunikat. • Istnieją też specjalni zarządcy kolejek, którzy działają jako rutery, czyli przekaźniki (relays). Ich zadaniem jest kierowanie nadchodzących komunikatów do innych zarządców kolejek. • W ten sposób system kolejkowania komunikatów może stopniowo rozrastać się w kompletną sieć nakładkową (overlay network) na poziomie aplikacji powyżej istniejącej sieci komputerowej. • Rozwiązania oparte na przekaźnikach stanowią lepiej skalowalną alternatywę dla statycznych topologii rozsyłania komunikatów, opartych na utrzymywaniu przez każdego zarządcę kolejki kopii odwzorowania kolejka-miejsce. Dotyczy to zwłaszcza (dosyć powszechnej) sytuacji, gdy w systemie kolejkowania nie ma globalnych usług nazewniczych.

  9. Katedra Informatyki Aplikacja Kolejka odbiorcza Kolejka nadawcza Aplikacja Aplikacja Aplikacja Systemy kolejkowania komunikatów Wykorzystanie przekaźników Nadawca A R2 R1 Konfigurację sieci znają rutery. Nadawca wie tylko gdzie jest najbliższy ruter. Przy dodawaniu lub usuwaniu kolejek wystarczy zaktualizować tylko rutery Odbiorca B

  10. Katedra Informatyki Systemy kolejkowania komunikatów Brokerzy komunikatów • Przekaźniki mogą wykonywać również pomocnicze przetwarzanie komunikatów. Komunikaty mogą na przykład wymagać rejestrowania ze względu na bezpieczeństwo lub tolerowanie awarii. • Najważniejszym przykładem tego typu rozwiązań są tzw. brokerzy komunikatów (message brokers). • Brokerzy komunikatów są to specjalne węzły sieci kolejkującej, wykonujące konwersje komunikatów. Broker pełni funkcję bramy (gateway) na poziomie aplikacji, której podstawowym zadaniem jest przekształcanie nadchodzących komunikatów na format zrozumiały przez aplikację docelową. • Jeśli dla przykładu komunikat zawiera tabelę bazy danych, broker komunikatów może dokonywać modyfikacji fizycznej reprezentacji pól i rekordów (np. poprzez zmianę znaku delimitera rekordu, zamianę z rekordów o stałej długości na reprezentacje o zmiennej długości, itp.) tak by dostosować ją z postaci generowanej przez aplikację źródłową do formy oczekiwanej przez aplikację docelową.

  11. Katedra Informatyki Systemy kolejkowania komunikatów Brokerzy komunikatów • Brokerzy komunikatów stanowią więc ważne narzędzie, ułatwiające integrację heterogenicznych środowisk aplikacyjnych w jeden, spójny rozproszony system informacyjny. • Centralną częścią brokera komunikatów jest baza danych z regułami określającymi sposób konwersji komunikatów. • Większość wytwarzanych brokerów komunikatów zaopatrzonych jest w wyrafinowane narzędzia wprowadzania reguł konwersji. • Reguły mogą być formułowane w specjalnych językach konwersji, ale wielu obecnie stosowanych brokerów komunikatów umożliwia ich tworzenie również z wykorzystaniem zwykłych języków programowania. • Reguły konwersji zazwyczaj muszą być tworzone ręcznie. Zbudowanie brokera komunikatów jest zatem na ogół zadaniem żmudnym.

  12. Katedra Informatyki Systemy kolejkowania komunikatów IBM MQSeries • W architekturze MQSeries nadzór nad wszystkimi kolejkami sprawują zarządcy kolejek. Odpowiadają oni za usuwanie komunikatów ze swojej kolejki nadawczej i przekazywanie ich do innych zarządców komunikatów. • Zarządca kolejki odpowiada też za obsługę nadchodzących komunikatów, które pobiera z bazowej sieci, zapamiętując każdy z nich we właściwej kolejce wejściowej. • Zarządcy komunikatów połączeni są parami poprzez kanały komunikatów (message channels), reprezentujące abstrakcję poziomu transportu. • Kanał komunikatów jest jednokierunkowym, niezawodnym połączeniem między nadawczym a odbiorczym zarządcą kolejki, którym przesyła się ustawione w kolejce komunikaty. Na przykład kanał komunikatów oparty na sieci Internet zrealizowany jest jako połączenie TCP.

  13. Katedra Informatyki Systemy kolejkowania komunikatów IBM MQSeries • Każdy z dwu końców kanału zarządzany jest przez agenta kanału komunikatów (message channel agent – MCA). • Agent nadawczy sprawdza kolejki nadawcze, opakowuje komunikat w pakiet poziomu transportu i wysyła go do skojarzonego z nim odbiorczego agenta MCA. • Agent odbiorczy nasłuchuje nadchodzących pakietów, rozpakowuje je i wstawia komunikaty do odpowiedniej kolejki. • Zarządcy kolejek mogą być łączeni w jeden proces wraz z aplikacją, dla której zrządzają kolejkami. W takim przypadku aplikacje operują bezpośrednio na kolejkach przez standardowy interfejs. • Jeśli zarządca kolejki i aplikacja działają na odrębnych maszynach, aplikacja korzysta z również tego samego standardowego interfejsu, ale realizowanego przez zarządcę kolejki w formie tradycyjnych, synchronicznych wywołań RPC.

  14. Katedra Informatyki Zarządca kolejki Aplikacja Aplikacja Interfejs MQ Interfejs MQ Namiastka serwera Namiastka Namiastka MCA MCA Systemy kolejkowania komunikatów IBM MQSeries Kolejka nadawcza Kolejka odbiorcza klienta Tablica tras Klient nadawczy Klient odbiorczy Zarządca kolejki Namiastka serwera MCA MCA Intersieć Sieć lokalna Sieć lokalna RPC (synchroniczne) Do innych zarządców kolejek Przekazywanie komunikatów (asynchroniczne)

More Related