Üzenetsor - Message queue

A számítástechnika , üzenetsorok és postafiókok vannak software-engineering komponensek jellemzően használt folyamatok közötti kommunikációt (IPC), illetve inter- szál kommunikációs ugyanazon folyamaton belül. Ők egy sorban az üzenetek  - az elhaladó ellenőrzés vagy a tartalom. A csoportos kommunikációs rendszerek hasonló típusú funkciókat kínálnak.

Az üzenetsor paradigma a kiadó / előfizető mintájának testvére , és általában egy nagyobb üzenetorientált köztes szoftver rendszer része. A legtöbb üzenetkezelő rendszer támogatja a kiadó / előfizető és az üzenetsor modelleket az API-jukban , pl. Java Message Service (JMS).

Megbízás és tulajdonjog

Az üzenetsorok aszinkron kommunikációs mintát valósítanak meg két vagy több folyamat / szál között, ahol a küldő és a fogadó félnek nem kell egyszerre interakcióba lépnie az üzenetsorral. A sorba helyezett üzeneteket addig tároljuk, amíg a címzett be nem szerzi azokat. Az üzenetsorok implicit vagy explicit korlátozásokat tartalmaznak az egyetlen üzenetben továbbítható adatok méretére és a sorban esetleg fennmaradó üzenetek számára.

Mérsékel

Az üzenetsorok sok megvalósítása belsőleg működik egy operációs rendszeren vagy egy alkalmazáson belül . Ilyen sorok csak a rendszer céljaira léteznek .

Más megvalósítások lehetővé teszik az üzenetek továbbítását a különböző számítógépes rendszerek között, több alkalmazás és több operációs rendszer összekapcsolásával. Ezek az üzenetsorba állító rendszerek általában rugalmasságot biztosítanak annak biztosítására, hogy az üzenetek ne tévesszenek el rendszerhiba esetén. Az ilyen üzenetsor- szoftver (más néven üzenet-orientált köztes szoftver ) kereskedelmi megvalósításának példái közé tartozik az IBM MQ (korábban MQ Series) és az Oracle Advanced Queuing (AQ). Van egy Java Message Service nevű Java szabvány , amely számos saját és ingyenes szoftver implementációval rendelkezik.

A valós idejű operációs rendszerek (RTOS), például a VxWorks és a QNX ösztönzik az üzenetsorok használatát elsődleges folyamatközi vagy szálközi kommunikációs mechanizmusként. Ez integrációt eredményezhet az üzenetátadás és a CPU ütemezése között. A kereskedelmi RTOS-ok korai példái, amelyek az üzenetsor-alapot ösztönzik a szálak közötti kommunikációra, tartalmazzák a VRTX-et és a pSOS + -ot is, amelyek mind az 1980-as évek elejére nyúlnak vissza. Az Erlang programozási nyelv folyamatokat használ az egyidejűség biztosítására; ezek a folyamatok aszinkron módon kommunikálnak az üzenetsorba állítással.

Tulajdonjog

Az üzenetsor-szoftver lehet saját, nyílt forráskódú vagy mindkettő keveréke. Ezután futtatásra kerül, vagy magánszervereken, vagy külső felhőszervereken ( üzenetsor-szolgáltatás ).

• A szabadalmaztatott opciók a legrégebbi múltra tekintenek vissza, és az üzenetsorok kezdetétől fogva termékeket tartalmaznak, például az IBM MQ-t , valamint azokat, amelyek meghatározott operációs rendszerekhez vannak kötve, például a Microsoft Message Queuing (MSMQ) . A felhőszolgáltatók olyan szabadalmaztatott megoldásaikat is kínálják, mint az Amazon Simple Queue Service (SQS), a StormMQ , a Solace és az IBM MQ .
• Az üzenetküldő köztes rendszerek nyílt forráskódú választása az Apache ActiveMQ , az Apache Kafka , az Apache Qpid , az Apache RocketMQ , az Enduro / X , a JBoss Messaging , a JORAM , a RabbitMQ , a Sun Open Message Queue és a Tarantool .

A hardver alapú üzenetküldő köztes gyártók példái a Solace , az Apigee és az IBM MQ .

Használat

Egy tipikus üzenetsoros megvalósításban a rendszergazda telepíti és konfigurálja az üzenetsorosító szoftvert (egy sorkezelő vagy közvetítő), és meghatároz egy megnevezett üzenetsort. Vagy regisztrálnak egy üzenetsoros szolgáltatással .

Ezután egy alkalmazás regisztrálja a szoftver rutint, amely "meghallgatja" a várólistára helyezett üzeneteket.

A második és a későbbi alkalmazások csatlakozhatnak a várólistához, és üzenetet továbbíthatnak rá.

A sorkezelő szoftver addig tárolja az üzeneteket, amíg a fogadó alkalmazás csatlakozik, majd felhívja a regisztrált szoftver rutint. Ezután a fogadó alkalmazás megfelelő módon feldolgozza az üzenetet.

Az üzenet továbbításának pontos szemantikájával kapcsolatban gyakran számos lehetőség áll rendelkezésre, többek között:

• Tartósság - az üzeneteket tárolhatjuk a memóriában, lemezre írhatjuk, vagy akár egy DBMS-hez is rendelhetjük, ha a megbízhatóság iránti igény erőforrás-igényesebb megoldást jelez.
• Biztonsági házirendek - mely alkalmazások férhetnek hozzá ezekhez az üzenetekhez?
• Üzenettisztítási irányelvek - a soroknak vagy az üzeneteknek " ideje élni "
• Üzenetszűrés - egyes rendszerek támogatják az adatok szűrését, így az előfizető csak bizonyos előre meghatározott érdeklődési feltételeknek megfelelő üzeneteket láthat
• Kézbesítési irányelvek - garantálnunk kell, hogy az üzenetet legalább egyszer, vagy legfeljebb egyszer kézbesítsük?
• Útválasztási házirendek - egy sok sorkiszolgálóval rendelkező rendszerben mely szerverek kapjanak üzenetet vagy egy sor üzeneteit?
• Kötegelt kötvények - azonnal meg kell-e küldeni az üzeneteket? Vagy várjon egy kicsit a rendszernek, és megpróbáljon sok üzenetet átadni egyszerre?
• Sorban állási kritériumok - mikor kell egy üzenetet „befogadottnak” tekinteni? Amikor egy sorban van? Vagy amikor továbbították legalább egy távoli várólistára? Vagy minden sorba?
• Értesítés nyugtáról - Lehet, hogy a kiadónak tudnia kell, hogy néhány előfizető vagy az összes előfizető kapott-e üzenetet.

Ezek mind olyan szempontok, amelyek jelentős hatással lehetnek a tranzakció szemantikájára, a rendszer megbízhatóságára és a rendszer hatékonyságára.

Szabványok és protokollok

Történelmileg az üzenetsorolás saját, zárt protokollokat használt, korlátozva a különböző operációs rendszerek vagy programozási nyelvek interakcióját heterogén környezetekben.

Egy korai kísérlet, hogy az üzenet sorban több volt jelen a Sun Microsystems " JMS leírás, amely során a Java -csak absztrakció egy ügyfél API . Ez lehetővé tette a Java fejlesztők számára, hogy az SQL- adatbázisokat használó fejlesztőkhöz hasonló módon váltsanak az üzenetsorok szolgáltatói között . A gyakorlatban, tekintettel az üzenetsorolási technikák és forgatókönyvek sokféleségére, ez nem mindig volt olyan praktikus, mint lehetett.

Három szabvány jelent meg, amelyeket a nyílt forráskódú üzenetsor-megvalósításokban használnak:

1. Advanced Message Queuing Protocol (AMQP) - funkciókban gazdag üzenetsorprotokoll, 2014 áprilisától ISO / IEC 19464 szabványként jóváhagyva
2. Szövegorientált üzenetküldési protokoll (STOMP) - egyszerű, szövegorientált üzenetprotokoll
3. MQTT (korábban MQ Telemetry Transport) - könnyű üzenetsor-protokoll, különösen beágyazott eszközök számára

Ezek a protokollok a szabványosítás és az elfogadás különböző szakaszaiban vannak. Az első kettő ugyanazon a szinten működik, mint a HTTP , az MQTT a TCP / IP szintjén .

Néhány kereskedelmi alkalmazás is használja a HTTP, hogy üzenetet sorbanállási egyes implementációk, például az Amazon „s SQS . Ennek oka az, hogy az aszinkron viselkedést (ami az üzenetsoroláshoz szükséges) mindig rétegezni lehet egy szinkron protokoll felett kérelem-válasz szemantika segítségével. Az ilyen megvalósításokat azonban ebben az esetben az alapul szolgáló protokoll korlátozza, és előfordulhat, hogy nem képesek biztosítani a fenti üzenet továbbításakor szükséges teljes hűséget vagy opciókat.

Szinkron vs. aszinkron

A használatban lévő, szélesebb körben ismert kommunikációs protokollok közül sok szinkronosan működik . A világhálón és a webszolgáltatásokban használt HTTP protokoll  nyilvánvaló példát kínál arra, hogy a felhasználó kérést küld egy weboldalra, majd megvárja a választ.

Vannak azonban olyan forgatókönyvek, amelyekben a szinkron viselkedés nem megfelelő. Például az AJAX ( aszinkron JavaScript és XML ) használható aszinkron módon szöveges, JSON vagy XML üzenetek küldésére, hogy a weboldal egy részét relevánsabb információkkal frissítse. A Google ezt a megközelítést használja a Google Suggest szolgáltatáshoz, amely egy olyan keresési funkció, amely a felhasználó részben beírt lekérdezéseit elküldi a Google szervereire, és visszaküldi a lehetséges teljes lekérdezések listáját, amelyeket a felhasználó érdekelhet a gépelés folyamata iránt. Ez a lista aszinkron módon frissül a felhasználói típusok szerint.

Egyéb aszinkron példák léteznek az eseményértesítő rendszerekben és a közzétételi / előfizetői rendszerekben.

• Előfordulhat, hogy egy alkalmazásnak értesítenie kell a másikat egy esemény bekövetkezéséről, de nem kell megvárnia a választ.
• A közzétételi / feliratkozási rendszerekben egy alkalmazás bármennyi ügyfél számára "közzétesz" információkat.

A fenti két példában nem lenne értelme, ha az információ küldőjének várnia kell, ha például az egyik címzett összeomlott.

Az alkalmazásoknak nem kell kizárólag szinkronnak vagy aszinkronnak lenniük. Előfordulhat, hogy egy interaktív alkalmazásnak azonnal reagálnia kell a kérelem bizonyos részeire (például közölnie kell az ügyfelekkel, hogy eladási kérelmet elfogadtak, és kezelnie kell a készletre történő felhasználás ígéretét), de sorba állíthat más részeket (például befejezheti a számlázás számítását) , az adatok továbbítása a központi könyvelési rendszerbe, és mindenféle egyéb szolgáltatás igénybevétele), valamivel később.

Az ilyen jellegű helyzetekben az üzenetsorba állítást végző alrendszer (vagy alternatív megoldásként az üzenetszóró rendszer) segíthet az egész rendszer viselkedésének javításában.

Megvalósítás UNIX-ban

Két általános üzenetsor-megvalósítás létezik a UNIX rendszerben . Az egyik a SYS V API része, a másik a POSIX része .

SYS V

A UNIX SYS V úgy hajtja végre az üzenetátadást, hogy összekapcsolt listák tömbjét tartja üzenetsorként. Minden egyes üzenetsort a tömb indexe alapján azonosítanak, és egyedi leírójuk van. Egy adott indexnek több lehetséges leírója lehet. A UNIX szabványos funkciókat biztosít az üzenetátvitel funkció eléréséhez.

msgget()

Ez a rendszerhívás egy kulcsot vesz fel argumentumként, és visszaadja a sor leíróját a megfelelő kulccsal, ha létezik. Ha nem létezik, és a IPC_CREAT zászló be van állítva, akkor egy új üzenetsort állít fel a megadott kulccsal, és visszaadja annak leíróját.

msgrcv()

Üzenet fogadására szolgál egy adott sorleírótól. A hívó folyamatnak olvasási engedéllyel kell rendelkeznie a sor számára. Kétféle.

• A vétel letiltása elaltatja a gyermeket, ha nem találja a kért üzenet típusát. Alszik, amíg egy újabb üzenet nem kerül a sorba, majd felébred, hogy újra ellenőrizze.
• A nem blokkoló vétel azonnal visszatér a hívóhoz, megemlítve, hogy nem sikerült.

msgctl()

Az üzenetsor paramétereinek, például a tulajdonosának megváltoztatására szolgál. A legfontosabb, hogy arra használják, hogy törölje az üzenetsort a IPC_RMID zászló átadásával . Az üzenetsort csak az alkotója, a tulajdonosa vagy a főfelhasználó törölheti.

POSIX

A POSIX.1-2001 üzenetsor-API a két UNIX-üzenetsor-API közül a későbbi. Különbözik a SYS V API-tól, de hasonló funkciót biztosít. Az unix man oldal mq_overview(7) áttekintést nyújt a POSIX üzenetsorokról.

Grafikus felhasználói felületek

A grafikus felhasználói felületek (GUI-k) üzenetsort használnak, amelyet eseménysornak vagy bemeneti sornak is neveznek , hogy grafikus bemeneti műveleteket , például egérkattintásokat , billentyűzeteseményeket vagy más felhasználói bemeneteket továbbítsanak az alkalmazásprogramnak . Az ablakos rendszer felhasználói vagy más eseményeket jelző üzeneteket, például időzítő kullancsokat vagy más szálak által küldött üzeneteket helyez az üzenetsorba. A grafikus felhasználói felület alkalmazás ezeket az eseményeket egyenként eltávolítja úgy, hogy getNextEvent() egy eseményhurokban meghívott vagy hasonló rutint hív meg , majd felhívja a megfelelő alkalmazás rutint az esemény feldolgozásához.

Lásd még

Hivatkozások