Service Bus üzenetsorok, témakörök és előfizetések

Az Azure Service Bus támogatja a megbízható üzenetsorkezelést és a tartós közzétételi/feliratkozási üzenetküldést. A Service Bus üzenetkezelési képességeinek magját alkotó üzenetkezelési entitások üzenetsorok, témakörök és előfizetések.

Ez a cikk bemutatja ezeket az alapvető üzenetkezelési entitásokat, azok előnyeit, valamint azt, hogy mikor érdemes ezeket használni az alkalmazásarchitektúrában.

Fontos

Ha még nem ismerkedik az Azure Service Bus szolgáltatással, olvassa el az Azure Service Bus bemutatása című cikket, mielőtt áttekintené ezt a cikket.

Válasszon az üzenetsorok és a témák között

Az alábbi táblázat összefoglalja az üzenetsorok és a témakörök közötti főbb különbségeket, hogy segítsen kiválasztani a forgatókönyvéhez megfelelő üzenetkezelési entitást.

Tulajdonság Várólisták Témakörök és előfizetések
Kommunikációs minta Pont-pont közötti Közzététel/előfizetés (egy-többhöz)
Üzenetkézbesítés Egyetlen fogyasztó üzenetenként Több előfizető is kaphat másolatot
Használati eset Tevékenységelosztás, terhelés simítás Eseményközvetítés, rajongói forgatókönyvek
Szűrés Nem támogatott Előfizetési szűrők szelektív üzenetkézbesítéshez

Várólisták

Az üzenetsorok elsőnek be, elsőnek ki (First In, First Out, FIFO) üzenetküldést biztosítanak egy vagy több konkuráló fogyasztó számára. 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. És csak egy üzenetfogyasztó fogad és dolgoz fel minden üzenetet.

Egy Service Bus-üzenetsor diagramja, amelyen a feladóktól az üzenetsorig, majd a fogadókig áramló üzenetek láthatók.

Az üzenetsorok használatának előnyei

Előny Description
Időbeli leválasztás A gyártóknak (feladóknak) és a fogyasztóknak (fogadóknak) nem kell egyszerre üzeneteket küldeniük és fogadniuk, mert az üzeneteket a rendszer tartósan tárolja az üzenetsorban. A gyártónak nem kell megvárnia a fogyasztó válaszát a feldolgozás folytatásához.
Terhelés simítás A termelők és a fogyasztók különböző díjszabás szerint küldhetnek és fogadhatnak üzeneteket. A fogyasztó alkalmazásnak csak az átlagos terhelést kell kezelnie a csúcsterhelés helyett, ezzel megtakarítani az infrastruktúra költségeit.
Versengő fogyasztók Több feldolgozói folyamat is beolvasható az üzenetsorból, és mindegyik üzenetet csak egy feldolgozó dolgozza fel. Ez a lekéréses terheléselosztás lehetővé teszi a munkavállalók számára, hogy saját maximális sebességükkel dolgozzanak.
Laza csatlakozó Mivel a termelők és a fogyasztók nem ismerik egymást, a fogyasztó a gyártó befolyásolása nélkül frissíthető.

Sorok létrehozása

A sorokat az alábbi lehetőségek közül egyet választva hozhatja létre.

Ezután küldjön és fogadjon üzeneteket olyan ügyfelekkel, amelyek programozási nyelveken vannak írva, többek között az alábbiakat.

Fogadási módok

Két különböző módot adhat meg, amelyekben a felhasználók üzeneteket fogadhatnak a Service Bustól.

Fogadási és törlési mód

Amikor a Service Bus megkapja a kérést a fogyasztótól, megjelöli az üzenetet felhasználtként, és visszaküldi azt a fogyasztói alkalmazásnak. Ez a mód a legegyszerűbb modell, és olyan helyzetekben működik a legjobban, amikor az alkalmazás el tudja viselni, hogy nem dolgoz fel üzenetet, ha hiba történik.

Ha a fogyasztó összeomlik az üzenet feldolgozása előtt, az üzenet elveszik, mert a Service Bus már felhasználtként jelölte meg. Ezt a folyamatot gyakran nevezik legfeljebb egyszer feldolgozásnak.

Betekintő zárolási mód

A Fogadás művelet kétfázisúvá válik, ami lehetővé teszi az olyan alkalmazások támogatását, amelyek nem tudják elviselni a hiányzó üzeneteket:

  1. Megkeresi a következő felhasználandó üzenetet, zárolja , hogy más felhasználók ne fogadják, majd visszaadja az üzenetet az alkalmazásnak.
  2. Miután az alkalmazás befejezi az üzenet feldolgozását, kérést küld a Service Bus szolgáltatásnak, hogy hajtsa végre a fogadási folyamat második szakaszát. Ezután a szolgáltatás az üzenetet felhasználtként jelöli meg.

Hibák kezelése betekintő zárolási módban:

  • Megszakítás: Ha az alkalmazás nem tudja feldolgozni az üzenetet, kérheti a Service Bustól, hogy hagyja abba az üzenetet. A Service Bus feloldja az üzenetet, és elérhetővé teszi az újbóli fogadáshoz.
  • Zárolási időtúllépés: Ha az alkalmazás nem tudja feldolgozni az üzenetet a zárolási időtúllépés lejárta előtt, a Service Bus feloldja az üzenetet, és elérhetővé teszi, hogy újra megkapja.
  • Alkalmazás összeomlása: Ha az alkalmazás az üzenet feldolgozása után, de a befejezés előtt összeomlik, a Service Bus újra kézbesíti az üzenetet, amikor az alkalmazás újraindul. Ezt a folyamatot gyakran legalább egyszer feldolgozzák.

Ha a forgatókönyv nem tudja elviselni a duplikált feldolgozást, adjon hozzá további logikát az alkalmazáshoz az ismétlődések észleléséhez. További információ: Duplikált észlelés, amelyet pontosan egyszer kell feldolgozni.

Feljegyzés

A két módról további információt a fogadási műveletek kiegyenlítése című témakörben talál.

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

Az üzenetsor lehetővé teszi az üzenetek egyetlen fogyasztó általi feldolgozását. Az üzenetsorokkal ellentétben a témák és előfizetések egy-a-többhöz típusú kommunikációt biztosítanak egy közzétételi és előfizetési mintázatban. Ez hasznos lehet, amikor nagy számú címzetthez kell méretezni a rendszert. Minden közzétett üzenet elérhetővé válik a témakörben regisztrált összes előfizetésnél. A Publisher üzenetet küld egy témakörnek, és egy vagy több előfizető megkapja az üzenet másolatát.

Egy Service Bus-témakör diagramja három előfizetéssel, amely üzenetek másolatait kapja.

A közzétevők ugyanúgy küldenek üzeneteket egy témakörbe, mint egy üzenetsorba. A felhasználók azonban nem kapnak közvetlenül a témakörből üzeneteket. Ehelyett a felhasználók üzeneteket kapnak a témakör előfizetéseitől. Egy 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 ahogyan az üzenetsorból érkező üzeneteket fogadják. Az üzenetsor üzenetküldő funkciója közvetlenül egy témakörre tükröződik, az üzenetátvevő funkció pedig egy előfizetésre leképeződik. Ez a funkció többek között azt jelenti, hogy az előfizetések ugyanazokat a mintákat támogatják, amelyeket az ebben a szakaszban korábban leírtak az üzenetsorok tekintetében: versengő fogyasztó, időbeli szétválasztás, terhelés simítás és terheléselosztás.

Előfizetési szűrők

Az előfizetések meg tudják határozni, hogy mely üzeneteket szeretnék megkapni egy témakörből. Ezen üzenetek egy vagy több névvel ellátott előfizetési szabály formájában adhatók meg. Minden szabály egy szűrőfeltételből áll, amely bizonyos üzeneteket jelöl ki, és opcionálisan tartalmaz egy műveletet , amely széljegyzeteket ad a kijelölt üzenetnek. Alapértelmezés szerint egy témakör előfizetése megkapja a témakörnek küldött összes üzenetet. Az előfizetés kezdeti alapértelmezett szabálya igaz szűrővel rendelkezik, amely lehetővé teszi az összes üzenet kijelölését az előfizetésben. Az alapértelmezett szabály nem rendelkezik társított műveletekkel. Az előfizetéseken szabályokkal és műveletekkel rendelkező szűrőket határozhat meg, hogy az előfizetés csak a témakörnek küldött üzenetek egy részhalmazát kapja meg.

A szűrőkről további információt a Szűrők és műveletek című témakörben talál.

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 az előző szakaszban leírtak szerint. Témaköröket és előfizetéseket az alábbi lehetőségek egyikével hozhat létre:

Ezután küldjön üzeneteket egy témakörhöz, és fogadjon üzeneteket előfizetésekből, a programozási nyelveken írt kliensek használatával, például a következőkkel:

Szabályok és műveletek

Sok esetben az adott 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 megkereshessék a kívánt tulajdonságokkal rendelkező üzeneteket, majd bizonyos módosításokat hajtsanak végre ezen tulajdonságokon. Bár a Service Bus-előfizetések az összes, a témakörnek küldött üzenetet látják, ezeknek az üzeneteknek csak egy részét másolhatja a virtuális előfizetés üzenetsorába. 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 a rendszertulajdonságok (például a Címke) és az egyéni alkalmazástulajdonságok (például StoreName). Ebben az esetben az SQL-szűrőkifejezés nem kötelező. SQL-szűrőkifejezés nélkül az előfizetésben definiált szűrőműveleteket az adott előfizetés összes üzenetén végrehajtja a rendszer.

A teljes körű példáért tekintse meg a TopicFilters példát a GitHub-on. 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

A következő 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 tagolt tartós előfizetések
  • Megosztott, nem használható 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.

Expressz entitások

Fontos

Az expressz entitások nem ajánlottak új alkalmazásokhoz. Az átviteli sebesség és a késés előnyei jelenleg minimálisak a Service Bus optimalizálásainak köszönhetően. A Service Bus prémium szintű csomagja nem támogatja az Express-entitásokat.

Az expressz entitások nagy átviteli sebességhez és csökkentett késési forgatókönyvekhez lettek létrehozva. Az expressz entitások esetében, ha üzenetsorba vagy témakörbe kerül, a rendszer nem tárolja azonnal az üzenettárban. Ehelyett az üzenet eleinte a memóriában kerül gyorsítótárazásra. Az entitásban maradó üzeneteket a rendszer késleltetés után írja az üzenettárba, amely időponttól kezdve védelemmel rendelkezik a kimaradás miatti veszteség ellen.

Normál entitásokban minden futásidejű művelet (például Send, Complete, Abandon, Deadletter) először kerül rögzítésre a tárban, és csak azután, hogy a műveletet sikeresnek ismerik el az ügyfél felé. Az expressz entitásokban a futásidejű műveletet először sikeresnek ismerik el az ügyfél felé, és csak később, lustán perzisztálják az adatbázisba. Ennek eredményeképpen, amikor egy gép újraindul, vagy hardverhiba lép fel, előfordulhat, hogy bizonyos elismert futtatókörnyezeti műveletek egyáltalán nem maradnak meg. Ebben az esetben az ügyfél alacsonyabb késést és nagyobb átviteli sebességet kap az expressz entitásokkal, az üzenetek esetleges adatvesztésének és/vagy újraküldésének rovására.

Következő lépések

Próbálja ki a mintákat a választott nyelven:

A régebbi .NET- és Java-ügyfélkódtárakat használó mintákhoz használja az alábbi hivatkozásokat:

2026. szeptember 30-án kivonjuk az Azure Service Bus SDK-kódtárakat a WindowsAzure.ServiceBus, a Microsoft.Azure.ServiceBus és a com.microsoft.azure.servicebus kódtárakból, amelyek nem felelnek meg az Azure SDK irányelveinek. Az SBMP protokoll támogatását is megszüntetjük, így 2026. szeptember 30. után már nem használhatja ezt a protokollt. Migrálás a legújabb Azure SDK-kódtárakba, amelyek kritikus fontosságú biztonsági frissítéseket és továbbfejlesztett képességeket kínálnak ezen dátum előtt.

Bár a régebbi kódtárak 2026. szeptember 30. után továbbra is használhatók lesznek, már nem kapnak hivatalos támogatást és frissítéseket a Microsofttól. További információkért lásd a támogatási nyugdíjazási bejelentést.

  • Last updated on