Fronta zpráv - Message queue

„Mailbox (computing)“ přeadresuje tady. Formát souboru viz Mbox .

Ve výpočetní techniky , fronty zpráv a schránky jsou softwarové inženýrství složky obvykle používané pro komunikaci mezi procesy (IPC), nebo na inter- závitu komunikaci v rámci stejného procesu. Používají frontu pro zasílání zpráv  - předávání kontroly nebo obsahu. Skupinové komunikační systémy poskytují podobné druhy funkcí.

Paradigma fronty zpráv je sourozenec vzoru vydavatel / předplatitel a je obvykle jednou částí většího systému middlewaru orientovaného na zprávy . Většina systémů pro zasílání zpráv podporuje ve svém API jak modely vydavatele / předplatitele, tak fronty zpráv , např. Java Message Service (JMS).

Poslání a vlastnictví

Fronty zpráv implementují asynchronní komunikační vzor mezi dvěma nebo více procesy / vlákny, přičemž odesílající a přijímající strana nemusí komunikovat s frontou zpráv současně. Zprávy umístěné do fronty se ukládají, dokud je příjemce nenačte. Fronty zpráv mají implicitní nebo explicitní omezení velikosti dat, která mohou být přenášena v jedné zprávě, a počtu zpráv, které mohou ve frontě zůstat nevyřízené.

Prominout

Mnoho implementací front zpráv funguje interně v operačním systému nebo v aplikaci . Takové fronty existují pouze pro účely tohoto systému .

Další implementace umožňují předávání zpráv mezi různými počítačovými systémy, což potenciálně spojuje více aplikací a více operačních systémů. Tyto systémy zařazování zpráv obvykle poskytují funkce odolnosti, aby zajistily, že se zprávy v případě selhání systému neztratí. Mezi příklady komerčních implementací tohoto druhu softwaru pro řazení zpráv (označovaného také jako middleware orientovaný na zprávy ) patří IBM MQ (dříve MQ Series) a Oracle Advanced Queuing (AQ). Existuje standard Java nazvaný Java Message Service , který má několik proprietárních a bezplatných softwarových implementací.

Operační systémy v reálném čase (RTOS), jako jsou VxWorks a QNX, podporují použití front zpráv jako primární meziprocesový nebo mezivláknový komunikační mechanismus. To může mít za následek integraci mezi předáváním zpráv a plánováním CPU. Mezi rané příklady komerčních RTOS, které podporovaly komunikaci mezi vlákny na základě fronty zpráv, patří také VRTX a pSOS +, které se datují počátkem 80. let. Programovací jazyk Erlang využívá postupy k zajištění souběžnosti; tyto procesy komunikují asynchronně pomocí front zpráv.

Vlastnictví

Software pro frontu zpráv může být buď proprietární, open source nebo kombinace obou. Poté je spuštěn buď na místě na soukromých serverech, nebo na externích cloudových serverech ( služba řazení zpráv ).

Příklady dodavatelů middlewaru pro zasílání zpráv na základě hardwaru jsou Solace , Apigee a IBM MQ .

Používání

V typické implementaci zařazování zpráv do fronty správce systému nainstaluje a konfiguruje software pro zařazování zpráv do fronty ( správce front nebo zprostředkovatele) a definuje pojmenovanou frontu zpráv. Nebo se zaregistrují u služby zařazování zpráv do fronty .

Aplikace poté zaregistruje softwarovou rutinu, která „naslouchá“ zprávám zařazeným do fronty.

Druhá a následující aplikace se mohou připojit k frontě a přenést do ní zprávu.

Software pro správu front ukládá zprávy, dokud se nepřipojí přijímající aplikace, a poté nevyvolá zaregistrovanou softwarovou rutinu. Přijímající aplikace poté zprávu vhodným způsobem zpracuje.

Často existuje mnoho možností, pokud jde o přesnou sémantiku předávání zpráv, včetně:

  • Trvanlivost - zprávy mohou být uchovávány v paměti, zapisovány na disk nebo dokonce potvrzeny do systému DBMS, pokud potřeba spolehlivosti naznačuje řešení náročnější na zdroje.
  • Zásady zabezpečení - které aplikace by měly mít přístup k těmto zprávám?
  • Zásady čištění zpráv - fronty nebo zprávy mohou mít „ čas žít “
  • Filtrování zpráv - některé systémy podporují filtrování dat, takže předplatitel může vidět pouze zprávy odpovídající některým předem stanoveným kritériím zájmu
  • Zásady doručování - musíme zaručit, že zpráva bude doručena alespoň jednou, nebo ne více než jednou?
  • Zásady směrování - Které servery by v systému s mnoha servery ve frontě měly obdržet zprávu nebo zprávy ve frontě?
  • Zásady dávkování - měly by být zprávy doručovány okamžitě? Nebo by měl systém trochu počkat a pokusit se doručit mnoho zpráv najednou?
  • Kritéria pro zařazení do fronty - kdy by měla být zpráva považována za „zařazenou do fronty“? Když to má jedna fronta? Nebo když byla přeposlána alespoň do jedné vzdálené fronty? Nebo do všech front?
  • Oznámení o přijetí - Vydavatel možná bude muset vědět, kdy někteří nebo všichni předplatitelé obdrželi zprávu.

To vše jsou úvahy, které mohou mít podstatný vliv na sémantiku transakcí, spolehlivost systému a účinnost systému.

Standardy a protokoly

Historicky fronty zpráv používaly proprietární uzavřené protokoly, které omezovaly schopnost různých operačních systémů nebo programovacích jazyků interagovat v heterogenní sadě prostředí.

Časný pokus, aby Message Queuing více všudypřítomné byl Sun Microsystems " JMS specifikace, který poskytl Java -jen abstrakci klienta API . To umožnilo vývojářům Java přepínat mezi poskytovateli front zpráv podobným způsobem jako vývojáři používající databáze SQL . V praxi to vzhledem k rozmanitosti technik a scénářů řazení front nebylo vždy tak praktické, jak by to mohlo být.

Objevily se tři standardy, které se používají v implementacích front zpráv s otevřeným zdrojovým kódem:

  1. Advanced Message Queuing Protocol (AMQP) - protokol front zpráv bohatý na funkce, schválený jako ISO / IEC 19464 od dubna 2014
  2. Streaming Text Oriented Messaging Protocol (STOMP) - jednoduchý textově orientovaný protokol zpráv
  3. MQTT (formerly MQ Telemetry Transport) - lehký protokol fronty zpráv, zejména pro vestavěná zařízení

Tyto protokoly jsou v různých fázích standardizace a přijetí. První dva fungují na stejné úrovni jako HTTP , MQTT na úrovni TCP / IP .

Některé proprietární implementace také použít HTTP poskytnout Message Queuing podle některých implementacích, jako Amazon ‚s SQS . Je to proto, že je vždy možné vrstvit asynchronní chování (což je to, co je vyžadováno pro řazení zpráv) přes synchronní protokol pomocí sémantiky požadavku a odpovědi. Takové implementace jsou však v tomto případě omezeny základním protokolem a nemusí být schopné nabídnout úplnou věrnost nebo sadu možností požadovaných při předávání zpráv výše.

Synchronní vs. asynchronní

Mnoho běžně používaných komunikačních protokolů pracuje synchronně . Protokol HTTP - používaný v síti WWW a ve webových službách  - nabízí zřejmý příklad, kdy uživatel odešle požadavek na webovou stránku a poté čeká na odpověď.

Existují však scénáře, ve kterých není synchronní chování vhodné. Například AJAX ( Asynchronous JavaScript and XML ) can be used to asynchronously send text, JSON or XML messages to update part of a web page with more relevant information. Google používá tento přístup pro svou funkci Google Suggest, což je vyhledávací funkce, která odesílá částečně zadané dotazy uživatele na servery Google a vrací seznam možných úplných dotazů, které by uživatele při psaní mohly zajímat. Tento seznam je asynchronně aktualizován jako typy uživatelů.

Další asynchronní příklady existují v systémech upozornění na události a v systémech pro publikování / odběr .

  • Aplikace možná bude muset upozornit jiného, ​​že došlo k události, ale nemusí čekat na odpověď.
  • V systémech publikování / odběru aplikace „publikuje“ informace pro libovolný počet klientů ke čtení.

V obou výše uvedených příkladech by nemělo smysl, aby odesílatel informací musel čekat, pokud například narazil jeden z příjemců.

Aplikace nemusí být výlučně synchronní nebo asynchronní. Možná bude nutné, aby interaktivní aplikace okamžitě reagovala na určité části požadavku (například řekla zákazníkovi, že požadavek na prodej byl přijat a vyřídila příslib čerpání z inventáře), ale může zařadit do fronty další části (například dokončit výpočet fakturace) , předávání údajů do centrálního účetního systému a volání nejrůznějších dalších služeb), které je třeba provést o něco později.

Ve všech těchto druzích situací může mít subsystém, který provádí řazení zpráv (nebo alternativně systém hromadného zasílání zpráv), pomoci zlepšit chování celého systému.

Implementace v systému UNIX

V systému UNIX existují dvě běžné implementace fronty zpráv . Jeden je součástí API SYS V, druhý je součástí POSIX .

SYS V

UNIX SYS V implementuje předávání zpráv tím, že udržuje řadu propojených seznamů jako fronty zpráv. Každá fronta zpráv je identifikována indexem v poli a má jedinečný deskriptor. Daný index může mít několik možných deskriptorů. UNIX poskytuje standardní funkce pro přístup k funkci předávání zpráv.

msgget()
Toto systémové volání bere klíč jako argument a vrací deskriptor fronty s odpovídajícím klíčem, pokud existuje. Pokud neexistuje a IPC_CREAT příznak je nastaven, vytvoří novou frontu zpráv s daným klíčem a vrátí jeho deskriptor.
msgrcv()
Slouží k přijetí zprávy od daného deskriptoru fronty. Proces volajícího musí mít oprávnění ke čtení pro frontu. Je dvou typů.
  • Blokování příjmu uvede dítě do režimu spánku, pokud nemůže najít požadovaný typ zprávy. Spí, dokud není ve frontě zaúčtována další zpráva, a poté se probudí a znovu zkontroluje.
  • Neblokující příjem se okamžitě vrátí volajícímu s uvedením, že se nezdařilo.
msgctl()
Slouží ke změně parametrů fronty zpráv, jako je vlastník. Nejdůležitější je, že se používá k odstranění fronty zpráv předáním IPC_RMID vlajky. Frontu zpráv může smazat pouze její tvůrce, vlastník nebo superuživatel.

POSIX

API fronty zpráv POSIX.1-2001 je pozdější ze dvou rozhraní API fronty zpráv UNIX. Liší se od API SYS V, ale poskytuje podobnou funkci. Manuální stránka unixu mq_overview(7) poskytuje přehled front zpráv POSIX.

Grafická uživatelská rozhraní

Grafická uživatelská rozhraní (GUI) využívají frontu zpráv, která se také nazývá fronta událostí nebo vstupní fronta , k předávání grafických vstupních akcí , jako jsou kliknutí myší , události klávesnice nebo jiné uživatelské vstupy, do aplikačního programu . Okenní systém umisťuje do fronty zpráv zprávy označující uživatele nebo jiné události, jako jsou časovače nebo zprávy odeslané jinými vlákny. Aplikace GUI odebírá tyto události jeden po druhém voláním rutiny nazývané getNextEvent() nebo podobné ve smyčce událostí a následným voláním příslušné rutiny aplikace ke zpracování této události.

Viz také

Reference