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

Az Azure Service Bus felhőalapú, üzenetorientált, a megbízható üzenetsor-szolgáltatást és a tartós közzétételi/előfizetési üzenetkezelést is támogatja. Ezek a közvetítőn keresztüli üzenetkezelési képességek olyan leválasztott üzenetkezelési funkciókként biztosítanak támogatást, amelyek támogatják a közzétételi-feliratkozásos, az időbeli leválasztást és a terheléselosztási forgatókönyveket az Service Bus üzenetkezelési számítási feladattal. 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 is el is végrehajtásához.

A szolgáltatás üzenetkezelési képességeinek magját Service Bus üzenetsorok, témakörök és előfizetések, valamint szabályok/műveletek.

Üzenetsorok

Az üzenetsorok elsőnek be, elsőnek ki (First In, First Out, FIFO) üzenet kézbesítését kínálják egy vagy több versengő fogyasztónak. Ez azt jelenti, hogy a fogadók általában abban a sorrendben kapják meg és feldolgozják az üzeneteket, ahogy hozzá vannak adva az üzenetsorhoz. Az egyes üzeneteket pedig csak egy üzenet fogyasztója fogadja és dolgozza fel. Az üzenetsorok használatának egyik fő előnye az alkalmazás-összetevők időbeli leválasztásának megvalósítása. Más szóval az előállítóknak (feladóknak) és fogyasztóknak (fogadóknak) nem kell egyidejűleg üzeneteket küldeniük és fogadnia. Ennek az az oka, hogy az üzenetek tartósan vannak tárolva az üzenetsorban. Emellett az előállítónak nem kell megvárni, amíg a fogyasztó válasza folytatja az üzenetek feldolgozását és küldését.

Egy kapcsolódó előny a terheléselosztás, amely lehetővé teszi az előállítók és fogyasztók számára, hogy különböző díjszabású üzeneteket küldjenek és fogadjanak. Számos alkalmazásban a rendszerterhelés idővel változik. Az egyes munkaegységhez szükséges feldolgozási idő azonban általában állandó. Az üzenetek előállítóinak és fogyasztóinak üzenetsorokkal való összekapcsolása 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ásterhelés kiszolgálásához szükséges infrastruktúra mennyiségével kapcsolatban. A terhelés növekedésével további munkavégző folyamatok is hozzáadhatóak az üzenetsorból való olvasáshoz. Az egyes üzeneteket a feldolgozó folyamatoknak csak az egyike dolgozza fel. Ez a le pull-alapú terheléselosztás még akkor is lehetővé teszi a munkavégző számítógépek legjobb használatát, ha a munkavégző számítógépek a saját maximális sebességükön feldolgozási teljesítményt lekért üzenetekkel használják. Ezt a mintát gyakran a versengő felhasználó mintának hívják.

Az üzenetsorok az üzenet-előállítók és a fogyasztók közötti köztes megoldásokkal eredendően lazán összekapcsolják az összetevőket. Mivel az előállítók és a fogyasztók nem ismerik egymást, a fogyasztók anélkül frissíthetőek, hogy ez hatással lenne az előállítóra.

Üzenetsorok létrehozása

Üzenetsorokat a következő sablonokkal hozhatAzure Portal: , PowerShell, CLI vagy Resource Manager sablonokkal. 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 is megadhat, amelyekben a Service Bus fogad üzeneteket.

  • A fogadása és törlése. Ebben a módban, Service Bus fogadja a kérést a fogyasztótól, az fogyasztóként jelöli meg az üzenetet, és visszaadja a fogyasztói alkalmazásnak. Ez a legegyszerűbb modell. Akkor működik a legjobban, ha az alkalmazás hiba esetén nem képes feldolgozni egy üzenetet. A forgatókönyvet úgy értheti meg, ha a fogyasztó ki ad ki egy fogadási kérést, majd a feldolgozás előtt összeomlik. Ahogy Service Bus, az alkalmazás az újraindításkor megkezdi az üzenetek fogadását. Az összeomlás előtt felhasznált üzenetet kihagyja.
  • Betekintés a zárolásba. Ebben a módban a fogadási művelet két szakaszból áll, ami lehetővé teszi olyan alkalmazások támogatását, amelyek nem tolerálják a hiányzó üzeneteket.
    1. Megkeresi a következő felhasznált üzenetet, zárolja azt, hogy más fogyasztók ne kapják meg, majd visszaadja az üzenetet az alkalmazásnak.

    2. Miután az alkalmazás befejezte az üzenet feldolgozását, a Service Bus a fogadási folyamat második szakaszának befejezésére kéri a Service Bus szolgáltatást. 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 fel az üzenetet. Service Bus feloldja az üzenetet, és elérhetővé teszi azt, hogy ugyanaz a fogyasztó vagy egy másik versengő fogyasztó is megkapja. Másodszor a zároláshoz időtúllépés van társítva. Ha az alkalmazás nem tudja feldolgozni az üzenetet a zárolási időkorlát lejárta előtt, a Service Bus feloldja az üzenetet, és elérhetővé teszi azt, hogy ismét megkapható legyen.

      Ha az alkalmazás összeomlik az üzenet feldolgozása után, de mielőtt az Service Bus szolgáltatást az üzenet befejezésére kéri, a Service Bus újra kézbesíti az üzenetet az alkalmazásnak az újraindításkor. Ezt a folyamatot gyakran legalább egyszer feldolgozásnak nevezik. Ez azt jelenti, hogy a rendszer minden üzenetet legalább egyszer feldolgoz. Bizonyos helyzetekben azonban ugyanez az üzenet újraküldhető. Ha a forgatókönyv nem tudja tűrni 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ó: Ismétlődések észlelése. Ezt a funkciót pontosan egyszer történő feldolgozásnak nevezik.

      Megjegyzés

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

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

Az üzenetsorok lehetővé teszik az üzenetek feldolgozását egyetlen fogyasztó számára. Az üzenetsorokkal ellentétben a témakörök és előfizetések egy-a-több hez típusú kommunikációt biztosítanak közzétételi és előfizetési mintában. Nagy számú címzettre való méretezéshez hasznos. Minden közzétett üzenet elérhetővé válik a témakörben regisztrált összes előfizetés számára. Publisher egy üzenetet küld egy témakörbe, és egy vagy több előfizető megkapja az üzenet másolatát az előfizetésen beállított 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 üzeneteket közvetlenül a témakörből. Ehelyett a fogyasztók üzeneteket kapnak a témakör előfizetéseiből. A témakör-előfizetés egy virtuális üzenetsorhoz hasonlít, amely a témakörbe küldött üzenetek másolatát fogadja. A fogyasztók ugyanolyan üzeneteket kapnak egy előfizetéstől, mint az üzenetsorból.

Az üzenetsorok üzenetküldő funkciója közvetlenül egy témakörre van leképezve, az üzenet fogadása pedig egy előfizetésre van leképezve. Ez a funkció többek között azt jelenti, hogy az előfizetések támogatják a szakasz korábbi részében ismertetett mintákat az üzenetsorokkal kapcsolatban: versengő fogyasztó, időbeli levá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ök létrehozása hasonlít az üzenetsorok létrehozásához, az előző szakaszban leírtak szerint. Témaköröket és előfizetéseket a következő sablonokkal hozhat létre: Azure Portal, PowerShell, CLI vagy Resource Manager sablonokkal. Ezután küldjön üzeneteket egy témakörbe, és fogadja az előfizetések üzeneteit a C#, Java, Pythonés JavaScript nyelven írt ügyfelek használatával.

Szabályok és műveletek

Sok esetben a konkrét jellemzőkkel bíró üzeneteket különböző módokon kell feldolgozni. A feldolgozás engedélyezéséhez úgy konfigurálhatja az előfizetéseket, hogy megkeressék a kívánt tulajdonságokkal kapcsolatos ü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észkészletét másolhatja a virtuális előfizetés üzenetsorába. Ezt a szűrést előfizetési szűrők használatával lehet elvégezni. Az ilyen módosításokat szűrési műveleteknek nevezzük. Az előfizetés létrehozásakor meg lehet küldeni egy szűrőkifejezést, amely az üzenet tulajdonságain működik. A tulajdonságok a rendszertulajdonságok (például Címke) és az egyéni alkalmazástulajdonságok (például StoreName .) is lehet. A SQL kifejezés ebben az esetben nem kötelező. Szűrőkifejezés SQL nélkül az előfizetésen definiált összes szűrő művelet az előfizetéshez megadott összes üzeneten meg lesz adva.

Teljes körű példaként tekintse meg a TémakörSzűrők mintát a 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 Üzenetszolgáltatás (JMS) 2.0 API-n keresztül érhetők el.

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

További információk a JMS 2.0-entitásokkal és azok használatával kapcsolatban.

Következő lépések

Próbálja ki a mintákat az Ön által választott nyelven, és fedezze fel az Azure Service Bus funkcióit.

Az alábbiakban példákat talál a régebbi .NET- és Java-ügyfélkódtárakhoz: