Szekvenciális konvoj mintaSequential Convoy pattern

A kapcsolódó üzeneteket meghatározott sorrendben dolgozhatja fel, más üzenetcsoportok feldolgozásának akadályozása nélkül.Process a set of related messages in a defined order, without blocking processing of other groups of messages.

Kontextus és problémaContext and problem

Az alkalmazásoknak gyakran kell feldolgozniuk az üzenetek egy sorát a megérkezésük sorrendjében, miközben továbbra is képesek lesznek felskálázásra a megnövekedett terhelés kezelésére.Applications often need to process a sequence of messages in the order they arrive, while still being able to scale out to handle increased load. Elosztott architektúrában az üzenetek sorrendben történő feldolgozása nem egyértelmű, mert a dolgozók egymástól függetlenül és gyakran lehívhatják az üzeneteket egymástól függetlenül, versengő fogyasztói mintahasználatával.In a distributed architecture, processing these messages in order is not straightforward, because the workers can scale independently and often pull messages independently, using a Competing Consumers pattern.

Egy megrendelés-követési rendszer például a rendeléseket tartalmazó főkönyvet és a megfelelő műveleteket fogadja a rendeléseken.For example, an order tracking system receives a ledger containing orders and the relevant operations on those orders. Ezek a műveletek megrendelést hozhatnak létre, tranzakciót adhatnak hozzá a rendeléshez, módosíthatnak egy korábbi tranzakciót, vagy törölhetnek egy rendelést.These operations could be to create an order, add a transaction to the order, modify a past transaction, or delete an order. Ebben a rendszeren a műveleteket a rendszer első alkalommal, csak a sorrend szintjén kell végrehajtania.In this system, operations must be performed in a first-in-first-out (FIFO) manner, but only at the order level. A kezdeti várólista azonban olyan főkönyvet kap, amely számos megrendeléshez tartozó tranzakciót tartalmaz, és ez összekapcsolható lehet.However, the initial queue receives a ledger containing transactions for many orders, which may be interleaved.

MegoldásSolution

A kapcsolódó üzeneteket leküldheti kategóriákba a üzenetsor-kezelő rendszeren belül, és a várólista-figyelők zárolását és lekérését csak egyetlen kategóriából, egyszerre egy üzenetből végezheti el.Push related messages into categories within the queuing system, and have the queue listeners lock and pull only from one category, one message at a time.

Az általános szekvenciális konvoj mintája a következőképpen néz ki:Here's what the general Sequential Convoy pattern looks like:

Szekvenciális konvoj mintázatának ábrája

A várólistában a különböző kategóriákba tartozó üzenetek eltérhetnek az alábbi ábrán látható módon:In the queue, messages for different categories may be interleaved, as shown in the following diagram:

A felhagyott üzeneteket bemutató diagram

Problémák és megfontolandó szempontokIssues and considerations

A minta megvalósítása során az alábbi pontokat vegye figyelembe:Consider the following points when deciding how to implement this pattern:

  • Kategória/méretezési egységCategory/scale unit. A bejövő üzeneteinek milyen tulajdonságait lehet kibővíteni?What property of your incoming messages can you scale out on? A sorrend követése forgatókönyvben ez a tulajdonság a megrendelés azonosítója.In the order tracking scenario, this property is the order ID.
  • Átviteli sebesség.Throughput. Mi a cél üzenetek átviteli sebessége?What is your target message throughput? Ha nagyon magas, előfordulhat, hogy újra meg kell fontolnia a FIFO-követelményeket.If it is very high, you may need to reconsider your FIFO requirements. Kikényszerítheti például a kezdő/záró üzenetet, az időpontot, majd a kötegelt feldolgozást?For example, can you enforce a start/end message, sort by time, then send a batch for processing?
  • Szolgáltatási képességek.Service capabilities. Lehetővé teszi, hogy az üzenetsor vagy a várólista kategóriáján belül az üzenetek egy időben történő feldolgozását engedélyezi?Does your choice of message bus allow for one-at-a-time processing of messages within a queue or category of a queue?
  • A kialakulás.Evolvability. Hogyan adja hozzá az üzenet új kategóriáját a rendszerhez?How will you add a new category of message to the system? Tegyük fel például, hogy a fent ismertetett Főkönyv-rendszer egy adott ügyfél.For example, suppose the ledger system described above is specific one customer. Ha új ügyfelet szeretne bevezetni, rendelkezhet olyan főkönyvi feldolgozókkal, amelyek ügyfél-azonosító alapján osztják el a munkát?If you needed to onboard a new customer, could you have a set of ledger processors that distribute work per customer ID?
  • Előfordulhat, hogy a felhasználók az üzenetek elküldésekor változó hálózati késés miatt nem megfelelő sorrendben kapnak üzenetet.It's possible that consumers might receive a message out of order, due to variable network latency when sending messages. A sorrend ellenőrzéséhez vegye fontolóra a sorozatszámok használatát.Consider using sequence numbers to verify ordering. A tranzakció utolsó üzenetében egy speciális "End of Sequence" jelző is szerepelhet.You might also include a special "end of sequence" flag in the last message of a transaction. Az adatfolyam-feldolgozási technológiák, például a Spark vagy a Azure Stream Analytics egy adott időintervallumon belül dolgozhatnak fel üzeneteket.Stream processing technologies such as Spark or Azure Stream Analytics can process messages in order within a time window.

Mikor érdemes ezt a mintát használni?When to use this pattern

Használja ezt a mintát, ha:Use this pattern when:

  • Vannak olyan üzenetei, amelyek sorrendben érkeznek, és ugyanabban a sorrendben kell feldolgozni őket.You have messages that arrive in order and must be processed in the same order.
  • A beérkező üzenetek a "kategorizálva" formában jelennek meg oly módon, hogy a kategória a rendszer méretezési egysége lesz.Arriving messages are or can be "categorized" in such a way that the category becomes a unit of scale for the system.

Lehetséges, hogy ez a minta nem alkalmas a következőhöz:This pattern might not be suitable for:

  • Rendkívül nagy átviteli sebességű forgatókönyvek (több millió üzenet/perc vagy másodperc), mivel a FIFO-követelmény korlátozza a rendszer által elvégezhető skálázást.Extremely high throughput scenarios (millions of messages/minute or second), as the FIFO requirement limits the scaling that can be done by the system.

PéldaExample

Az Azure-ban ez a minta Azure Service Bus üzenet- munkamenetekhasználatával valósítható meg.On Azure, this pattern can be implemented using Azure Service Bus message sessions. A felhasználók számára Logic Appst használhat az Service Bus betekintés-Lock összekötővel , vagy Azure Functions a Service Bus triggerrel.For the consumers, you can use either Logic Apps with the Service Bus peek-lock connector or Azure Functions with the Service Bus trigger.

Az előző sorrend-követési példában az egyes főkönyvi üzeneteket a kapott sorrendben dolgozza fel, és minden tranzakciót egy másik várólistára kell küldenie, ahol a kategória a rendelés AZONOSÍTÓra van beállítva.For the previous order-tracking example, process each ledger message in the order it's received, and send each transaction to another queue where the category is set to the order ID. Ebben az esetben a tranzakció soha nem fog több megrendelést kiterjedni, így a felhasználók a kategórián belül párhuzamosan, de FIFO-ban dolgozzák fel az egyes kategóriákat.A transaction will never span multiple orders in this scenario, so consumers process each category in parallel but FIFO within the category.

A párkány processzora kikerüli az üzeneteket az első várólistán lévő üzenetek tartalmának letételével:The ledge processor fan outs the messages by de-batching the content of each message in the first queue:

Egy főkönyv-várólistával rendelkező szekvenciális konvoj mintáját bemutató ábra

A Főkönyv processzora a következőket végzi el:The ledger processor takes care of:

  1. A Főkönyv egy tranzakciójának bejárása egyszerre.Walking the ledger one transaction at a time.
  2. Az üzenet munkamenet-AZONOSÍTÓjának beállítása a megrendelési AZONOSÍTÓnak megfelelően.Setting the session ID of the message to match the order ID.
  3. Az egyes főkönyvi tranzakciók küldése másodlagos várólistára a munkamenet-AZONOSÍTÓval, amely a rendelési AZONOSÍTÓra van beállítva.Sending each ledger transaction to a secondary queue with the session ID set to the order ID.

A felhasználók figyelik a másodlagos várólistát, ahol az összes olyan üzenetet feldolgozzák, amely egyező sorrend - azonosítókkal van ellátva a várólistából.The consumers listen to the secondary queue where they process all messages with matching order IDs in order from the queue. A felhasználók betekintés-zárolási módot használnak.Consumers use peek-lock mode.

A skálázhatóság szempontjából a Főkönyv-várólista elsődleges szűk keresztmetszet.When considering scalability, the ledger queue is a primary bottleneck. A főkönyvbe feladott különböző tranzakciók ugyanarra a megrendelési AZONOSÍTÓra hivatkozhatnak.Different transactions posted to the ledger could reference the same order ID. Az üzenetek azonban a főkönyvnek a kiszolgáló nélküli környezetben lévő megrendelések száma után is kihasználhatók.However, messages can fan out after the ledger to the number of orders in a serverless environment.

Következő lépésekNext steps

Az alábbi információk segíthetnek a minta megvalósításakor:The following information may be relevant when implementing this pattern: