Sebességkorlátozó minta

Azure Service Bus

Azure Queue Storage

Azure-eseményközpontok

Számos szolgáltatás szabályozási mintát használ az általuk felhasznált erőforrások szabályozására, ami korlátozza a más alkalmazások vagy szolgáltatások hozzáférésének sebességét. A sebességkorlátozási mintával elkerülheti vagy minimalizálhatja a szabályozási korlátokhoz kapcsolódó szabályozási hibákat, és pontosabban előrejelezheti az átviteli sebességet.

A sebességkorlátozó minta sok esetben megfelelő, de különösen hasznos nagy léptékű, ismétlődő automatizált feladatokhoz, például kötegelt feldolgozáshoz.

Kontextus és probléma

Ha nagy számú műveletet hajt végre szabályozott szolgáltatással, az nagyobb forgalmat és átviteli sebességet eredményezhet, mivel az elutasított kéréseket mindkét esetben nyomon kell követnie, majd újra meg kell próbálkoznia. A műveletek számának növekedésével a szabályozási korlát több adatátadást is igényelhet, ami nagyobb teljesítményhatást eredményez.

Példaként tekintse meg a következő naiv újrapróbálkozást az adatok Azure Cosmos DB-be való betöltéséhez szükséges hibafolyamaton:

1. Az alkalmazásnak 10 000 rekordot kell beszúrnia az Azure Cosmos DB-be. Minden rekord 10 kérelemegységbe (kérelemegységbe) kerül, ami összesen 100 000 kérelemegységet igényel a feladat elvégzéséhez.
2. Az Azure Cosmos DB-példány 20 000 kiosztott kérelemegység-kapacitással rendelkezik.
3. Mind a 10 000 rekordot elküldi az Azure Cosmos DB-nek. A rendszer 2000 rekordot írt sikeresen, és 8000 rekordot elutasított.
4. A fennmaradó 8000 rekordot elküldi az Azure Cosmos DB-nek. A rendszer 2000 rekordot ír sikeresen, és 6000 rekordot elutasít.
5. A fennmaradó 6000 rekordot elküldheti az Azure Cosmos DB-nek. A rendszer 2000 rekordot írt sikeresen, és 4000 rekordot elutasított.
6. A fennmaradó 4000 rekordot elküldheti az Azure Cosmos DB-nek. A rendszer 2000 rekordot írt sikeresen, és 2000 rekordot elutasított.
7. A fennmaradó 2000 rekordot elküldi az Azure Cosmos DB-nek. Minden sikeresen meg van írva.

A betöltési feladat sikeresen befejeződött, de csak azután, hogy 30 000 rekordot küldött az Azure Cosmos DB-nek, annak ellenére, hogy a teljes adatkészlet csak 10 000 rekordból állt.

A fenti példában további tényezőket is figyelembe kell venni:

• A nagy számú hiba további munkát is eredményezhet ezeknek a hibáknak a naplózásához és az eredményként kapott naplóadatok feldolgozásához. Ez a naiv megközelítés 20 000 hibát fog kezelni, és a hibák naplózása feldolgozási, memória- vagy tárolási erőforrásköltséget eredményezhet.
• Nem ismerve a betöltési szolgáltatás szabályozási korlátait, a naiv megközelítésnek nincs módja arra, hogy elvárásokat állítson be arra vonatkozóan, hogy mennyi ideig tart az adatfeldolgozás. A sebességkorlátozás lehetővé teszi a betöltéshez szükséges idő kiszámítását.

Megoldás

A sebességkorlátozás csökkentheti a forgalmat, és javíthatja az átviteli sebességet azáltal, hogy csökkenti a szolgáltatásnak küldött rekordok számát egy adott időszakban.

Egy szolgáltatás idővel különböző metrikák alapján szabályozhat, például:

• A műveletek száma (például 20 kérelem másodpercenként).
• Az adatok mennyisége (például 2 GiB percenként).
• A műveletek relatív költsége (például 20 000 kérelemegység másodpercenként).

A szabályozáshoz használt metrikától függetlenül a sebességkorlátozó implementáció magában foglalja a szolgáltatásnak adott időszakban küldött műveletek számának és/vagy méretének szabályozását, optimalizálva a szolgáltatás használatát, miközben nem lépi túl a szabályozási kapacitást.

Azokban az esetekben, amikor az API-k gyorsabban tudják kezelni a kéréseket, mint bármely szabályozott betöltési szolgáltatás, kezelnie kell, hogy milyen gyorsan használhatja a szolgáltatást. A szabályozás azonban csak adatsebesség-eltéréssel kapcsolatos problémaként kezelhető, és a betöltési kérelmek pufferelése, amíg a szabályozott szolgáltatás felzárkózni nem tud, kockázatos. Ha az alkalmazás összeomlik ebben a forgatókönyvben, a pufferelt adatok bármelyikét elveszítheti.

A kockázat elkerülése érdekében érdemes lehet olyan tartós üzenetkezelő rendszerbe küldeni a rekordokat, amely képes kezelni a teljes betöltési arányt. (Az olyan szolgáltatások, mint az Azure Event Hubs, másodpercenként több millió műveletet képesek kezelni). Ezután egy vagy több feladatprocesszor használatával beolvashatja a rekordokat az üzenetkezelő rendszerből a szabályozott szolgáltatás korlátain belül eső szabályozott sebességgel. Ha rekordokat küld az üzenetkezelő rendszerbe, azzal belső memóriát takaríthat meg, ha csak az adott időintervallumban feldolgozható rekordokat törli.

Az Azure számos tartós üzenetkezelési szolgáltatást biztosít, amelyeket ezzel a mintával használhat, többek között a következőket:

• Azure Service Bus
• Azure Queue Storage
• Azure-eseményközpontok

Rekordok küldésekor a rekordok kiadásához használt időtartam részletesebb lehet, mint a szolgáltatás szabályozásának időtartama. A rendszerek gyakran beállítják a szabályozásokat az időbélyegek alapján, amelyek könnyen megérthetők és kezelhetők. A szolgáltatást futtató számítógép esetében azonban ezek az időkeretek nagyon hosszúak lehetnek ahhoz képest, hogy milyen gyorsan tudja feldolgozni az információkat. Előfordulhat például, hogy egy rendszer másodpercenként vagy percenként szabályoz, de a kód általában nanoszekundumok vagy ezredmásodpercek sorrendjében dolgozik.

Bár nem kötelező, gyakran ajánlott kisebb mennyiségű rekordot küldeni az átviteli sebesség javítása érdekében. Így ahelyett, hogy másodpercenként vagy percenként egyszer próbálná meg a kiadásra felszedni a dolgokat, részletesebb lehet annál, hogy az erőforrás-felhasználás (memória, CPU, hálózat stb.) egyenletesebb ütemben haladjon, megelőzve a kérések hirtelen kirobbanása miatti lehetséges szűk keresztmetszeteket. Ha például egy szolgáltatás másodpercenként 100 műveletet tesz lehetővé, a sebességkorlátozó megvalósítása 200 ezredmásodpercenként 20 művelet kiadásával egyenlítheti ki a kérelmeket, ahogyan az az alábbi grafikonon látható.

Emellett néha több nem koordinált folyamat is szükséges a szabályozott szolgáltatások megosztásához. A sebességkorlátozás implementálásához ebben a forgatókönyvben logikailag particionálhatja a szolgáltatás kapacitását, majd elosztott kölcsönös kizárási rendszer használatával kezelheti az ezeken a partíciókon lévő kizárólagos zárolásokat. A koordinálatlan folyamatok ezután versenyezhetnek az ezeken a partíciókon lévő zárolásokért, amikor kapacitásra van szükségük. Minden olyan partícióhoz, amelyhez egy folyamat zárolva van, adott mennyiségű kapacitást kap.

Ha például a szabályozott rendszer másodpercenként 500 kérést engedélyez, 20 partíciót hozhat létre másodpercenként 25 kérés értékben. Ha egy folyamat 100 kérés kiállításához szükséges, négy partícióra kérheti az elosztott kölcsönös kizárási rendszert. A rendszer 10 másodpercig két partíciót adhat meg. A folyamat ezután másodpercenként 50 kérésre korlátozza a korlátot, két másodperc alatt befejezi a feladatot, majd feloldja a zárolást.

A minta megvalósításának egyik módja az Azure Storage használata. Ebben a forgatókönyvben logikai partíciónként egy 0 bájtos blobot hoz létre egy tárolóban. Az alkalmazások ezután rövid ideig (például 15 másodpercig) közvetlenül ezekre a blobokra vonatkozóan szerezhetnek be kizárólagos bérleteket. Minden egyes bérlet esetében az alkalmazás képes lesz használni a partíció hasznos kapacitását. Az alkalmazásnak ezután nyomon kell követnie a bérlet idejét, hogy a lejárata után le tudja állítani a megadott kapacitás használatát. Ennek a mintának a megvalósításakor gyakran azt szeretné, hogy minden folyamat megkíséreljen egy véletlenszerű partíciót bérelni, amikor kapacitásra van szüksége.

A késés további csökkentése érdekében előfordulhat, hogy az egyes folyamatokhoz kis mennyiségű kizárólagos kapacitást foglal le. Egy folyamat ezután csak akkor próbálna bérletet szerezni a megosztott kapacitáson, ha azt a fenntartott kapacitás túllépéséhez szükséges.

Az Azure Storage alternatívaként az ilyen típusú bérletkezelési rendszert olyan technológiák használatával is implementálhatja, mint a Zookeeper, a Consul stb., a Redis/Redsync stb.

Problémák és megfontolandó szempontok

A minta implementálásának eldöntésekor vegye figyelembe a következőket:

• Bár a sebességkorlátozási minta csökkentheti a szabályozási hibák számát, az alkalmazásnak továbbra is megfelelően kell kezelnie az esetleges szabályozási hibákat.
• Ha az alkalmazás több olyan munkafolyamattal rendelkezik, amely ugyanahhoz a szabályozott szolgáltatáshoz fér hozzá, az összeset integrálnia kell a sebességkorlátozó stratégiába. Például támogathatja a rekordok tömeges betöltését egy adatbázisba, de az ugyanabban az adatbázisban lévő rekordok lekérdezését is. A kapacitást úgy kezelheti, hogy az összes munkafolyamat azonos sebességkorlátozó mechanizmuson keresztül legyen elérhető. Másik lehetőségként külön kapacitáskészleteket is lefoglalhat az egyes munkafolyamatokhoz.
• A szabályozott szolgáltatás több alkalmazásban is használható. Bizonyos esetekben – de nem minden esetben – lehetséges a használat koordinálása (a fent látható módon). Ha a vártnál nagyobb számú szabályozási hibát lát, ez a szolgáltatáshoz hozzáférő alkalmazások közötti versengés jele lehet. Ha igen, érdemes lehet ideiglenesen csökkentenie a sebességkorlátozó mechanizmus által előírt átviteli sebességet, amíg a más alkalmazásokból származó használat nem csökken.

Mikor érdemes ezt a mintát használni?

Ez a minta a következőkre használható:

• Csökkentse a korlátozott szabályozással rendelkező szolgáltatás által kiváltott szabályozási hibákat.
• Csökkentse a forgalmat a hibakeresés naiv újrapróbálkozásához képest.
• Csökkentse a memóriahasználatot úgy, hogy csak akkor vonja le a rekordokat, ha van kapacitás a feldolgozásukra.

Számítási feladatok tervezése

Az tervezőknek értékelniük kell, hogyan használható a sebességkorlátozási minta a számítási feladat kialakításában az Azure Well-Architected Framework pilléreiben foglalt célok és alapelvek kezelésére. Példa:

Pillér	Hogyan támogatja ez a minta a pillércélokat?
A megbízhatósági tervezési döntések segítenek a számítási feladatnak ellenállóvá válni a hibás működéssel szemben, és biztosítani, hogy a hiba bekövetkezése után teljesen működőképes állapotba kerüljön.	Ez a taktika azzal védi az ügyfelet, hogy elismeri és betartja a szolgáltatással való kommunikáció korlátait és költségeit, amikor a szolgáltatás el szeretné kerülni a túlzott használatot. - RE:07 Önmegőrzés

Mint minden tervezési döntésnél, fontolja meg az ezzel a mintával bevezethető többi pillér céljaival szembeni kompromisszumokat.

Példa

Az alábbi példaalkalmazás lehetővé teszi, hogy a felhasználók különböző típusú rekordokat küldjenek egy API-ba. Minden rekordtípushoz egyedi feladatfeldolgozó tartozik, amely a következő lépéseket hajtja végre:

1. Érvényesítés
2. Bővítés
3. A rekord beszúrása az adatbázisba

Az alkalmazás minden összetevője (API, A feladatfeldolgozó és B feladatfeldolgozó) különálló folyamatok, amelyek egymástól függetlenül skálázhatók. A folyamatok nem kommunikálnak közvetlenül egymással.

Ez a diagram a következő munkafolyamatot tartalmazza:

1. A felhasználó 10 000 A típusú rekordot küld az API-nak.
2. Az API 10 000 rekordot hoz létre az A üzenetsorban.
3. A felhasználó 5000 B típusú rekordot küld az API-nak.
4. Az API beolvasja ezt az 5000 rekordot a B üzenetsorba.
5. Az A feladatfeldolgozó látja az A üzenetsor rekordjait, és megpróbál kizárólagos bérletet szerezni a 2. blobon.
6. A B feladatfeldolgozó látja, hogy a B várólista rekordokkal rendelkezik, és megpróbál kizárólagos bérletet szerezni a 2. blobon.
7. Az A feladatfeldolgozó nem tudja beszerezni a bérletet.
8. A B feladatfeldolgozó 15 másodpercen át szerzi be a 2. blob bérletét. Mostantól másodpercenként 100-ra értékelheti az adatbázisra irányuló korlátkéréseket.
9. A B feladatfeldolgozó 100 rekordot töröl a B üzenetsorból, és megírja őket.
10. Egy másodperc eltelik.
11. Az A feladatfeldolgozó több rekordot lát az A üzenetsorban, és megpróbál kizárólagos bérletet szerezni a Blob 6-on.
12. A B feladatfeldolgozó azt látja, hogy a B üzenetsor több rekordot is rögzít, és megpróbál kizárólagos bérletet szerezni a blob 3-on.
13. Az A feladatfeldolgozó 15 másodpercen át szerzi be a 6. blob bérletét. Mostantól másodpercenként 100-ra értékelheti az adatbázisra irányuló korlátkéréseket.
14. A B feladatfeldolgozó 15 másodpercen át szerzi be a 3. blob bérletét. Mostantól másodpercenként 200-ra értékelheti az adatbázisra irányuló korlátkéréseket. (A blob 2 bérletét is tartalmazza.)
15. Az A feladatfeldolgozó 100 rekordot töröl az A üzenetsorból, és megírja őket.
16. A B feladatfeldolgozó 200 rekordot töröl a B üzenetsorból, és megírja őket.
17. Egy másodperc eltelik.
18. Az A feladatfeldolgozó több rekordot lát az A üzenetsorban, és megpróbál kizárólagos bérletet szerezni a blob 0-n.
19. A B feladatfeldolgozó azt látja, hogy a B üzenetsor több rekordot is felvesz, és megpróbál kizárólagos bérletet szerezni az 1. blobon.
20. Az A feladatfeldolgozó 15 másodpercen át szerzi be a 0 blob bérletét. Mostantól másodpercenként 200-ra értékelheti az adatbázisra irányuló korlátkéréseket. (A blob 6-os bérletét is tartalmazza.)
21. A B feladatfeldolgozó 1. blob bérletét 15 másodpercre szerzi be. Mostantól másodpercenként 300-ra értékelheti az adatbázisra irányuló korlátkéréseket. (A 2. és a 3. blob bérletét is tartalmazza.)
22. Az A feladatfeldolgozó 200 rekordot töröl az A üzenetsorból, és megírja őket.
23. A B feladatfeldolgozó 300 rekordot töröl a B üzenetsorból, és megírja őket.
24. És így tovább...

15 másodperc elteltével egy vagy mindkét feladat még mindig nem fejeződik be. A bérlet lejártával a processzornak csökkentenie kell a lekérdezett és írott kérelmek számát is.

A minta implementációi különböző programozási nyelveken érhetők el:

• A Go implementáció elérhető a GitHubon.
• A Java-implementáció elérhető a GitHubon.

Kapcsolódó erőforrások

Az alábbi minták és útmutatók szintén hasznosak lehetnek a minta megvalósításakor:

• Szabályozás. Az itt tárgyalt sebességkorlátozó mintát általában egy szabályozott szolgáltatásra válaszul implementáljuk.
• Újrapróbálkozás. Amikor a szabályozott szolgáltatásra irányuló kérések szabályozási hibákat eredményeznek, általában megfelelő időközönként érdemes újrapróbálkoznia.

A várólista-alapú terhelésszintezés hasonló, de több kulcsfontosságú módon különbözik a sebességkorlátozó mintától:

1. A sebességkorlátozásnak nem feltétlenül kell üzenetsorokat használnia a terhelés kezeléséhez, de tartós üzenetkezelési szolgáltatást kell használnia. Egy sebességkorlátozó minta például olyan szolgáltatásokat használhat, mint az Apache Kafka vagy az Azure Event Hubs.
2. A sebességkorlátozási minta bevezeti az elosztott kölcsönös kizárási rendszer fogalmát a partíciókon, amely lehetővé teszi több olyan koordinálatlan folyamat kapacitásának kezelését, amelyek ugyanazon szabályozott szolgáltatással kommunikálnak.
3. Az üzenetsor-alapú terheléselosztási minta akkor alkalmazható, ha a szolgáltatások teljesítménybeli eltérést mutatnak, vagy javítják a rugalmasságot. Ez szélesebb mintá teszi, mint a sebességkorlátozás, amely pontosabban a szabályozott szolgáltatások hatékony elérésével foglalkozik.

Számos szolgáltatás szabályozási mintát használ az általuk felhasznált erőforrások szabályozására, ami korlátozza a más alkalmazások vagy szolgáltatások hozzáférésének sebességét. A sebességkorlátozási mintával elkerülheti vagy minimalizálhatja a szabályozási korlátokhoz kapcsolódó szabályozási hibákat, és pontosabban előrejelezheti az átviteli sebességet.

A sebességkorlátozó minta sok esetben megfelelő, de különösen hasznos nagy léptékű, ismétlődő automatizált feladatokhoz, például kötegelt feldolgozáshoz.

Kontextus és probléma

Ha nagy számú műveletet hajt végre szabályozott szolgáltatással, az nagyobb forgalmat és átviteli sebességet eredményezhet, mivel az elutasított kéréseket mindkét esetben nyomon kell követnie, majd újra meg kell próbálkoznia. A műveletek számának növekedésével a szabályozási korlát több adatátadást is igényelhet, ami nagyobb teljesítményhatást eredményez.

Példaként tekintse meg a következő naiv újrapróbálkozást az adatok Azure Cosmos DB-be való betöltéséhez szükséges hibafolyamaton:

1. Az alkalmazásnak 10 000 rekordot kell beszúrnia az Azure Cosmos DB-be. Minden rekord 10 kérelemegységbe (kérelemegységbe) kerül, ami összesen 100 000 kérelemegységet igényel a feladat elvégzéséhez.
2. Az Azure Cosmos DB-példány 20 000 kiosztott kérelemegység-kapacitással rendelkezik.
3. Mind a 10 000 rekordot elküldi az Azure Cosmos DB-nek. A rendszer 2000 rekordot írt sikeresen, és 8000 rekordot elutasított.
4. A fennmaradó 8000 rekordot elküldi az Azure Cosmos DB-nek. A rendszer 2000 rekordot ír sikeresen, és 6000 rekordot elutasít.
5. A fennmaradó 6000 rekordot elküldheti az Azure Cosmos DB-nek. A rendszer 2000 rekordot írt sikeresen, és 4000 rekordot elutasított.
6. A fennmaradó 4000 rekordot elküldheti az Azure Cosmos DB-nek. A rendszer 2000 rekordot írt sikeresen, és 2000 rekordot elutasított.
7. A fennmaradó 2000 rekordot elküldi az Azure Cosmos DB-nek. Minden sikeresen meg van írva.

A betöltési feladat sikeresen befejeződött, de csak azután, hogy 30 000 rekordot küldött az Azure Cosmos DB-nek, annak ellenére, hogy a teljes adatkészlet csak 10 000 rekordból állt.

A fenti példában további tényezőket is figyelembe kell venni:

• A nagy számú hiba további munkát is eredményezhet ezeknek a hibáknak a naplózásához és az eredményként kapott naplóadatok feldolgozásához. Ez a naiv megközelítés 20 000 hibát fog kezelni, és a hibák naplózása feldolgozási, memória- vagy tárolási erőforrásköltséget eredményezhet.
• Nem ismerve a betöltési szolgáltatás szabályozási korlátait, a naiv megközelítésnek nincs módja arra, hogy elvárásokat állítson be arra vonatkozóan, hogy mennyi ideig tart az adatfeldolgozás. A sebességkorlátozás lehetővé teszi a betöltéshez szükséges idő kiszámítását.

Megoldás

A sebességkorlátozás csökkentheti a forgalmat, és javíthatja az átviteli sebességet azáltal, hogy csökkenti a szolgáltatásnak küldött rekordok számát egy adott időszakban.

Egy szolgáltatás idővel különböző metrikák alapján szabályozhat, például:

• A műveletek száma (például 20 kérelem másodpercenként).
• Az adatok mennyisége (például 2 GiB percenként).
• A műveletek relatív költsége (például 20 000 kérelemegység másodpercenként).

A szabályozáshoz használt metrikától függetlenül a sebességkorlátozó implementáció magában foglalja a szolgáltatásnak adott időszakban küldött műveletek számának és/vagy méretének szabályozását, optimalizálva a szolgáltatás használatát, miközben nem lépi túl a szabályozási kapacitást.

Azokban az esetekben, amikor az API-k gyorsabban tudják kezelni a kéréseket, mint bármely szabályozott betöltési szolgáltatás, kezelnie kell, hogy milyen gyorsan használhatja a szolgáltatást. A szabályozás azonban csak adatsebesség-eltéréssel kapcsolatos problémaként kezelhető, és a betöltési kérelmek pufferelése, amíg a szabályozott szolgáltatás felzárkózni nem tud, kockázatos. Ha az alkalmazás összeomlik ebben a forgatókönyvben, a pufferelt adatok bármelyikét elveszítheti.

A kockázat elkerülése érdekében érdemes lehet olyan tartós üzenetkezelő rendszerbe küldeni a rekordokat, amely képes kezelni a teljes betöltési arányt. (Az olyan szolgáltatások, mint az Azure Event Hubs, másodpercenként több millió műveletet képesek kezelni). Ezután egy vagy több feladatprocesszor használatával beolvashatja a rekordokat az üzenetkezelő rendszerből a szabályozott szolgáltatás korlátain belül eső szabályozott sebességgel. Ha rekordokat küld az üzenetkezelő rendszerbe, azzal belső memóriát takaríthat meg, ha csak az adott időintervallumban feldolgozható rekordokat törli.

Az Azure számos tartós üzenetkezelési szolgáltatást biztosít, amelyeket ezzel a mintával használhat, többek között a következőket:

• Azure Service Bus
• Azure Queue Storage
• Azure-eseményközpontok

Rekordok küldésekor a rekordok kiadásához használt időtartam részletesebb lehet, mint a szolgáltatás szabályozásának időtartama. A rendszerek gyakran beállítják a szabályozásokat az időbélyegek alapján, amelyek könnyen megérthetők és kezelhetők. A szolgáltatást futtató számítógép esetében azonban ezek az időkeretek nagyon hosszúak lehetnek ahhoz képest, hogy milyen gyorsan tudja feldolgozni az információkat. Előfordulhat például, hogy egy rendszer másodpercenként vagy percenként szabályoz, de a kód általában nanoszekundumok vagy ezredmásodpercek sorrendjében dolgozik.

Bár nem kötelező, gyakran ajánlott kisebb mennyiségű rekordot küldeni az átviteli sebesség javítása érdekében. Így ahelyett, hogy másodpercenként vagy percenként egyszer próbálná meg a kiadásra felszedni a dolgokat, részletesebb lehet annál, hogy az erőforrás-felhasználás (memória, CPU, hálózat stb.) egyenletesebb ütemben haladjon, megelőzve a kérések hirtelen kirobbanása miatti lehetséges szűk keresztmetszeteket. Ha például egy szolgáltatás másodpercenként 100 műveletet tesz lehetővé, a sebességkorlátozó megvalósítása 200 ezredmásodpercenként 20 művelet kiadásával egyenlítheti ki a kérelmeket, ahogyan az az alábbi grafikonon látható.

Emellett néha több nem koordinált folyamat is szükséges a szabályozott szolgáltatások megosztásához. A sebességkorlátozás implementálásához ebben a forgatókönyvben logikailag particionálhatja a szolgáltatás kapacitását, majd elosztott kölcsönös kizárási rendszer használatával kezelheti az ezeken a partíciókon lévő kizárólagos zárolásokat. A koordinálatlan folyamatok ezután versenyezhetnek az ezeken a partíciókon lévő zárolásokért, amikor kapacitásra van szükségük. Minden olyan partícióhoz, amelyhez egy folyamat zárolva van, adott mennyiségű kapacitást kap.

Ha például a szabályozott rendszer másodpercenként 500 kérést engedélyez, 20 partíciót hozhat létre másodpercenként 25 kérés értékben. Ha egy folyamat 100 kérés kiállításához szükséges, négy partícióra kérheti az elosztott kölcsönös kizárási rendszert. A rendszer 10 másodpercig két partíciót adhat meg. A folyamat ezután másodpercenként 50 kérésre korlátozza a korlátot, két másodperc alatt befejezi a feladatot, majd feloldja a zárolást.

A minta megvalósításának egyik módja az Azure Storage használata. Ebben a forgatókönyvben logikai partíciónként egy 0 bájtos blobot hoz létre egy tárolóban. Az alkalmazások ezután rövid ideig (például 15 másodpercig) közvetlenül ezekre a blobokra vonatkozóan szerezhetnek be kizárólagos bérleteket. Minden egyes bérlet esetében az alkalmazás képes lesz használni a partíció hasznos kapacitását. Az alkalmazásnak ezután nyomon kell követnie a bérlet idejét, hogy a lejárata után le tudja állítani a megadott kapacitás használatát. Ennek a mintának a megvalósításakor gyakran azt szeretné, hogy minden folyamat megkíséreljen egy véletlenszerű partíciót bérelni, amikor kapacitásra van szüksége.

A késés további csökkentése érdekében előfordulhat, hogy az egyes folyamatokhoz kis mennyiségű kizárólagos kapacitást foglal le. Egy folyamat ezután csak akkor próbálna bérletet szerezni a megosztott kapacitáson, ha azt a fenntartott kapacitás túllépéséhez szükséges.

Az Azure Storage alternatívaként az ilyen típusú bérletkezelési rendszert olyan technológiák használatával is implementálhatja, mint a Zookeeper, a Consul stb., a Redis/Redsync stb.

Problémák és megfontolandó szempontok

A minta implementálásának eldöntésekor vegye figyelembe a következőket:

• Bár a sebességkorlátozási minta csökkentheti a szabályozási hibák számát, az alkalmazásnak továbbra is megfelelően kell kezelnie az esetleges szabályozási hibákat.
• Ha az alkalmazás több olyan munkafolyamattal rendelkezik, amely ugyanahhoz a szabályozott szolgáltatáshoz fér hozzá, az összeset integrálnia kell a sebességkorlátozó stratégiába. Például támogathatja a rekordok tömeges betöltését egy adatbázisba, de az ugyanabban az adatbázisban lévő rekordok lekérdezését is. A kapacitást úgy kezelheti, hogy az összes munkafolyamat azonos sebességkorlátozó mechanizmuson keresztül legyen elérhető. Másik lehetőségként külön kapacitáskészleteket is lefoglalhat az egyes munkafolyamatokhoz.
• A szabályozott szolgáltatás több alkalmazásban is használható. Bizonyos esetekben – de nem minden esetben – lehetséges a használat koordinálása (a fent látható módon). Ha a vártnál nagyobb számú szabályozási hibát lát, ez a szolgáltatáshoz hozzáférő alkalmazások közötti versengés jele lehet. Ha igen, érdemes lehet ideiglenesen csökkentenie a sebességkorlátozó mechanizmus által előírt átviteli sebességet, amíg a más alkalmazásokból származó használat nem csökken.

Mikor érdemes ezt a mintát használni?

Ez a minta a következőkre használható:

• Csökkentse a korlátozott szabályozással rendelkező szolgáltatás által kiváltott szabályozási hibákat.
• Csökkentse a forgalmat a hibakeresés naiv újrapróbálkozásához képest.
• Csökkentse a memóriahasználatot úgy, hogy csak akkor vonja le a rekordokat, ha van kapacitás a feldolgozásukra.

Számítási feladatok tervezése

Az tervezőknek értékelniük kell, hogyan használható a sebességkorlátozási minta a számítási feladat kialakításában az Azure Well-Architected Framework pilléreiben foglalt célok és alapelvek kezelésére. Példa:

Pillér	Hogyan támogatja ez a minta a pillércélokat?
A megbízhatósági tervezési döntések segítenek a számítási feladatnak ellenállóvá válni a hibás működéssel szemben, és biztosítani, hogy a hiba bekövetkezése után teljesen működőképes állapotba kerüljön.	Ez a taktika azzal védi az ügyfelet, hogy elismeri és betartja a szolgáltatással való kommunikáció korlátait és költségeit, amikor a szolgáltatás el szeretné kerülni a túlzott használatot. - RE:07 Önmegőrzés

Mint minden tervezési döntésnél, fontolja meg az ezzel a mintával bevezethető többi pillér céljaival szembeni kompromisszumokat.

Példa

Az alábbi példaalkalmazás lehetővé teszi, hogy a felhasználók különböző típusú rekordokat küldjenek egy API-ba. Minden rekordtípushoz egyedi feladatfeldolgozó tartozik, amely a következő lépéseket hajtja végre:

1. Érvényesítés
2. Bővítés
3. A rekord beszúrása az adatbázisba

Az alkalmazás minden összetevője (API, A feladatfeldolgozó és B feladatfeldolgozó) különálló folyamatok, amelyek egymástól függetlenül skálázhatók. A folyamatok nem kommunikálnak közvetlenül egymással.

Ez a diagram a következő munkafolyamatot tartalmazza:

1. A felhasználó 10 000 A típusú rekordot küld az API-nak.
2. Az API 10 000 rekordot hoz létre az A üzenetsorban.
3. A felhasználó 5000 B típusú rekordot küld az API-nak.
4. Az API beolvasja ezt az 5000 rekordot a B üzenetsorba.
5. Az A feladatfeldolgozó látja az A üzenetsor rekordjait, és megpróbál kizárólagos bérletet szerezni a 2. blobon.
6. A B feladatfeldolgozó látja, hogy a B várólista rekordokkal rendelkezik, és megpróbál kizárólagos bérletet szerezni a 2. blobon.
7. Az A feladatfeldolgozó nem tudja beszerezni a bérletet.
8. A B feladatfeldolgozó 15 másodpercen át szerzi be a 2. blob bérletét. Mostantól másodpercenként 100-ra értékelheti az adatbázisra irányuló korlátkéréseket.
9. A B feladatfeldolgozó 100 rekordot töröl a B üzenetsorból, és megírja őket.
10. Egy másodperc eltelik.
11. Az A feladatfeldolgozó több rekordot lát az A üzenetsorban, és megpróbál kizárólagos bérletet szerezni a Blob 6-on.
12. A B feladatfeldolgozó azt látja, hogy a B üzenetsor több rekordot is rögzít, és megpróbál kizárólagos bérletet szerezni a blob 3-on.
13. Az A feladatfeldolgozó 15 másodpercen át szerzi be a 6. blob bérletét. Mostantól másodpercenként 100-ra értékelheti az adatbázisra irányuló korlátkéréseket.
14. A B feladatfeldolgozó 15 másodpercen át szerzi be a 3. blob bérletét. Mostantól másodpercenként 200-ra értékelheti az adatbázisra irányuló korlátkéréseket. (A blob 2 bérletét is tartalmazza.)
15. Az A feladatfeldolgozó 100 rekordot töröl az A üzenetsorból, és megírja őket.
16. A B feladatfeldolgozó 200 rekordot töröl a B üzenetsorból, és megírja őket.
17. Egy másodperc eltelik.
18. Az A feladatfeldolgozó több rekordot lát az A üzenetsorban, és megpróbál kizárólagos bérletet szerezni a blob 0-n.
19. A B feladatfeldolgozó azt látja, hogy a B üzenetsor több rekordot is felvesz, és megpróbál kizárólagos bérletet szerezni az 1. blobon.
20. Az A feladatfeldolgozó 15 másodpercen át szerzi be a 0 blob bérletét. Mostantól másodpercenként 200-ra értékelheti az adatbázisra irányuló korlátkéréseket. (A blob 6-os bérletét is tartalmazza.)
21. A B feladatfeldolgozó 1. blob bérletét 15 másodpercre szerzi be. Mostantól másodpercenként 300-ra értékelheti az adatbázisra irányuló korlátkéréseket. (A 2. és a 3. blob bérletét is tartalmazza.)
22. Az A feladatfeldolgozó 200 rekordot töröl az A üzenetsorból, és megírja őket.
23. A B feladatfeldolgozó 300 rekordot töröl a B üzenetsorból, és megírja őket.
24. És így tovább...

15 másodperc elteltével egy vagy mindkét feladat még mindig nem fejeződik be. A bérlet lejártával a processzornak csökkentenie kell a lekérdezett és írott kérelmek számát is.

A minta implementációi különböző programozási nyelveken érhetők el:

• A Go implementáció elérhető a GitHubon.
• A Java-implementáció elérhető a GitHubon.

Kapcsolódó erőforrások

Az alábbi minták és útmutatók szintén hasznosak lehetnek a minta megvalósításakor:

• Szabályozás. Az itt tárgyalt sebességkorlátozó mintát általában egy szabályozott szolgáltatásra válaszul implementáljuk.
• Újrapróbálkozás. Amikor a szabályozott szolgáltatásra irányuló kérések szabályozási hibákat eredményeznek, általában megfelelő időközönként érdemes újrapróbálkoznia.

A várólista-alapú terhelésszintezés hasonló, de több kulcsfontosságú módon különbözik a sebességkorlátozó mintától:

1. A sebességkorlátozásnak nem feltétlenül kell üzenetsorokat használnia a terhelés kezeléséhez, de tartós üzenetkezelési szolgáltatást kell használnia. Egy sebességkorlátozó minta például olyan szolgáltatásokat használhat, mint az Apache Kafka vagy az Azure Event Hubs.
2. A sebességkorlátozási minta bevezeti az elosztott kölcsönös kizárási rendszer fogalmát a partíciókon, amely lehetővé teszi több olyan koordinálatlan folyamat kapacitásának kezelését, amelyek ugyanazon szabályozott szolgáltatással kommunikálnak.
3. Az üzenetsor-alapú terheléselosztási minta akkor alkalmazható, ha a szolgáltatások teljesítménybeli eltérést mutatnak, vagy javítják a rugalmasságot. Ez szélesebb mintá teszi, mint a sebességkorlátozás, amely pontosabban a szabályozott szolgáltatások hatékony elérésével foglalkozik.