Üzenetsor-alapú terheléskiegyenlítési mintaQueue-Based Load Leveling pattern

Használjon olyan várólistát, amely pufferként funkcionál egy feladat és egy olyan szolgáltatás között, amely az időszakos nagy terhelések elvégzéséhez vezethet, ami miatt a szolgáltatás meghibásodik, vagy a feladat időtúllépést okoz. Ez segít csökkenteni az igény szerinti csúcsok hatását a rendelkezésre állásra, valamint a feladatra és a szolgáltatásra való reagálásra is.Use a queue that acts as a buffer between a task and a service it invokes in order to smooth intermittent heavy loads that can cause the service to fail or the task to time out. This can help to minimize the impact of peaks in demand on availability and responsiveness for both the task and the service.

Kontextus és problémaContext and problem

A felhőben számos megoldás futtat szolgáltatásokat meghívó feladatokat.Many solutions in the cloud involve running tasks that invoke services. Ebben a környezetben ha egy szolgáltatás időszakos nagy terheléseknek van kitéve, az a teljesítménnyel és a megbízhatósággal kapcsolatos problémákat okozhat.In this environment, if a service is subjected to intermittent heavy loads, it can cause performance or reliability issues.

A szolgáltatások ugyanazon megoldás részei lehetnek, mint az azt használó feladatok, vagy külső szolgáltatások lehetnek, amelyek hozzáférést nyújtanak a gyakran használt erőforrásokhoz, például egy gyorsítótárhoz vagy egy társzolgáltatáshoz.A service could be part of the same solution as the tasks that use it, or it could be a third-party service providing access to frequently used resources such as a cache or a storage service. Ha több egyidejűleg futó feladat ugyanazt a szolgáltatást használja, egy adott időpillanatban nehéz lehet megjósolni a szolgáltatás felé irányuló kérések mennyiségét.If the same service is used by a number of tasks running concurrently, it can be difficult to predict the volume of requests to the service at any time.

A szolgáltatásban időszakonként csúcsok jelentkezhetnek az igényekben, amelyek túlterhelést okozhatnak, így a szolgáltatás nem tud időben válaszolni a kérésekre.A service might experience peaks in demand that cause it to overload and be unable to respond to requests in a timely manner. A szolgáltatások számos egyidejű kéréssel való elárasztása is a szolgáltatás meghiúsulását eredményezheti, ha nem tudja kezelni a kérések okozta versenyt.Flooding a service with a large number of concurrent requests can also result in the service failing if it's unable to handle the contention these requests cause.

MegoldásSolution

Bontsa újra a megoldást, és vezessen be egy üzenetsort a feladat és a szolgáltatás között.Refactor the solution and introduce a queue between the task and the service. A feladatok és a szolgáltatás aszinkron módon fut.The task and the service run asynchronously. A feladat közzéteszi a szolgáltatás számára szükséges adatokat tartalmazó üzenetet egy üzenetsorba.The task posts a message containing the data required by the service to a queue. Az üzenetsor pufferként működik, addig tárolja az üzenetet, amíg azt a szolgáltatás le nem kéri.The queue acts as a buffer, storing the message until it's retrieved by the service. A szolgáltatás lekéri az üzeneteket az üzenetsorból, és feldolgozza őket.The service retrieves the messages from the queue and processes them. Egy adott üzenetsorban számos különféle feladatból származó kérés adható át a szolgáltatásnak, amelyek rendkívül változó sebességgel jöhetnek létre.Requests from a number of tasks, which can be generated at a highly variable rate, can be passed to the service through the same message queue. Ez az ábra egy szolgáltatás terhelésének kiegyenlítésére szolgáló üzenetsor használatát mutatja be.This figure shows using a queue to level the load on a service.

1. ábra – Szolgáltatás terhelésének kiegyenlítésére szolgáló üzenetsor használata

Az üzenetsor leválasztja a feladatokat a szolgáltatásról, és a szolgáltatás a saját tempójában tudja kezelni az üzeneteket az egyidejű feladatoktól érkező kérések mennyiségétől függetlenül.The queue decouples the tasks from the service, and the service can handle the messages at its own pace regardless of the volume of requests from concurrent tasks. Emellett a feladatok nem késnek, ha a szolgáltatás nem érhető el, amikor üzenetet tesznek közzé az üzenetsorba.Additionally, there's no delay to a task if the service isn't available at the time it posts a message to the queue.

Ez a minta az alábbi előnyökkel jár:This pattern provides the following benefits:

  • Maximálisra növeli a rendelkezésre állást, mert a szolgáltatásokban felmerülő késések nincsenek azonnali és közvetlen hatással az alkalmazásra, amely akkor is folytathatja az üzenetek üzenetsorba való közzétételét, amikor a szolgáltatás nem érhető el vagy épp nem dolgoz fel üzeneteket.It can help to maximize availability because delays arising in services won't have an immediate and direct impact on the application, which can continue to post messages to the queue even when the service isn't available or isn't currently processing messages.

  • Segít a skálázhatóság maximalizálásában, mert az üzenetsorok száma és a szolgáltatások száma is módosítható igény szerint.It can help to maximize scalability because both the number of queues and the number of services can be varied to meet demand.

  • A segítségével kézben tarthatók a költségek, mert az üzembe helyezett szolgáltatáspéldányok számának csak az átlagos terheléshez kell elegendőnek lennie, a csúcsterheléshez nem.It can help to control costs because the number of service instances deployed only have to be adequate to meet average load rather than the peak load.

    Egyes szolgáltatások szabályozást alkalmaznak, amikor az igények elérnek egy olyan küszöbértéket, amelyet követően a rendszer meghibásodhat.Some services implement throttling when demand reaches a threshold beyond which the system could fail. A szabályozás csökkentheti az elérhető funkciókat.Throttling can reduce the functionality available. Ezekkel a szolgáltatásokkal terheléskiegyenlítést valósíthat meg annak érdekében, hogy ne érje el ezt a küszöbértéket.You can implement load leveling with these services to ensure that this threshold isn't reached.

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:

  • Olyan alkalmazáslogikát kell megvalósítani, amely szabályozza a szolgáltatások általi üzenetkezelés sebességét, hogy a cél erőforrás ne legyen túlterhelve.It's necessary to implement application logic that controls the rate at which services handle messages to avoid overwhelming the target resource. Ne adjon át igénybevételi csúcsokat a rendszer más részeinek.Avoid passing spikes in demand to the next stage of the system. Tesztelje a terhelés alatti rendszert annak ellenőrzéséhez, hogy az biztosítja-e a megfelelő terheléskiegyenlítést, és ennek megfelelően módosítsa az üzeneteket kezelő üzenetsorok és szolgáltatáspéldányok számát.Test the system under load to ensure that it provides the required leveling, and adjust the number of queues and the number of service instances that handle messages to achieve this.
  • Az üzenetsorok egyirányú kommunikációs mechanizmusok.Message queues are a one-way communication mechanism. Ha egy feladat válaszra vár egy szolgáltatástól, előfordulhat, hogy olyan mechanizmust kell implementálni, amellyel a szolgáltatás választ tud küldeni.If a task expects a reply from a service, it might be necessary to implement a mechanism that the service can use to send a response. További információkért lásd az aszinkron üzenetkezelés ismertetését.For more information, see the Asynchronous Messaging Primer.
  • Legyen körültekintő, ha az üzenetsor kéréseit figyelő szolgáltatásokra automatikus skálázást alkalmaz.Be careful if you apply autoscaling to services that are listening for requests on the queue. Ez megnövekedett versenyt eredményezhet az ezen szolgáltatások által megosztott erőforrásokért, és csökkenti az üzenetsor hatékonyságát a terhelés kiegyenlítése terén.This can result in increased contention for any resources that these services share and diminish the effectiveness of using the queue to level the load.

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

Ez a minta olyan alkalmazásokhoz hasznos, amelyek gyakran túlterhelt szolgáltatásokat használnak.This pattern is useful to any application that uses services that are subject to overloading.

Ez a minta nem használható jól, ha az alkalmazás minimális késéssel vár választ a szolgáltatástól.This pattern isn't useful if the application expects a response from the service with minimal latency.

PéldaExample

Egy webalkalmazás egy külső adattárba ír egy adatot.A web app writes data to an external data store. Ha a webalkalmazás nagy számú példánya fut egyidejűleg, előfordulhat, hogy az adattár nem tud elég gyorsan válaszolni a kérelmekre, így a kérések időtúllépést okoznak, szabályozható vagy egyéb módon meghiúsulnak.If a large number of instances of the web app run concurrently, the data store might be unable to respond to requests quickly enough, causing requests to time out, be throttled, or otherwise fail. Az alábbi ábrán egy olyan adattár látható, amely túlterheli az alkalmazások példányainak nagy számú egyidejű kérelmét.The following diagram shows a data store being overwhelmed by a large number of concurrent requests from instances of an application.

2. ábra – egy webalkalmazás példányai által nagy számú egyidejű kérés által túlterhelt szolgáltatás

Ennek megoldásához egy üzenetsor használatával állíthatja be az alkalmazás példányai és az adattár közötti terhelést.To resolve this, you can use a queue to level the load between the application instances and the data store. Egy Azure Functions alkalmazás beolvassa az üzeneteket a várólistából, és elvégzi az olvasási/írási kéréseket az adattárba.An Azure Functions app reads the messages from the queue and performs the read/write requests to the data store. A Function alkalmazásban az alkalmazás logikája szabályozhatja, hogy a rendszer milyen sebességgel továbbítson kérelmeket az adattárba, hogy megakadályozza a tároló túlterhelését.The application logic in the function app can control the rate at which it passes requests to the data store, to prevent the store from being overwhelmed. (Ellenkező esetben a Function alkalmazás csak újra bevezeti ugyanazt a problémát a háttér végén.)(Otherwise the function app will just re-introduce the same problem at the back end.)

3. ábra – az üzenetsor és a Function alkalmazás használata a terhelés szintjének elvégzéséhez

Az alábbi minták és útmutatók szintén hasznosak lehetnek a minta megvalósításakor:The following patterns and guidance might also be relevant when implementing this pattern:

  • Az aszinkron üzenetkezelés ismertetése.Asynchronous Messaging Primer. Az üzenetsorok eredendően aszinkron típusúak.Message queues are inherently asynchronous. Előfordulhat, hogy egy feladatban újra kell tervezni az alkalmazáslogikát a szolgáltatással való közvetlen kommunikációról üzenetsor használatára.It might be necessary to redesign the application logic in a task if it's adapted from communicating directly with a service to using a message queue. Hasonlóképpen szükség lehet a szolgáltatások újrabontására, hogy kéréseket fogadjanak el egy üzenetsortól.Similarly, it might be necessary to refactor a service to accept requests from a message queue. Másik lehetőségként meg lehet valósítani egy proxyszolgáltatást a példában bemutatott módon.Alternatively, it might be possible to implement a proxy service, as described in the example.

  • Versengő fogyasztók mintája.Competing Consumers pattern. Egy szolgáltatás több példánya is futtatható lehet, amelyek mindegyike üzenetfogyasztóként viselkedik a terheléskiegyenlítő üzenetsorból.It might be possible to run multiple instances of a service, each acting as a message consumer from the load-leveling queue. Ezzel a módszerrel beállíthatja az üzenetek szolgáltatásból való fogadásának és a szolgáltatásba küldésének sebességét.You can use this approach to adjust the rate at which messages are received and passed to a service.

  • Szabályozási minta.Throttling pattern. A szolgáltatás általi szabályozás megvalósításának egyszerű módja az üzenetsoralapú terheléskiegyenlítés és a szolgáltatásokra érkező összes kérés átirányítása egy üzenetsorba.A simple way to implement throttling with a service is to use queue-based load leveling and route all requests to a service through a message queue. A szolgáltatás olyan sebességgel dolgozza fel a kéréseket, amely biztosítja, hogy a szolgáltatás számára szükséges erőforrások ne merüljenek ki, és hogy csökkenjen az esetleges verseny mennyisége.The service can process requests at a rate that ensures that resources required by the service aren't exhausted, and to reduce the amount of contention that could occur.

  • Válasszon az Azure Messaging Services közül.Choose between Azure messaging services. Információkat biztosít az üzenetkezelési és sorkezelési mechanizmusok kiválasztásáról Azure-alkalmazásokban.Information about choosing a messaging and queuing mechanism in Azure applications.

  • A méretezhetőség javítása egy Azure-webalkalmazásban.Improve scalability in an Azure web application. Ez a hivatkozási architektúra üzenetsor-alapú terheléselosztást tartalmaz az architektúra részeként.This reference architecture includes queue-based load leveling as part of the architecture.