Service Bus queues, topics, and subscriptions (Service Bus-üzenetsorok, -témakörök és -előfizetések)

  • Cikk
  • 5 perc alatt elolvasható

Azure Service Bus számos felhőalapú, üzenetorientált köztes szoftvertechnológiát támogat, beleértve a megbízható üzenetsorkezelést és a tartós közzétételi/feliratkozási üzenetküldést. Ezek a közvetítőalapú üzenetküldési képességek a közzétételi-feliratkozási, időbeli leválasztási és terheléselosztási forgatókönyveket támogató, leválasztott üzenetküldési funkcióknak tekinthetők az Service Bus üzenetkezelési számítási feladat használatával. A leválasztott kommunikációnak számos előnye van. Az ügyfelek és a kiszolgálók például szükség szerint csatlakozhatnak, és aszinkron módon végezhetik el a műveleteiket.

A Service Bus üzenetkezelési képességeinek alapvető részét képező üzenetkezelési entitások az üzenetsorok, a témakörök és az előfizetések, valamint a szabályok/műveletek.

Üzenetsorok

Az üzenetsorok a First In, First Out (FIFO) üzenetkézbesítést kínálják egy vagy több versengő fogyasztónak. Ez azt jelzi, hogy a fogadók általában abban a sorrendben fogadják és dolgozzák fel az üzeneteket, amelyben hozzáadták őket az üzenetsorhoz. Emellett az egyes üzeneteket csak egy üzenet fogadja és dolgozza fel. Az üzenetsorok használatának egyik fő előnye az alkalmazás-összetevők időbeli szétválasztása. Más szóval az előállítóknak (feladóknak) és fogyasztóknak (fogadóknak) nem kell egyszerre üzeneteket küldeniük és fogadniuk. Ennek az az oka, hogy az üzenetek tartósan az üzenetsorban vannak tárolva. Emellett a gyártónak nem kell megvárnia a fogyasztó válaszát, hogy továbbra is feldolgozhassa és elküldhesse az üzeneteket.

A kapcsolódó előnyök a terhelésszintezés, amely lehetővé teszi az előállítók és a fogyasztók számára, hogy különböző arányban küldjenek és fogadjanak üzeneteket. Sok alkalmazásban a rendszer terhelése idővel változik. Az egyes munkaegységekhez szükséges feldolgozási idő azonban általában állandó. Az üzenetkészítők és a fogyasztók üzenetsorokkal való szervizelése azt jelenti, hogy a fogyasztó alkalmazásnak csak az átlagos terhelést kell kezelnie a csúcsterhelés helyett. A bejövő terhelés változásával az üzenetsor hossza nő vagy csökken. Ez a képesség közvetlenül pénzt takarít meg az alkalmazás terhelésének kiszolgálásához szükséges infrastruktúra mennyiségével kapcsolatban. A terhelés növekedésével több feldolgozói folyamat adható hozzá az üzenetsorból való olvasáshoz. Az egyes üzeneteket a feldolgozó folyamatoknak csak az egyike dolgozza fel. Továbbá ez a lekéréses alapú terheléselosztás lehetővé teszi a feldolgozó számítógépek optimális használatát még akkor is, ha a feldolgozó számítógépek a teljesítmény-lekérési üzeneteket a saját maximális sebességükön dolgozták fel. Ezt a mintát gyakran a versengő felhasználó mintának hívják.

Az üzenetsorok használata az üzenetkészítők és a fogyasztók közötti köztes kapcsolatokhoz biztosítja az összetevők közötti laza kapcsolatot. Mivel a termelők és a fogyasztók nem ismerik egymást, a fogyasztók anélkül frissíthetők, hogy ez hatással lenne a gyártóra.

Üzenetsorok létrehozása

Üzenetsorokat a Azure Portal, a PowerShell, a parancssori felület vagy az Azure Resource Manager-sablonok (ARM-sablonok) használatával hozhat létre. Ezután C#, Java, Python és JavaScript nyelven írt ügyfelekkel küldhet és fogadhat üzeneteket.

Fogadási módok

Két különböző módot adhat meg, amelyekben Service Bus fogadja az üzeneteket.

  • Fogadás és törlés. Ebben a módban, amikor Service Bus fogadja a kérést a fogyasztótól, a rendszer felhasználtként jelöli meg az üzenetet, és visszaküldi azt a fogyasztói alkalmazásnak. Ez a legegyszerűbb modell. Az olyan helyzetekben működik a legjobban, amikor az alkalmazás nem tudja feldolgozni az üzeneteket hiba esetén. A forgatókönyv megértéséhez fontolja meg azt a forgatókönyvet, amelyben a fogyasztó kiadja a fogadási kérést, majd összeomlik a feldolgozás előtt. Mivel Service Bus az üzenetet használatban lévőként jelöli meg, az alkalmazás az újraindításkor megkezdi az üzenetek felhasználását. Az összeomlás előtt felhasznált üzenet nem jelenik meg.
  • Betekintőzár. Ebben a módban a fogadási művelet két fázisúvá válik, ami lehetővé teszi az olyan alkalmazások támogatását, amelyek nem tolerálják a hiányzó üzeneteket.

    1. Megkeresi a következő felhasználandó üzenetet, zárolja , hogy mások ne kapják meg, majd küldje vissza az üzenetet az alkalmazásnak.

    2. Miután az alkalmazás befejezte az üzenet feldolgozását, kéri a Service Bus szolgáltatást a fogadási folyamat második szakaszának befejezésére. Ezután a szolgáltatás felhasználtként jelöli meg az üzenetet.

      Ha az alkalmazás valamilyen okból nem tudja feldolgozni az üzenetet, kérheti a Service Bus szolgáltatástól, hogy hagyja abba az üzenetet. Service Bus feloldja az üzenetet, és elérhetővé teszi, hogy az ugyanazon fogyasztó vagy egy másik versengő fogyasztó ismét megkapja. Másodszor, a zároláshoz időkorlát van társítva. Ha az alkalmazás nem tudja feldolgozni az üzenetet a zárolási időkorlát lejárta előtt, Service Bus feloldja az üzenet zárolását, és elérhetővé teszi, hogy újra megkapja.

      Ha az alkalmazás összeomlik az üzenet feldolgozása után, de mielőtt a Service Bus szolgáltatást az üzenet befejezésére kéri, Service Bus újra kézbesíti az üzenetet az alkalmazásnak, amikor újraindul. Ezt a folyamatot gyakran legalább egyszer kell feldolgozni. Vagyis minden üzenet feldolgozása legalább egyszer megtörténik. Bizonyos helyzetekben azonban előfordulhat, hogy ugyanez az üzenet újra lesz kézbesítve. Ha a forgatókönyv nem tolerálja a duplikált feldolgozást, adjon hozzá további logikát az alkalmazásban az ismétlődések észleléséhez. További információ: Duplikátumészlelés. Ezt a funkciót pontosan egyszeri feldolgozásnak nevezzük.

      Megjegyzés

      További információ erről a két módról: Fogadási műveletek rendezése.

Témakörök és előfizetések

Az üzenetsorok lehetővé teszik az üzenetek egyetlen fogyasztó általi feldolgozását. Az üzenetsorokkal ellentétben a témakörök és előfizetések egy-a-többhöz típusú kommunikációt biztosítanak közzétételi és előfizetési mintában. Nagy számú címzettre való skálázáshoz hasznos. Minden közzétett üzenet elérhetővé válik a témakörrel regisztrált előfizetések számára. Publisher üzenetet küld egy témakörbe, és egy vagy több előfizető megkapja az üzenet másolatát az előfizetésekre vonatkozó szűrési szabályoktól függően. Az előfizetések további szűrőkkel korlátozhatják a fogadni kívánt üzeneteket. A közzétevők ugyanúgy küldenek üzeneteket egy témakörbe, mint az üzenetsorba. A fogyasztók azonban nem kapnak közvetlenül a témakörből üzeneteket. Ehelyett a felhasználók a témakör előfizetéseitől kapnak üzeneteket. A témakör-előfizetés hasonlít egy virtuális üzenetsorra, amely megkapja a témakörbe küldött üzenetek másolatait. A fogyasztók ugyanúgy kapnak üzeneteket egy előfizetésből, mint az üzenetsorból érkező üzenetek.

Az üzenetsor üzenetküldési funkciói közvetlenül egy témakörre, az üzenetfogadási funkció pedig egy előfizetésre képezhetők le. Ez a funkció többek között azt jelenti, hogy az előfizetések ugyanazokat a mintákat támogatják, mint az üzenetsorok korábbi részében: versengő fogyasztó, időbeli szétválasztás, terheléskiegyenlítés és terheléselosztás.

Témakörök és előfizetések létrehozása

A témakör létrehozása hasonló az üzenetsor létrehozásához, ahogy azt az előző szakaszban ismertettük. Témaköröket és előfizetéseket a Azure Portal, a PowerShell, a parancssori felület vagy az ARM-sablonok használatával hozhat létre. Ezután küldjön üzeneteket egy témakörbe, és fogadjon üzeneteket az előfizetésekből C#, Java, Python és JavaScript nyelven írt ügyfelek használatával.

Szabályok és műveletek

Sok esetben a konkrét jellemzőkkel rendelkező üzeneteket különböző módokon kell feldolgozni. A feldolgozás engedélyezéséhez úgy konfigurálhatja az előfizetéseket, hogy megtalálják a kívánt tulajdonságokkal rendelkező üzeneteket, majd bizonyos módosításokat hajtsanak végre ezen tulajdonságokon. Bár Service Bus előfizetések a témakörbe küldött összes üzenetet látják, az üzeneteknek csak egy részhalmazát lehet átmásolni a virtuális előfizetési üzenetsorba. Ez a szűrés előfizetési szűrőkkel történik. Az ilyen módosításokat szűrőműveleteknek nevezzük. Előfizetés létrehozásakor megadhat egy szűrőkifejezést, amely az üzenet tulajdonságain működik. A tulajdonságok lehetnek rendszertulajdonságok (például Címke) és egyéni alkalmazástulajdonságok (például StoreName). Az SQL-szűrőkifejezés ebben az esetben nem kötelező. SQL-szűrőkifejezés nélkül az előfizetésen definiált szűrőműveleteket az adott előfizetéshez tartozó összes üzeneten végrehajtja a rendszer.

Teljes körű példaként tekintse meg a TopicFilters mintát GitHub.

További információ a szűrőkről: Témakörszűrők és műveletek.

Java Message Service (JMS) 2.0-entitások

Az alábbi entitások a Java Message Service (JMS) 2.0 API-n keresztül érhetők el.

  • Ideiglenes üzenetsorok
  • Ideiglenes témakörök
  • Megosztott tartós előfizetések
  • Nem megosztható tartós előfizetések
  • Megosztott, nem tartós előfizetések
  • Nem megosztható, nem tartós előfizetések

További információ a JMS 2.0-entitásokról és azok használatáról.

Következő lépések

Próbálja ki a mintákat az Ön által választott nyelven, hogy megismerje Azure Service Bus funkciókat.

A régebbi .NET- és Java-ügyfélkódtárak mintáit az alábbiakban találja: