Üzenet-munkamenetekMessage sessions

Microsoft Azure Service Bus-munkamenetek lehetővé teszik a kapcsolódó üzenetek nem kötött sorrendjének együttes és rendezett kezelését.Microsoft Azure Service Bus sessions enable joint and ordered handling of unbounded sequences of related messages. A munkamenetek a-ben , az elsőben (FIFO) és a kérés-válasz mintákban is használhatók.Sessions can be used in first in, first out (FIFO) and request-response patterns. Ez a cikk bemutatja, hogyan használhatja a munkameneteket ezen minták megvalósításához Service Bus használatakor.This article shows how to use sessions to implement these patterns when using Service Bus.

Megjegyzés

A Service Bus alapszintű csomagja nem támogatja a munkamenetek használatát.The basic tier of Service Bus doesn't support sessions. A standard és a prémium szintű csomag támogatja a munkameneteket.The standard and premium tiers support sessions. A szintek közötti különbségekért tekintse meg a Service Bus díjszabását.For differences between these tiers, see Service Bus pricing.

Első – első kimenő (FIFO) mintaFirst-in, first out (FIFO) pattern

Ha Service Bus-ben a FIFO-garanciát szeretné megvalósítani, használja a munkameneteket.To realize a FIFO guarantee in Service Bus, use sessions. Service Bus nem rendelkezik az üzenetek közötti kapcsolat természetétől, és nem határoz meg egy adott modellt, amely meghatározza, hogy a rendszer hol induljon el vagy végződik.Service Bus isn't prescriptive about the nature of the relationship between the messages, and also doesn't define a particular model for determining where a message sequence starts or ends.

Bármely feladó létrehozhat egy munkamenetet, amikor üzeneteket küld egy témakörbe vagy várólistába úgy, hogy a munkamenet-azonosító tulajdonságot egy olyan alkalmazás által definiált azonosítóra állítja be, amely egyedi a munkamenetben.Any sender can create a session when submitting messages into a topic or queue by setting the session ID property to some application-defined identifier that is unique to the session. Az AMQP 1,0 protokoll szintjén ez az érték a Group-ID tulajdonságra van leképezve.At the AMQP 1.0 protocol level, this value maps to the group-id property.

A munkamenet-kompatibilis várólistákon vagy előfizetéseken a munkamenetek akkor jönnek létre, ha legalább egy üzenet van a munkamenet-AZONOSÍTÓval.On session-aware queues or subscriptions, sessions come into existence when there's at least one message with the session ID. Ha a munkamenet már létezik, nincs definiálva idő vagy API a munkamenet lejáratának vagy eltűnésének idejére.Once a session exists, there's no defined time or API for when the session expires or disappears. Elméletileg egy üzenet érkezik egy adott munkamenethez, a következő üzenet egy évben, és ha a munkamenet-azonosító megegyezik, a munkamenet megegyezik a Service Bus perspektívával.Theoretically, a message can be received for a session today, the next message in a year's time, and if the session ID matches, the session is the same from the Service Bus perspective.

Az alkalmazások jellemzően azonban egyértelmű fogalmat mutatnak arról, hogy hol kezdődnek és végződik a kapcsolódó üzenetek halmaza.Typically, however, an application has a clear notion of where a set of related messages starts and ends. Service Bus nem állít be konkrét szabályokat.Service Bus doesn't set any specific rules. Az alkalmazás például megadhatja a label (címke ) tulajdonságot az első üzenet elindításához, a köztes üzenetekhez a tartalomhoz, valamint az utolsó üzenet befejezéséhez.For example, your application could set the Label property for the first message to start, for intermediate messages to content, and for the last message to end. A tartalmi üzenetek relatív helyzete a Start Message sorszám származó aktuális sorszám -különbözetként számítható ki.The relative position of the content messages can be computed as the current message SequenceNumber delta from the start message SequenceNumber.

A szolgáltatás engedélyezéséhez állítsa be az requiresSession tulajdonságot a várólistán vagy az előfizetésen a Azure Resource Manageron keresztül, vagy állítsa be a jelölőt a portálon.You enable the feature by setting the requiresSession property on the queue or subscription via Azure Resource Manager, or by setting the flag in the portal. A kapcsolódó API-műveletek használatának megkísérlése előtt szükség van rá.It's required before you attempt to use the related API operations.

A portálon engedélyezheti a munkameneteket, miközben az alábbi példákban látható módon létrehoz egy entitást (Üzenetsor vagy előfizetés).In the portal, you can enable sessions while creating an entity (queue or subscription) as shown in the following examples.

Munkamenet engedélyezése a várólista létrehozásának időpontjában

Munkamenet engedélyezése az előfizetés létrehozásának időpontjában

Fontos

Ha a munkamenetek engedélyezve vannak egy várólistán vagy előfizetésen, az ügyfélalkalmazások többé nem küldhetnek és fogadhatnak rendszeres üzeneteket.When Sessions are enabled on a queue or a subscription, the client applications can no longer send/receive regular messages. Minden üzenetet el kell juttatni a munkamenet részeként (a munkamenet-azonosító beállításával), és a fogadást a munkamenet elfogadásával.All messages must be sent as part of a session (by setting the session id) and received by accepting the session.

A munkamenetek API-jai léteznek a várólista-és előfizetési ügyfeleken.The APIs for sessions exist on queue and subscription clients. Van egy kötelező modell, amely a munkamenetek és üzenetek fogadását vezérli, valamint egy kezelő-alapú modellt, amely elrejti a fogadási hurok kezelésének bonyolultságát.There's an imperative model that controls when sessions and messages are received, and a handler-based model that hides the complexity of managing the receive loop.

A példákat a következő lépések szakaszban található hivatkozásokra kattintva végezheti el.For samples, use links in the Next steps section.

Munkamenet-funkciókSession features

A munkamenetek egyidejű, egymással párhuzamosan megjelenő üzeneteket biztosítanak a megrendelt kézbesítés megőrzése és garantálása mellett.Sessions provide concurrent de-multiplexing of interleaved message streams while preserving and guaranteeing ordered delivery.

Egy diagram, amely azt mutatja, hogy a munkamenetek szolgáltatás hogyan őrzi meg a rendezett kézbesítést.

A munkamenet-fogadót egy-munkamenetet elfogadó ügyfél hozza létre.A session receiver is created by a client accepting a session. Ha a munkamenetet elfogadják és egy ügyfél tartja, az ügyfél kizárólagos zárolást tart az adott munkamenet munkamenet-azonosítójával rendelkező összes üzenetben a várólistán vagy az előfizetésen belül.When the session is accepted and held by a client, the client holds an exclusive lock on all messages with that session's session ID in the queue or subscription. Emellett a munkamenet-azonosítóval rendelkező összes üzenet kizárólagos zárolását is tartalmazza, amely később érkezik.It will also hold exclusive locks on all messages with the session ID that will arrive later.

A zárolás akkor jelenik meg, ha meghívja a lezárt kapcsolódó metódusokat a fogadón, vagy amikor lejár a zárolás.The lock is released when you call the close related methods on the receiver or when the lock expires. A fogadó módszerekkel megújíthatja a zárolásokat is.There are methods on the receiver to renew the locks as well. Ehelyett használhatja az automatikus zárolás megújítása funkciót, ahol megadhatja azt az időtartamot, ameddig szeretné megőrizni a zárolást.Instead, you can use the automatic lock renewal feature where you can specify the time duration for which you want to keep getting the lock renewed. 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 le kell zárnia a munkamenetet, amint már nincs rá szüksége, és/vagy nem vár semmilyen további üzenetet.The session lock should be treated like an exclusive lock on a file, meaning that the application should close the session as soon as it no longer needs it and/or doesn't expect any further messages.

Ha több párhuzamos fogadó is lekéri a várólistáról, az adott munkamenethez tartozó üzeneteket a rendszer az adott munkamenethez tartozó zárolást betöltő adott fogadónak küldi el.When multiple concurrent receivers pull from the queue, the messages belonging to a particular session are dispatched to the specific receiver that currently holds the lock for that session. Ezzel a művelettel az egyik várólistában vagy előfizetésben lévő, egymástól elválasztott üzenetek streamje tiszta módon, különböző fogadók számára érhető el, és ezek a fogadók különböző ügyfélszámítógépeken is élhetnek, mivel a zárolási felügyelet Service Buson belül történik.With that operation, an interleaved message stream in one queue or subscription is cleanly de-multiplexed to different receivers and those receivers can also live on different client machines, since the lock management happens service-side, inside Service Bus.

Az előző ábrán három egyidejű munkamenet-fogadó látható.The previous illustration shows three concurrent session receivers. Az egyik munkamenetben a SessionId = 4 nem rendelkezik aktív, tulajdonosi ügyféllel, ami azt jelenti, hogy az adott munkamenetből nem érkeznek üzenetek.One Session with SessionId = 4 has no active, owning client, which means that no messages are delivered from this specific session. A munkamenetek számos módon működnek, mint például az alárendelt üzenetsor.A session acts in many ways like a sub queue.

A munkamenet-fogadó által tárolt munkamenet-zárolás egy esernyő a betekintési zárolási mód által használt üzenetek zárolásához.The session lock held by the session receiver is an umbrella for the message locks used by the peek-lock settlement mode. Egy munkamenetben csak egy fogadó rendelkezhet zárolással.Only one receiver can have a lock on a session. Előfordulhat, hogy egy fogadó több fedélzeti üzenetet tartalmaz, de az üzenetek sorrendben érkeznek.A receiver may have many in-flight messages, but the messages will be received in order. Az üzenet elhagyása azt eredményezi, hogy ugyanazt az üzenetet ismét a következő fogadási művelettel kézbesíti a rendszer.Abandoning a message causes the same message to be served again with the next receive operation.

Üzenet-munkamenet állapotaMessage session state

Ha a munkafolyamatokat nagy léptékű, magas rendelkezésre állású felhőalapú rendszerekben dolgozzák fel, akkor az adott munkamenethez társított munkafolyamat-kezelőnek képesnek kell lennie a váratlan hibák helyreállítására, és a részben befejezett munkát egy másik folyamaton vagy gépen végezheti el, ahol a munka megkezdődött.When workflows are processed in high-scale, high-availability cloud systems, the workflow handler associated with a particular session must be able to recover from unexpected failures and can resume partially completed work on a different process or machine from where the work began.

A munkamenet-állapot lehetőség lehetővé teszi egy üzenet-munkamenet alkalmazás által meghatározott megjegyzésének megadását a közvetítőn belül, így az adott munkamenethez viszonyított rögzített feldolgozási állapot azonnal elérhetővé válik, amikor egy új processzor szerzi be a munkamenetet.The session state facility enables an application-defined annotation of a message session inside the broker, so that the recorded processing state relative to that session becomes instantly available when the session is acquired by a new processor.

Az Service Bus perspektívából az üzenet-munkamenet állapota egy átlátszatlan bináris objektum, amely egy üzenet méretének tárolására képes, amely 256 KB Service Bus standard és 1 MB a Service Bus Premium esetében.From the Service Bus perspective, the message session state is an opaque binary object that can hold data of the size of one message, which is 256 KB for Service Bus Standard, and 1 MB for Service Bus Premium. A munkamenet-állapothoz viszonyított feldolgozási állapot a munkamenet-állapotban tartható, vagy a munkamenet-állapot olyan tárolási helyre vagy adatbázis-rekordra mutathat, amely az ilyen adatokat tárolja.The processing state relative to a session can be held inside the session state, or the session state can point to some storage location or database record that holds such information.

A munkamenet-állapot, a SetState és a GetState kezelésének módszerei a munkamenet-fogadó objektumon találhatók.The methods for managing session state, SetState and GetState, can be found on the session receiver object. Egy olyan munkamenet, amely korábban nem tartalmazott munkamenet-állapotot, null hivatkozást ad vissza a GetState.A session that had previously no session state returns a null reference for GetState. A korábban beállított munkamenet-állapot törölhető úgy, hogy null értéket továbbít a fogadó SetState metódusának.The previously set session state can be cleared by passing null to the SetState method on the receiver.

A munkamenet-állapot addig marad mindaddig, amíg nincs törölve ( Null értékre tér vissza), még akkor is, ha a munkamenetben lévő összes üzenetet felhasználják.Session state remains as long as it isn't cleared up (returning null), even if all messages in a session are consumed.

Egy várólistában vagy előfizetésben tárolt munkamenet-állapot az entitás tárolási kvótája felé mutat.The session state held in a queue or in a subscription counts towards that entity's storage quota. Ha az alkalmazás egy munkamenettel fejeződött be, ezért ajánlott az alkalmazás számára megőrizni a megőrzött állapotot, hogy elkerülje a külső felügyeleti költségeket.When the application is finished with a session, it is therefore recommended for the application to clean up its retained state to avoid external management cost.

A kézbesítések számának következményeiImpact of delivery count

Az üzenetek kézbesítési számának a munkamenetek kontextusában való meghatározása a munkamenetek hiányában a definíciótól némileg eltér.The definition of delivery count per message in the context of sessions varies slightly from the definition in the absence of sessions. Itt látható egy táblázat, amely összegzi a kézbesítések számának növelését.Here is a table summarizing when the delivery count is incremented.

EsetScenario Az üzenet kézbesítési száma nőIs the message's delivery count incremented
A munkamenet el van fogadva, de a munkamenet zárolása lejár (időtúllépés miatt)Session is accepted, but the session lock expires (due to timeout) YesYes
A munkamenet elfogadása megtörtént, a munkamenetben lévő üzenetek nem lesznek végrehajtva (még akkor is, ha zárolva vannak), és a munkamenet be van zárva.Session is accepted, the messages within the session aren't completed (even if they are locked), and the session is closed NoNo
A munkamenet elfogadva, az üzenetek befejeződtek, majd a munkamenet explicit módon be van zárvaSession is accepted, messages are completed, and then the session is explicitly closed N/A (ez a standard folyamat.N/A (It's the standard flow. Itt az üzenetek el lesznek távolítva a munkamenetből)Here messages are removed from the session)

Kérelem – válasz mintaRequest-response pattern

A kérelem-válasz minta egy jól bevált integrációs minta, amely lehetővé teszi, hogy a küldő alkalmazás küldjön egy kérést, és módot biztosít arra, hogy a fogadó helyesen küldjön vissza választ a küldő alkalmazásnak.The request-reply pattern is a well-established integration pattern that enables the sender application to send a request and provides a way for the receiver to correctly send a response back to the sender application. Ez a minta általában egy rövid élettartamú várólistára vagy témakörre van szüksége ahhoz, hogy az alkalmazás válaszokat küldjön.This pattern typically needs a short-lived queue or topic for the application to send responses to. Ebben az esetben a munkamenetek egy egyszerű alternatív megoldást biztosítanak, amely hasonló szemantikai megoldásokkal rendelkezik.In this scenario, sessions provide a simple alternative solution with comparable semantics.

Több alkalmazás is elküldheti kérelmeit egyetlen kérelem-várólistába, egy adott fejléc-paraméterrel, amely egyedileg azonosítja a küldő alkalmazást.Multiple applications can send their requests to a single request queue, with a specific header parameter set to uniquely identify the sender application. A fogadó alkalmazás képes feldolgozni a várólistára érkező kéréseket, és elküldi a válaszokat a munkamenet-kompatibilis várólistán, a munkamenet-azonosítót pedig arra a egyedi azonosítóra állítja, amelyet a küldő a kérelem üzenetében küldött.The receiver application can process the requests coming in the queue and send replies on the session enabled queue, setting the session ID to the unique identifier the sender had sent on the request message. A kérést elküldő alkalmazás az adott munkamenet-AZONOSÍTÓra vonatkozó üzeneteket fogadhat, és helyesen dolgozza fel a válaszokat.The application that sent the request can then receive messages on the specific session ID and correctly process the replies.

Megjegyzés

A kezdeti kérelmeket küldő alkalmazásnak ismernie kell a munkamenet-azonosítót, és annak használatával el kell fogadnia a munkamenetet, hogy az a munkamenet, amelyen a válasz vár, zárolva legyen.The application that sends the initial requests should know about the session ID and use it to accept the session so that the session on which it is expecting the response is locked. Érdemes olyan GUID-t használni, amely egyedileg azonosítja az alkalmazás példányát munkamenet-azonosítóként. A várólista munkamenet-fogadóján nincs megadva munkamenet-kezelő vagy időtúllépés, így biztosítható, hogy a válaszok zárolva legyenek, és az adott fogadók feldolgozzák azokat.It's a good idea to use a GUID that uniquely identifies the instance of the application as a session id. There should be no session handler or a timeout specified on the session receiver for the queue to ensure that responses are available to be locked and processed by specific receivers.

Következő lépésekNext steps

Service Bus üzenetkezeléssel kapcsolatos további tudnivalókért tekintse meg a Service Bus várólisták, témakörök és előfizetésekcímű témakört.To learn more about Service Bus messaging, see Service Bus queues, topics, and subscriptions.