Kolejka wiadomości - Message queue

W informatyce , kolejki komunikatów i skrzynki oprogramowanie inżynierii składniki zwykle stosowane do komunikacji między procesu (IPC) lub między- gwintu komunikacji w tym samym procesie. Używają kolejki do przesyłania wiadomości  - przekazywania kontroli lub treści. Systemy komunikacji grupowej zapewniają podobne funkcje.

Paradygmat kolejki komunikatów jest odpowiednikiem wzorca wydawcy / subskrybenta i zwykle stanowi część większego systemu oprogramowania pośredniego zorientowanego na komunikaty. Większość systemów przesyłania wiadomości obsługuje w swoim API zarówno modele wydawcy / subskrybenta, jak i kolejki komunikatów , np. Java Message Service (JMS).

Przekaz i własność

Kolejki komunikatów implementują asynchroniczny wzorzec komunikacji między dwoma lub więcej procesami / wątkami, dzięki czemu strona wysyłająca i odbierająca nie muszą jednocześnie współdziałać z kolejką komunikatów. Wiadomości umieszczone w kolejce są przechowywane do momentu ich pobrania przez odbiorcę. W kolejkach komunikatów obowiązują niejawne lub jawne ograniczenia dotyczące rozmiaru danych, które mogą być przesyłane w pojedynczym komunikacie, oraz liczby komunikatów, które mogą pozostać zaległe w kolejce.

Przekazać

Wiele implementacji kolejek komunikatów działa wewnętrznie w systemie operacyjnym lub w aplikacji . Takie kolejki istnieją tylko na potrzeby tego systemu .

Inne implementacje umożliwiają przekazywanie wiadomości między różnymi systemami komputerowymi, potencjalnie łącząc wiele aplikacji i wiele systemów operacyjnych. Te systemy kolejkowania wiadomości zwykle zapewniają funkcję odporności, aby zapewnić, że wiadomości nie zostaną „zgubione” w przypadku awarii systemu. Przykłady komercyjnych implementacji tego rodzaju oprogramowania do kolejkowania komunikatów (znanego również jako oprogramowanie pośredniczące zorientowane na komunikaty ) obejmują IBM MQ (dawniej MQ Series) i Oracle Advanced Queuing (AQ). Istnieje standard Java o nazwie Java Message Service , który zawiera kilka prawnie zastrzeżonych i bezpłatnych implementacji oprogramowania .

Systemy operacyjne czasu rzeczywistego (RTOS), takie jak VxWorks i QNX, zachęcają do korzystania z kolejkowania komunikatów jako podstawowego mechanizmu komunikacji między procesami lub wątkami. Może to skutkować integracją między przekazywaniem wiadomości a harmonogramem procesora. Wczesne przykłady komercyjnych systemów RTOS, które zachęcały do ​​tworzenia kolejki komunikatów do komunikacji między wątkami, obejmują również VRTX i pSOS +, oba datowane na wczesne lata 80. Język programowania Erlang wykorzystuje procesy do zapewnienia współbieżności; procesy te komunikują się asynchronicznie za pomocą kolejkowania komunikatów.

Własność

Oprogramowanie kolejki wiadomości może być zastrzeżone, open source lub mieszać oba. Następnie jest uruchamiany lokalnie na serwerach prywatnych lub na zewnętrznych serwerach w chmurze ( usługa kolejkowania wiadomości ).

Przykładami dostawców oprogramowania pośredniego do obsługi wiadomości opartych na sprzęcie są Solace , Apigee i IBM MQ .

Stosowanie

W typowej implementacji kolejkowania komunikatów administrator systemu instaluje i konfiguruje oprogramowanie do kolejkowania komunikatów ( menedżer kolejek lub broker) oraz definiuje nazwaną kolejkę komunikatów. Lub rejestrują się w usłudze kolejkowania wiadomości .

Następnie aplikacja rejestruje procedurę programową, która „nasłuchuje” komunikatów umieszczanych w kolejce.

Druga i kolejne aplikacje mogą łączyć się z kolejką i przesyłać do niej wiadomość.

Oprogramowanie menedżera kolejek przechowuje komunikaty do momentu połączenia się aplikacji odbierającej, a następnie wywołuje zarejestrowaną procedurę oprogramowania. Następnie aplikacja odbierająca przetwarza wiadomość w odpowiedni sposób.

Często istnieje wiele opcji co do dokładnej semantyki przekazywania wiadomości, w tym:

  • Trwałość - wiadomości mogą być przechowywane w pamięci, zapisywane na dysku lub nawet przekazywane do systemu DBMS, jeśli potrzeba niezawodności wskazuje na rozwiązanie wymagające większej ilości zasobów.
  • Polityki bezpieczeństwa - które aplikacje powinny mieć dostęp do tych wiadomości?
  • Zasady usuwania wiadomości - kolejki lub wiadomości mogą mieć „ czas życia
  • Filtrowanie wiadomości - niektóre systemy obsługują filtrowanie danych tak, aby subskrybent mógł zobaczyć tylko wiadomości spełniające określone z góry kryteria zainteresowania
  • Zasady dostarczania - czy musimy zagwarantować, że wiadomość dotrze co najmniej raz, czy nie więcej niż jeden raz?
  • Zasady routingu - w systemie z wieloma serwerami kolejek, które serwery powinny otrzymać wiadomość lub wiadomości z kolejki?
  • Zasady dotyczące grupowania - czy wiadomości powinny być dostarczane natychmiast? A może system powinien trochę poczekać i spróbować dostarczyć wiele wiadomości naraz?
  • Kryteria kolejkowania - kiedy wiadomość należy uznać za „kolejkowaną”? Kiedy ma to jedna kolejka? Lub gdy został przekazany do co najmniej jednej zdalnej kolejki? Albo do wszystkich kolejek?
  • Powiadomienie o otrzymaniu - wydawca może potrzebować wiedzieć, kiedy niektórzy lub wszyscy subskrybenci otrzymali wiadomość.

Są to wszystkie kwestie, które mogą mieć znaczący wpływ na semantykę transakcji, niezawodność systemu i wydajność systemu.

Normy i protokoły

Historycznie rzecz biorąc, kolejkowanie wiadomości wykorzystywało zastrzeżone, zamknięte protokoły, ograniczając możliwość interakcji różnych systemów operacyjnych lub języków programowania w heterogenicznym zestawie środowisk.

Wczesna próba dokonania kolejkowania wiadomości bardziej wszechobecny był Sun Microsystems ' JMS specyfikacja, która dostarcza Java -tylko abstrakcję klienta API . Pozwoliło to programistom Java na przełączanie się między dostawcami kolejkowania komunikatów w sposób podobny do tego, który jest stosowany przez programistów korzystających z baz danych SQL . W praktyce, biorąc pod uwagę różnorodność technik i scenariuszy kolejkowania wiadomości, nie zawsze było to tak praktyczne, jak mogłoby być.

Pojawiły się trzy standardy, które są używane w implementacjach kolejki komunikatów typu open source:

  1. Advanced Message Queuing Protocol (AMQP) - bogaty w funkcje protokół kolejki komunikatów, zatwierdzony jako ISO / IEC 19464 od kwietnia 2014 r.
  2. Streaming Text Oriented Messaging Protocol (STOMP) - prosty, zorientowany tekstowo protokół wiadomości
  3. MQTT (dawniej MQ Telemetry Transport) - lekki protokół kolejki komunikatów, szczególnie dla urządzeń wbudowanych

Protokoły te znajdują się na różnych etapach standaryzacji i przyjęcia. Pierwsze dwa działają na tym samym poziomie co HTTP , MQTT na poziomie TCP / IP .

Niektóre własności implementacje również użyć HTTP, aby zapewnić kolejkowania wiadomości przez niektórych implementacjach, takich jak Amazon „s SQS . Dzieje się tak, ponieważ zawsze możliwe jest warstwowe zachowanie asynchroniczne (co jest wymagane w przypadku kolejkowania komunikatów) w protokole synchronicznym przy użyciu semantyki żądanie-odpowiedź. Jednak takie implementacje są w tym przypadku ograniczone przez protokół bazowy i mogą nie być w stanie zaoferować pełnej wierności lub zestawu opcji wymaganych przy przekazywaniu komunikatów powyżej.

Synchroniczne vs. asynchroniczne

Wiele powszechnie znanych używanych protokołów komunikacyjnych działa synchronicznie . Protokół HTTP - używany w sieci WWW i usługach sieciowych  - stanowi oczywisty przykład, w którym użytkownik wysyła żądanie dotyczące strony internetowej, a następnie czeka na odpowiedź.

Istnieją jednak scenariusze, w których zachowanie synchroniczne nie jest odpowiednie. Na przykład AJAX ( Asynchroniczny JavaScript i XML ) może być używany do asynchronicznego wysyłania wiadomości tekstowych, JSON lub XML w celu zaktualizowania części strony internetowej o bardziej istotne informacje. Google korzysta z tego podejścia w Google Suggest, funkcji wyszukiwania, która wysyła częściowo wpisane zapytania użytkownika na serwery Google i zwraca listę możliwych pełnych zapytań, którymi użytkownik mógłby być zainteresowany w procesie wpisywania. Ta lista jest asynchronicznie aktualizowana wraz z typami użytkowników.

Inne przykłady asynchroniczne istnieją w systemach powiadamiania o zdarzeniach i systemach publikacji / subskrypcji .

  • Aplikacja może potrzebować powiadomienia innej osoby o wystąpieniu zdarzenia, ale nie musi czekać na odpowiedź.
  • W systemach publikowania / subskrypcji aplikacja „publikuje” informacje do odczytania dla dowolnej liczby klientów.

W obu powyższych przykładach nie miałoby sensu, aby nadawca informacji musiał czekać, gdyby na przykład jeden z odbiorców się zawiesił.

Aplikacje nie muszą być wyłącznie synchroniczne ani asynchroniczne. Interaktywna aplikacja może wymagać natychmiastowej odpowiedzi na pewne części żądania (np. Poinformowanie klienta, że ​​żądanie sprzedaży zostało przyjęte i obsługa obietnicy wykorzystania zapasów), ale może kolejkować inne części (np. , przekazywanie danych do centralnego systemu księgowego i wzywanie wszelkiego rodzaju innych usług), co ma nastąpić później.

We wszystkich tego rodzaju sytuacjach posiadanie podsystemu, który wykonuje kolejkowanie wiadomości (lub alternatywnie, system rozgłaszania wiadomości) może pomóc poprawić zachowanie całego systemu.

Implementacja w systemie UNIX

W systemie UNIX istnieją dwie typowe implementacje kolejek komunikatów . Jedna jest częścią SYS V API, druga jest częścią POSIX .

SYS V

UNIX SYS V implementuje przekazywanie komunikatów, utrzymując tablicę połączonych list jako kolejki komunikatów. Każda kolejka komunikatów jest identyfikowana przez swój indeks w tablicy i ma unikalny deskryptor. Dany indeks może mieć wiele możliwych deskryptorów. UNIX udostępnia standardowe funkcje dostępu do funkcji przekazywania wiadomości.

msgget()
To wywołanie systemowe przyjmuje klucz jako argument i zwraca deskryptor kolejki z pasującym kluczem, jeśli taki istnieje. Jeśli nie istnieje, a IPC_CREAT flaga jest ustawiona, tworzy nową kolejkę komunikatów z podanym kluczem i zwraca jego deskryptor.
msgrcv()
Służy do odbierania wiadomości z danego deskryptora kolejki. Proces wywołujący musi mieć uprawnienia do odczytu kolejki. Jest dwojakiego rodzaju.
  • Zablokowanie odbioru usypia dziecko, jeśli nie może znaleźć żądanego typu wiadomości. Śpi do momentu umieszczenia kolejnej wiadomości w kolejce, a następnie budzi się, aby sprawdzić ponownie.
  • Odbieranie bez blokowania wraca natychmiast do dzwoniącego, wspominając, że się nie udało.
msgctl()
Służy do zmiany parametrów kolejki komunikatów, np. Właściciela. Co najważniejsze, służy do usuwania kolejki komunikatów poprzez przekazanie IPC_RMID flagi. Kolejkę wiadomości może usunąć tylko jej twórca, właściciel lub superużytkownik.

POSIX

Interfejs API kolejki komunikatów POSIX.1-2001 jest późniejszym z dwóch interfejsów API kolejki komunikatów systemu UNIX. Różni się od API SYS V, ale zapewnia podobną funkcję. Strona podręcznika uniksowego zawiera mq_overview(7) przegląd kolejek komunikatów POSIX.

Graficzne interfejsy użytkownika

Graficzne interfejsy użytkownika (GUI) wykorzystują kolejkę komunikatów, zwaną także kolejką zdarzeń lub kolejką wejściową , do przekazywania graficznych działań wejściowych , takich jak kliknięcia myszą , zdarzenia klawiatury lub inne dane wejściowe użytkownika, do aplikacji . System okienkowy umieszcza w kolejce komunikatów komunikaty wskazujące użytkownika lub inne zdarzenia, takie jak takty czasomierza lub komunikaty wysyłane przez inne wątki. Aplikacja GUI usuwa te zdarzenia pojedynczo, wywołując procedurę wywoływaną getNextEvent() lub podobną w pętli zdarzeń , a następnie wywołując odpowiednią procedurę aplikacji w celu przetworzenia tego zdarzenia.

Zobacz też

Bibliografia