Megosztás a következőn keresztül:


Üzenet-munkamenetek

Az Azure Service Bus-munkamenetek lehetővé teszik a nem kötött kapcsolódó üzenetsorozatok együttes és rendezett kezelését. A munkamenetek az első be - és kimenő (FIFO) és a kérés-válasz mintákban használhatók. Ez a cikk bemutatja, hogyan valósíthatja meg ezeket a mintákat a Service Bus használatakor munkamenetek használatával.

Feljegyzés

Az alapszintű Service Bus nem támogatja a munkameneteket. A standard és prémium szintek támogatják a munkameneteket. A szintek közötti különbségekért tekintse meg a Service Bus díjszabását.

First-in, first out (FIFO) minta

Ha FIFO-garanciát szeretne megvalósítani az üzenetek Service Bus-üzenetsorokban vagy előfizetésekben való feldolgozására, használjon munkameneteket. A Service Bus nem ismerteti az üzenetek közötti kapcsolat természetét, és nem határoz meg egy adott modellt annak meghatározásához, hogy hol kezdődik vagy végződik egy üzenetütemezés.

Bármely feladó létrehozhat egy munkamenetet, amikor üzeneteket küld egy témakörbe vagy üzenetsorba, ha a munkamenet-azonosító tulajdonságot a munkamenetre egyedi alkalmazás által meghatározott azonosítóra állítja. Az AMQP 1.0 protokoll szintjén ez az érték a csoportazonosító tulajdonsághoz lesz megfeleltetve.

Munkamenet-tudatos üzenetsorok vagy előfizetések esetén a munkamenetek akkor jönnek létre, ha legalább egy üzenet van a munkamenet-azonosítóval. Ha már létezik munkamenet, nincs meghatározott idő vagy API arra az időre, amikor a munkamenet lejár vagy eltűnik. Elméletileg egy ma, egy év múlva következő üzenetre fogadható üzenet, és ha a munkamenet-azonosító megegyezik, a munkamenet megegyezik a Service Bus szempontjából.

Általában azonban egy alkalmazásnak egyértelmű fogalma van, hogy hol kezdődnek és végződnek a kapcsolódó üzenetek. A Service Bus nem állít be konkrét szabályokat. Az alkalmazás például beállíthatja a Címke tulajdonságot az első üzenet indításához, a köztes üzenetekhez a tartalomhoz és az utolsó üzenet befejezéséhez. A tartalomüzenetek relatív pozíciója az aktuális üzenet, a SequenceNumber eltéréseként számítható ki a SequenceNumber kezdő üzenettől.

Fontos

Ha a munkamenetek engedélyezve vannak egy üzenetsoron vagy előfizetésen, az ügyfélalkalmazások már nem küldhetnek/fogadhatnak rendszeres üzeneteket. Minden üzenetet egy munkamenet részeként (a munkamenet azonosítójának beállításával) kell elküldeni, és a munkamenet elfogadásával kell fogadni. Előfordulhat, hogy az ügyfelek továbbra is betekintenek egy üzenetsorba vagy előfizetésbe, amelynek munkamenetei engedélyezve vannak. Lásd: Üzenetböngészés.

A munkamenetekhez tartozó API-k az üzenetsor- és előfizetés-ügyfeleken találhatók. Létezik egy imperatív modell, amely szabályozza a munkamenetek és üzenetek fogadását, valamint egy kezelőalapú modell, amely elrejti a fogadási ciklus kezelésének összetettségét.

Mintákhoz használja a Következő lépések szakaszban található hivatkozásokat .

Munkamenet-funkciók

A munkamenetek egyidejűleg demultiplexinget biztosítanak az interleaved üzenetstreamek számára, miközben megőrzik és garantálják a rendezett kézbesítést.

Diagram that shows how the Sessions feature preserves an ordered delivery.

A munkamenet-fogadót a munkamenetet elfogadó ügyfél hozza létre. Amikor egy ügyfél elfogadja és megtartja a munkamenetet, az ügyfél kizárólagos zárolást tart az adott munkamenet munkamenet-azonosítójával rendelkező összes üzenetre az üzenetsorban vagy az előfizetésben. Kizárólagos zárolásokat tartalmaz a munkamenet-azonosítóval rendelkező összes üzeneten, amelyek később érkeznek.

A zárolás akkor szabadul fel, ha szoros metódusokat hív meg a fogadón, vagy ha a zárolás lejár. A zárak megújítására is vannak módszerek a vevőn. Ehelyett használhatja az automatikus zárolásmegújítási funkciót, ahol megadhatja, hogy mennyi ideig szeretné megújítani a zárolást. A munkamenet-zárolást úgy kell kezelni, mint egy fájl kizárólagos zárolását, ami azt jelenti, hogy az alkalmazásnak azonnal be kell zárnia a munkamenetet, amint már nincs rá szüksége, és/vagy nem vár további üzeneteket.

Amikor több egyidejű fogadó is lekéri az üzenetsort, a rendszer az adott munkamenethez tartozó üzeneteket küldi el annak a fogadónak, amely jelenleg zárolja a munkamenetet. Ezzel a művelettel az egy üzenetsorban vagy előfizetésben lévő, egymással összekapcsolt üzenetfolyamok tisztán demultiplexednek a különböző fogadók számára, és ezek a fogadók különböző ügyfélgépeken is képesek élni, mivel a zároláskezelés szolgáltatásoldali, a Service Buson belül történik.

Az előző ábrán három egyidejű munkamenet-fogadó látható. Egy = 4-et tartalmazó SessionId munkamenet nem rendelkezik aktív, tulajdonos ügyféllel, ami azt jelenti, hogy az adott munkamenetből nem érkeznek üzenetek. A munkamenetek többféleképpen is viselkednek, például egy alsor.

A munkamenet-fogadó által tartott munkamenet-zárolás a betekintő zárolási mód által használt üzenetzárak esernyője. Csak egy fogadó rendelkezhet zárolással egy munkameneten. Előfordulhat, hogy a fogadó számos fedélzeti üzenetet tartalmaz, de az üzenetek sorrendben érkeznek. Az üzenet elhagyása esetén ugyanazt az üzenetet ismét kézbesíti a rendszer a következő fogadási művelettel.

Üzenet munkamenetének állapota

Ha a munkafolyamatokat nagy léptékű, magas rendelkezésre állású felhőrendszerekben dolgozzák fel, az adott munkamenethez társított munkafolyamat-kezelőnek képesnek kell lennie a váratlan hibákból való helyreállításra, és a részben befejezett munkát egy másik folyamaton vagy gépen folytatni, ahonnan a munka elkezdődött.

A munkamenet-állapot létesítménye lehetővé teszi egy üzenet munkamenet alkalmazás által meghatározott széljegyzetét a közvetítőn belül, így a munkamenethez viszonyított rögzített feldolgozási állapot azonnal elérhetővé válik, amikor a munkamenetet egy új processzor szerzi be.

A Service Bus szempontjából az üzenet munkamenet-állapota egy átlátszatlan bináris objektum, amely egy üzenet méretű adatokat tárolhat, amely a Service Bus Standard esetében 256 KB, a Service Bus Premium esetében pedig 100 MB. A munkamenethez viszonyított feldolgozási állapot tárolható a munkamenet állapotában, vagy a munkamenet állapota mutathat valamilyen tárolási helyre vagy adatbázisrekordra, amely ezeket az információkat tartalmazza.

A munkamenet-állapot SetState kezelésének módszerei és GetStatea munkamenet-fogadó objektumban találhatók. Az olyan munkamenetek, amelyek korábban nem voltak munkamenet-állapotban, null hivatkozást ad vissza a következőhöz GetState: . A korábban beállított munkamenet-állapot úgy törölhető, ha null értéket ad át a SetState fogadó metódusának.

A munkamenet állapota mindaddig megmarad, amíg nincs törölve (null értéket ad vissza), még akkor is, ha a munkamenet összes üzenete használatban van.

Az üzenetsorban vagy előfizetésben tárolt munkamenet-állapot az entitás tárolási kvótájával számol. Amikor az alkalmazás befejeződött egy munkamenettel, javasoljuk, hogy a külső felügyeleti költségek elkerülése érdekében törölje az alkalmazás megtartott állapotát.

A kézbesítések számának hatása

A munkamenetek kontextusában az üzenetenkénti kézbesítések száma kissé eltér a munkamenetek hiányában használt definíciótól. Íme egy táblázat, amely összefoglalja, hogy a kézbesítések száma mikor növekszik.

Eset Nő-e az üzenet kézbesítési száma?
A munkamenet elfogadva, de a munkamenet-zárolás lejár (időtúllépés miatt) Igen
A munkamenet elfogadott, a munkameneten belüli üzenetek nem fejeződnek be (még akkor sem, ha zárolva vannak), és a munkamenet be van zárva Nem
A munkamenet elfogadott, az üzenetek befejeződnek, majd a munkamenet explicit módon lezárul N/A (Ez a standard folyamat. Itt az üzenetek törlődnek a munkamenetből)

Kérelem-válasz minta

A kérés-válasz minta egy jól bevált integrációs minta, amely lehetővé teszi a küldő alkalmazás számára, hogy küldjön egy kérést, és lehetővé teszi a fogadó számára, hogy helyesen küldje vissza a választ a feladó alkalmazásnak. Ehhez a mintához általában egy rövid életű üzenetsorra vagy témakörre van szükség ahhoz, hogy az alkalmazás válaszokat küldjön. Ebben a forgatókönyvben a munkamenetek egy egyszerű, hasonló szemantikával rendelkező alternatív megoldást nyújtanak.

Több alkalmazás is elküldheti a kéréseit egyetlen kérelemsorba, és egy adott fejlécparaméter van beállítva, amely egyedileg azonosítja a küldő alkalmazást. A fogadó alkalmazás feldolgozhatja az üzenetsorba érkező kéréseket, és válaszokat küldhet a munkamenet-kompatibilis üzenetsoron, a munkamenet-azonosítót pedig a küldő által a kérelemüzenetben küldött egyedi azonosítóra állíthatja. A kérelmet küldő alkalmazás ezután fogadhat üzeneteket az adott munkamenet-azonosítóról, és megfelelően feldolgozhatja a válaszokat.

Feljegyzés

A kezdeti kéréseket küldő alkalmazásnak tudnia kell a munkamenet-azonosítóról, és azt kell használnia a munkamenet elfogadásához, hogy az a munkamenet, amelyen a választ várja, zárolva legyen. Érdemes olyan GUID-t használni, amely egyedileg azonosítja az alkalmazás példányát munkamenet-azonosítóként. Az üzenetsorhoz nem lehet munkamenet-kezelőt vagy időtúllépést megadni a munkamenet-fogadóban annak érdekében, hogy a válaszok zárolhatók és feldolgozhatók legyenek adott fogadók számára.

Szekvenálás és munkamenetek

A sorszám önmagában garantálja az üzenetsorrendet és az üzenetek kinyerési sorrendjét, a munkameneteket igénylő feldolgozási sorrendet azonban nem.

Tegyük fel, hogy három üzenet van az üzenetsorban, és két fogyasztó.

  1. A Consumer 1 az 1. üzenetet veszi fel.
  2. A Consumer 2 a 2. üzenetet veszi fel.
  3. A Consumer 2 befejezi a 2. üzenet feldolgozását, és felveszi a 3. üzenetet, míg az 1. fogyasztó még nem végzi el az 1. üzenet feldolgozását.
  4. A Consumer 2 befejezi a 3. üzenet feldolgozását, de az 1. fogyasztó még nem fejeződött be az 1. üzenet feldolgozásával.
  5. Végül a Consumer 1 befejezi az 1. feldolgozási üzenetet.

Az üzenetek feldolgozása tehát ebben a sorrendben történik: 2. üzenet, 3. üzenet és 1. üzenet. Ha az 1., a 2. és a 3. üzenetet sorrendben kell feldolgozni, munkameneteket kell használnia.

Ha az üzeneteket csak sorrendben kell lekérni, akkor nem kell munkameneteket használnia. Ha az üzeneteket sorrendben kell feldolgozni, használjon munkameneteket. Ugyanazt a munkamenet-azonosítót kell beállítani az egymáshoz tartozó üzenetekre, amelyek lehetnek egy halmaz 1., 4. és 8. üzenetei, egy másik csoportban pedig 2, 3 és 6. üzenet.

Üzenet lejárata

A munkamenet-kompatibilis üzenetsorok vagy témakörök előfizetései esetében az üzenetek a munkamenet szintjén vannak zárolva. Ha bármelyik üzenet élettartamának (TTL) lejár, az adott munkamenethez kapcsolódó összes üzenet elvetve vagy kézbesítetlenként lesz engedélyezve az entitás üzenetküldő lejárati beállításakor engedélyezett holtbetűs üzenetek alapján. Más szóval, ha a munkamenetben egyetlen üzenet van, amely átment a TTL-en, a munkamenet összes üzenete lejárt. Az üzenetek csak akkor járnak le, ha aktív figyelő van. További információ: Üzenet lejárata.

Következő lépések

Üzenetsor létrehozásakor engedélyezheti az üzenetsor-munkameneteket az Azure Portal, a PowerShell, a parancssori felület, a Resource Manager-sablon, a .NET, a Java, a Python és a JavaScript használatával. További információ: Üzenet-munkamenetek engedélyezése.

Az Azure Service Bus funkcióinak megismeréséhez próbálja ki az Ön által választott nyelven elérhető mintákat.