Átmeneti hibák kezelése
A távoli szolgáltatásokkal és erőforrásokkal kommunikáló alkalmazásoknak érzékenynek kell lenniük az átmeneti hibákra. Ez különösen igaz a felhőben futó alkalmazásokra, ahol a környezet természete és az interneten keresztüli kapcsolat miatt ez a hiba valószínűleg gyakrabban jelentkezik. Az átmeneti hibák közé tartozik az összetevők és szolgáltatások hálózati kapcsolatának pillanatnyi elvesztése, a szolgáltatás ideiglenes elérhetetlensége, valamint a szolgáltatás foglaltsága esetén előforduló időtúllépések. Ezek a hibák gyakran önjavítóak, ezért ha a művelet megfelelő késleltetés után ismétlődik, valószínűleg sikeres lesz.
Ez a cikk általános útmutatást nyújt az átmeneti hibakezeléshez. Az Azure-szolgáltatások használatakor előforduló átmeneti hibák kezelésével kapcsolatos információkért tekintse meg az Azure-szolgáltatások újrapróbálkozási útmutatóját.
Miért fordulnak elő átmeneti hibák a felhőben?
Az átmeneti hibák bármilyen környezet, platform vagy operációs rendszer esetén, illetve bármilyen típusú alkalmazásban előfordulhatnak. A helyi helyszíni infrastruktúrán futó megoldások esetében az alkalmazás és összetevői teljesítménye és rendelkezésre állása általában költséges és gyakran kihasználatlan hardveres redundancián keresztül marad fenn, az összetevők és erőforrások pedig egymás közelében találhatók. Ez a megközelítés kevésbé valószínű, de átmeneti hibák továbbra is előfordulhatnak, ahogy az olyan előre nem látható események által okozott kimaradások is, mint a külső áramellátás vagy a hálózati problémák, vagy más vészforgatókönyvek.
A felhőalapú üzemeltetés, beleértve a magánfelhőrendszereket is, magasabb általános rendelkezésre állást kínálhat megosztott erőforrások, redundancia, automatikus feladatátvétel és dinamikus erőforrás-kiosztás használatával számos értékes számítási csomóponton. A felhőkörnyezetek természetéből adódóan azonban az átmeneti hibák nagyobb valószínűséggel fordulnak elő. Ennek több oka is van:
A felhőkörnyezetben számos erőforrás meg van osztva, és az erőforrások védelme érdekében az erőforrásokhoz való hozzáférés szabályozás alá esik. Egyes szolgáltatások megtagadják a kapcsolatokat, amikor a terhelés egy adott szintre emelkedik, vagy amikor eléri a maximális átviteli sebességet, hogy lehetővé tegye a meglévő kérések feldolgozását, és fenntartsa a szolgáltatás teljesítményét az összes felhasználó számára. A szabályozás segít fenntartani a szolgáltatás minőségét a megosztott erőforrást használó szomszédok és más bérlők számára.
A felhőkörnyezetek nagy mennyiségű árucikk hardveregységet használnak. A teljesítményt úgy biztosítják, hogy dinamikusan osztják el a terhelést több számítási egység és infrastruktúra-összetevő között. A hibás egységek automatikus újrahasznosításával vagy cseréjével biztosítják a megbízhatóságot. A dinamikus jelleg miatt időnként átmeneti hibák és ideiglenes csatlakozási hibák léphetnek fel.
Az alkalmazás és az általa használt erőforrások és szolgáltatások között gyakran több hardverösszetevő van, például hálózati infrastruktúra, például útválasztók és terheléselosztók. Ez a további infrastruktúra alkalmanként további kapcsolódási késést és átmeneti kapcsolati hibákat okozhat.
Az ügyfél és a kiszolgáló közötti hálózati feltételek változók lehetnek, különösen akkor, ha a kommunikáció keresztezi az internetet. Még a helyszíni helyeken is a nagy forgalom lelassíthatja a kommunikációt, és időszakos csatlakozási hibákat okozhat.
Problémák
Az átmeneti hibák nagy hatással lehetnek az alkalmazások érzékelt rendelkezésre állására, még akkor is, ha minden előre látható körülmények között alaposan tesztelték. Annak érdekében, hogy a felhőben üzemeltetett alkalmazások megbízhatóan működjenek, gondoskodnia kell arról, hogy a következő kihívásokra válaszolhassanak:
Az alkalmazásnak képesnek kell lennie észlelni a hibák előfordulását, és meg kell állapítania, hogy a hibák valószínűleg átmenetiek, tartósak vagy terminálhibák. A különböző erőforrások valószínűleg különböző válaszokat adnak vissza hiba esetén, és ezek a válaszok a művelet környezetétől függően is változhatnak. Ha például az alkalmazás a tárolóból olvas, a hiba válasza eltérhet a tárolóba való íráskor kapott választól. Számos erőforrás és szolgáltatás jól dokumentált átmeneti meghibásodási szerződéssel rendelkezik. Ha azonban ezek az információk nem érhetők el, nehéz lehet felderíteni a hiba természetét és azt, hogy az valószínűleg átmeneti-e.
Az alkalmazásnak képesnek kell lennie a művelet újrapróbálkozására, ha megállapítja, hogy a hiba valószínűleg átmeneti lesz. Azt is nyomon kell követnie, hogy hányszor próbálkozik újra a művelet.
Az alkalmazásnak megfelelő stratégiát kell használnia az újrapróbálkozáshoz. A stratégia meghatározza, hogy az alkalmazásnak hányszor kell újrapróbálkoznia, az egyes kísérletek közötti késést, valamint a sikertelen kísérletek után végrehajtandó műveleteket. Gyakran nehéz meghatározni a kísérletek megfelelő számát és az egyes kísérletek közötti késést. A stratégia az erőforrás típusától, valamint az erőforrás és az alkalmazás aktuális üzemeltetési feltételeitől függően változik.
Általános irányelvek
Az alábbi irányelvek segítenek megfelelő átmeneti hibakezelési mechanizmusok kialakításában az alkalmazások számára.
Annak megállapítása, hogy létezik-e beépített újrapróbálkozásos mechanizmus
Számos szolgáltatás biztosít átmeneti hibakezelési mechanizmust tartalmazó SDK-t vagy ügyfélkódtárat. A mechanizmus által használt újrapróbálkozási szabályzat általában a célszolgáltatás természetéhez és követelményeihez igazodik. Alternatív megoldásként a szolgáltatások REST-felületei olyan információkat is visszaadhatnak, amelyek segítségével megállapíthatja, hogy az újrapróbálkozások megfelelőek-e, és mennyi ideig kell várni a következő újrapróbálkozási kísérlet előtt.
Ha elérhető, használja a beépített újrapróbálkozési mechanizmust, kivéve, ha olyan konkrét és jól érthető követelményekkel rendelkezik, amelyek egy másik újrapróbálkozési viselkedést tesznek megfelelőbbé.
Annak meghatározása, hogy a művelet alkalmas-e az újrapróbálkozásra
Az újrapróbálkozási műveleteket csak akkor hajtsa végre, ha a hibák átmenetiek (általában a hiba természete jelzi), és ha legalább valószínű, hogy a művelet sikeres lesz az újrapróbálkozáskor. Nincs értelme olyan műveleteket újrapróbálkozni, amelyek érvénytelen műveletet kísérelnek meg, például egy nem létező elem adatbázis-frissítését, vagy egy olyan szolgáltatásra vagy erőforrásra irányuló kérést, amely végzetes hibát szenvedett.
Az újrapróbálkozásokat általában csak akkor hajthatja végre, ha meg tudja határozni ennek teljes hatását, és ha a feltételek jól érthetőek és érvényesíthetők. Ellenkező esetben hagyja, hogy a hívó kód implementáljon újrapróbálkozásokat. Ne feledje, hogy a kontrollon kívüli erőforrásokból és szolgáltatásokból visszaadott hibák idővel változhatnak, és előfordulhat, hogy újra meg kell látogatnia az átmeneti hibaészlelési logikát.
Szolgáltatások vagy összetevők létrehozásakor érdemes lehet olyan hibakódokat és üzeneteket implementálni, amelyek segítenek az ügyfeleknek eldönteni, hogy újrapróbálkoznak-e a sikertelen műveletek. Jelezze például, hogy az ügyfélnek újra meg kell-e próbálnia a műveletet (esetleg az isTransient érték visszaadásával), és javasoljon megfelelő késleltetést a következő újrapróbálkozási kísérlet előtt. Ha webszolgáltatást hoz létre, fontolja meg a szolgáltatási szerződésekben meghatározott egyéni hibák visszaadását. Annak ellenére, hogy az általános ügyfelek nem tudják elolvasni ezeket a hibákat, hasznosak az egyéni ügyfelek létrehozásakor.
A megfelelő újrapróbálkozási szám és intervallum meghatározása
Optimalizálja az újrapróbálkozási számot és az időközt a használati eset típusához. Ha nem próbálkozik elég alkalommal, az alkalmazás nem tudja végrehajtani a műveletet, és valószínűleg sikertelen lesz. Ha túl sokszor próbálkozik újra, vagy túl rövid időközzel próbálkozik a próbálkozások között, előfordulhat, hogy az alkalmazás hosszú ideig olyan erőforrásokat tárol, mint a szálak, a kapcsolatok és a memória, ami hátrányosan befolyásolja az alkalmazás állapotát.
Módosítsa az időintervallum értékeit és az újrapróbálkozások számát a művelet típusához. Ha például a művelet egy felhasználói beavatkozás része, az időköznek rövidnek kell lennie, és csak néhány újrapróbálkozási kísérletet kell végrehajtania. Ezzel a módszerrel elkerülheti, hogy a felhasználók megvárják a választ, ami nyitott kapcsolatokat tartogat, és csökkentheti a többi felhasználó rendelkezésre állását. Ha a művelet egy hosszú ideig futó vagy kritikus munkafolyamat része, ahol a folyamat megszakítása és újraindítása költséges vagy időigényes, érdemes hosszabb időt várni a kísérletek között, és újra próbálkozni.
Ne feledje, hogy a sikeres stratégia kialakításának legnehezebb része az újrapróbálkozások közötti megfelelő időközök meghatározása. A stratégiák általában az alábbi újrapróbálkozási időköztípusokat használják:
Exponenciális visszatartás. Az alkalmazás az első újrapróbálkozás előtt rövid ideig várakozik, majd exponenciálisan növeli az egyes újrapróbálkozások közötti időt. Előfordulhat például, hogy újrapróbálkozza a műveletet 3 másodperc, 12 másodperc, 30 másodperc stb. után.
Növekményes időközök. Az alkalmazás rövid ideig várakozik az első újrapróbálkozás előtt, majd növekményesen növeli az egyes újrapróbálkozások közötti időt. Előfordulhat például, hogy újrapróbálkozza a műveletet 3 másodperc, 7 másodperc, 13 másodperc stb. után.
Rendszeres időközök. Az alkalmazás ugyanannyi ideig várakozik a próbálkozások között. Előfordulhat például, hogy 3 másodpercenként újrapróbálkozza a műveletet.
Azonnali újrapróbálkozás. Előfordulhat, hogy egy átmeneti hiba rövid, amelyet egy olyan esemény okozhat, mint egy hálózati csomag ütközése vagy egy hardverösszetevő csúcsa. Ebben az esetben a művelet azonnali újrapróbálkozása megfelelő lehet, mert akkor lehet sikeres, ha a hiba abban az időben törlődik, amikor az alkalmazás összeáll és elküldi a következő kérést. Azonban soha ne legyen több azonnali újrapróbálkozási kísérlet. Ha az azonnali újrapróbálkozás meghiúsul, váltson alternatív stratégiákra, például exponenciális visszalépési vagy tartalék műveletekre.
Véletlenszerűsítés. A korábban felsorolt újrapróbálkozási stratégiák bármelyike tartalmazhat véletlenszerűsítést, amely megakadályozza, hogy az ügyfél több példánya egyszerre küldjön további újrapróbálkozási kísérleteket. Előfordulhat például, hogy egy példány 3 másodperc, 11 másodperc, 28 másodperc stb. után újrapróbálkozza a műveletet, míg egy másik példány 4 másodperc, 12 másodperc, 26 másodperc stb. után újrapróbálkozza a műveletet. A véletlenszerűség hasznos technika, amely más stratégiákkal kombinálható.
Általános útmutatóként használjon exponenciális visszalépési stratégiát a háttérműveletekhez, és használjon azonnali vagy rendszeres időközönkénti újrapróbálkozási stratégiákat az interaktív műveletekhez. Mindkét esetben úgy kell kiválasztania a késleltetést és az újrapróbálkozások számát, hogy az újrapróbálkozási kísérletek maximális késleltetése megfeleljen a végpontok közötti késés szükséges követelményeinek.
Vegye figyelembe az összes olyan tényező kombinációját, amely hozzájárul az újrapróbálkozás teljes maximális időtúllépéséhez. Ezek a tényezők magukban foglalják a sikertelen kapcsolatok válaszhoz való előállításához szükséges időt (általában az ügyfél időtúllépési értékével), az újrapróbálkozási kísérletek közötti késést és az újrapróbálkozások maximális számát. Az összes ilyen idő hosszú általános műveleti időt eredményezhet, különösen akkor, ha exponenciális késleltetési stratégiát használ, ahol az újrapróbálkozások közötti időköz az egyes hibák után gyorsan növekszik. Ha egy folyamatnak meg kell felelnie egy adott szolgáltatásiszint-szerződésnek (SLA), a teljes működési időnek , beleértve az összes időtúllépést és késést is, az SLA-ban meghatározott korlátokon belül kell lennie.
Ne alkalmazzon túlzottan agresszív újrapróbálkozési stratégiákat. Ezek olyan stratégiák, amelyek időközei túl rövidek, vagy túl gyakori újrapróbálkozások. Negatív hatással lehetnek a célerőforrásra vagy szolgáltatásra. Ezek a stratégiák megakadályozhatják, hogy az erőforrás vagy szolgáltatás helyreálljon a túlterhelt állapotából, és továbbra is blokkolja vagy elutasítja a kéréseket. Ez a forgatókönyv ördögi kört eredményez, ahol a rendszer egyre több kérést küld az erőforrásnak vagy szolgáltatásnak. Következésképpen a helyreállítás képessége tovább csökken.
Az újrapróbálkozási időközök kiválasztásakor vegye figyelembe a műveletek időtúllépését, hogy elkerülje a későbbi kísérlet azonnali indítását (például ha az időtúllépési időszak az újrapróbálkozási időközhöz hasonló). Azt is gondolja át, hogy a teljes lehetséges időtartamot (az időtúllépést és az újrapróbálkozási időközöket) egy adott teljes idő alatt kell-e tartania. Ha egy művelet szokatlanul rövid vagy hosszú időtúllépéssel rendelkezik, az időtúllépés befolyásolhatja, hogy mennyi ideig kell várni, és hogy milyen gyakran próbálkozzon újra a művelettel.
A kivétel típusát és a benne lévő adatokat, illetve a szolgáltatásból visszaadott hibakódokat és üzeneteket használva optimalizálhatja az újrapróbálkozések számát és a köztük lévő intervallumot. Egyes kivételek vagy hibakódok (például az 503-at tartalmazó HTTP-kód, a Szolgáltatás nem érhető el, a válaszban újrapróbálkozási utófejjel) például jelezhetik, hogy mennyi ideig tarthat a hiba, vagy hogy a szolgáltatás meghiúsult, és nem válaszol a későbbi próbálkozásokra.
Kerülje az antipatterneket
A legtöbb esetben kerülje az újrapróbálkozási kód duplikált rétegeit tartalmazó implementációkat. Kerülje az olyan terveket, amelyek kaszkádolt újrapróbálkozási mechanizmusokat tartalmaznak, vagy amelyek újrapróbálkozást hajtanak végre egy olyan művelet minden szakaszában, amely a kérések hierarchiáját foglalja magában, kivéve, ha vannak olyan konkrét követelmények, amelyek ezt megkövetelik. Ezekben a kivételes esetekben használjon olyan szabályzatokat, amelyek megakadályozzák a túl sok újrapróbálkozást és a túl nagy késleltetési időközöket, és győződjön meg róla, hogy tisztában van a következményekkel. Tegyük fel például, hogy az egyik összetevő kérést intéz egy másikhoz, majd hozzáfér a célszolgáltatáshoz. Ha mindkét híváson három darab újrapróbálkozást hajt végre, összesen kilenc újrapróbálkozási kísérlet történik a szolgáltatás ellen. Számos szolgáltatás és erőforrás implementál egy beépített újrapróbálkozési mechanizmust. Meg kell vizsgálnia, hogyan tilthatja le vagy módosíthatja ezeket a mechanizmusokat, ha magasabb szinten kell végrehajtania az újrapróbálkozásokat.
Soha ne implementáljon végtelen újrapróbálkozási mechanizmust. Ez valószínűleg megakadályozza, hogy az erőforrás vagy szolgáltatás helyreálljon a túlterhelési helyzetekből, és a szabályozást és a kapcsolatok hosszabb ideig való folytatását okozza. Használjon véges számú újrapróbálkozási lehetőséget, vagy implementáljon egy olyan mintát, mint a Megszakító , hogy a szolgáltatás helyreálljon.
Soha ne végezzen azonnali újrapróbálkozást egynél több alkalommal.
Ne használjon rendszeres újrapróbálkozási időközt, amikor az Azure-beli szolgáltatásokhoz és erőforrásokhoz fér hozzá, különösen akkor, ha nagy számú újrapróbálkozási kísérlete van. Ebben a forgatókönyvben a legjobb módszer egy exponenciális háttérstratégia, amely kapcsolatcsoporttörési képességgel rendelkezik.
Megakadályozza, hogy ugyanazon ügyfél több példánya vagy több különböző ügyfélpéldánya egyszerre küldjön újrapróbálkozási elemet. Ha ez a forgatókönyv valószínűleg bekövetkezik, vezessen be véletlenszerűsítést az újrapróbálkozási időközökbe.
Újrapróbálkozási stratégia és megvalósítás tesztelése
Az újrapróbálkozás stratégiájának teljes körű tesztelése a lehető legszélesebb körülmények között, különösen akkor, ha az alkalmazás és a használt célerőforrások és szolgáltatások is rendkívül terhelés alatt állnak. A következőképpen ellenőrizheti a viselkedést a tesztelés közben:
Átmeneti és nem átmeneti hibákat injektál a szolgáltatásba. Például küldjön érvénytelen kéréseket, vagy adjon hozzá egy kódot, amely észleli a tesztelési kéréseket, és különböző típusú hibákat ad vissza válaszként. A TestApi-t használó példákért lásd a TestApi hibainjektálási tesztelését és a TestApi bemutatása – 5. rész: Felügyelt kód hibainjektálási API-k.
Hozzon létre egy makettet az erőforrásról vagy szolgáltatásról, amely a valós szolgáltatás által visszaadott hibák tartományát adja vissza. Fedezze fel az újrapróbálkozési stratégia által észlelt összes hibatípust.
A létrehozott és üzembe helyezhető egyéni szolgáltatások esetében kényszerítse az átmeneti hibák előfordulását a szolgáltatás ideiglenes letiltásával vagy túlterhelésével. (Ne próbálja meg túlterhelni a megosztott erőforrásokat vagy a megosztott szolgáltatásokat az Azure-ban.)
HTTP-alapú API-k esetén érdemes lehet egy kódtárat használni az automatizált tesztekben a HTTP-kérések eredményének módosításához, akár extra ciklikus idő hozzáadásával, akár a válasz módosításával (például a HTTP-állapotkód, fejlécek, törzs vagy egyéb tényezők) módosításával. Ez lehetővé teszi a hibafeltételek egy részhalmazának determinisztikus tesztelését az átmeneti hibák és más típusú hibák esetében.
Nagy terhelési tényezőt és egyidejű teszteket hajthat végre annak biztosítása érdekében, hogy az újrapróbálkozási mechanizmus és a stratégia megfelelően működjön ezekben a feltételekben. Ezek a tesztek azt is biztosítják, hogy az újrapróbálkozás ne befolyásolja hátrányosan az ügyfél működését, és ne okozzon keresztszennyezettséget a kérelmek között.
Újrapróbálkozások szabályzatkonfigurációinak kezelése
Az újrapróbálkozési szabályzat az újrapróbálkozás stratégiájának összes elemének kombinációja. Meghatározza az észlelési mechanizmust, amely meghatározza, hogy egy hiba valószínűleg átmeneti-e, a használandó időköz típusa (például rendszeres, exponenciális visszakapcsolás és véletlenszerűség), a tényleges intervallumértékek és az újrapróbálkozások száma.
Az újrapróbálkozások megvalósítása sok helyen, még a legegyszerűbb alkalmazásban is, és az összetettebb alkalmazások minden rétegében. Ahelyett, hogy az egyes szabályzatok elemeit több helyen is keményen kódolták, fontolja meg egy központi pont használatát az összes szabályzat tárolásához. Tárolja például az olyan értékeket, mint az intervallum és az újrapróbálkozások száma az alkalmazáskonfigurációs fájlokban, olvassa el őket futásidőben, és programozott módon hozza létre az újrapróbálkozási szabályzatokat. Ezzel egyszerűbbé válik a beállítások kezelése, valamint az értékek módosítása és finomhangolása a változó követelményeknek és forgatókönyveknek megfelelően. Azonban úgy tervezheti meg a rendszert, hogy tárolja az értékeket ahelyett, hogy minden alkalommal újraolvasná a konfigurációs fájlt, és megfelelő alapértelmezett értékeket használjon, ha az értékek nem kérhetők le a konfigurációból.
Egy Azure Cloud Services-alkalmazásban érdemes lehet az újrapróbálkozási szabályzatok futásidőben történő létrehozásához használt értékeket a szolgáltatáskonfigurációs fájlban tárolva, hogy az alkalmazás újraindítása nélkül módosíthassa őket.
Használja ki az ön által használt ügyfél API-kban elérhető beépített vagy alapértelmezett újrapróbálkozési stratégiákat, de csak akkor, ha azok megfelelnek az Ön forgatókönyvének. Ezek a stratégiák általában általánosak. Egyes helyzetekben előfordulhat, hogy csak ezekre van szüksége, más forgatókönyvekben azonban nem kínálják az adott követelményeknek megfelelő lehetőségek teljes választékát. A legmegfelelőbb értékek meghatározásához tesztelést kell végeznie annak megértéséhez, hogy a beállítások hogyan befolyásolják az alkalmazást.
Átmeneti és nem átmeneti hibák naplózása és nyomon követése
Az újrapróbálkozási stratégia részeként vegye fel a kivételkezelést és az újrapróbálkozási kísérleteket naplózó egyéb rendszerállapotokat. Időnként átmeneti hiba és újrapróbálkozás várható, és nem jelez problémát. Az újrapróbálkozások rendszeres és növekvő száma azonban gyakran olyan probléma jele, amely meghibásodást okozhat, vagy rontja az alkalmazás teljesítményét és rendelkezésre állását.
Az átmeneti hibákat ne hibabejegyzésként, hanem figyelmeztetésként naplózza, hogy a figyelési rendszerek ne észleljék őket olyan alkalmazáshibákként, amelyek téves riasztásokat válthatnak ki.
Érdemes lehet olyan értéket tárolni a naplóbejegyzésekben, amely azt jelzi, hogy az újrapróbálkozások a szolgáltatás szabályozása vagy más típusú hibák, például csatlakozási hibák okoztak-e, így megkülönböztetheti őket az adatok elemzése során. A szabályozási hibák számának növekedése gyakran egy tervezési hibát jelez az alkalmazásban, vagy azt, hogy át kell váltani egy dedikált hardvereket kínáló prémium szolgáltatásra.
Fontolja meg az újrapróbálkozási mechanizmust tartalmazó műveletek összesített eltelt idejének mérését és naplózását. Ez a metrika jól jelzi az átmeneti hibáknak a felhasználói válaszidőkre, a folyamat késésére és az alkalmazáshasználati esetek hatékonyságára gyakorolt általános hatását. Naplózza az újrapróbálkozások számát is, hogy megértse a válaszidőhöz hozzájáruló tényezőket.
Fontolja meg egy olyan telemetriai és monitorozási rendszer implementálását, amely riasztásokat hozhat létre, ha a hibák száma és sebessége, az újrapróbálkozások átlagos száma vagy a műveletek sikeressége előtt eltelt teljes idő növekszik.
Folyamatosan sikertelen műveletek kezelése
Gondolja át, hogyan fogja kezelni a továbbra is sikertelen műveleteket minden kísérlet során. Az ilyen helyzetek elkerülhetetlenek.
Bár az újrapróbálkozási stratégia meghatározza a művelet újrapróbálkozásának maximális számát, nem akadályozza meg, hogy az alkalmazás ugyanazzal a számú újrapróbálkozással ismételje meg a műveletet. Ha például egy rendelésfeldolgozó szolgáltatás végzetes hibával meghiúsul, amely véglegesen leáll, az újrapróbálkozási stratégia észlelheti a kapcsolat időtúllépését, és átmeneti hibának tekintheti. A kód egy megadott számú alkalommal újrapróbálkozza a műveletet, majd feladja. Amikor azonban egy másik ügyfél lead egy megrendelést, a rendszer újra megpróbálja végrehajtani a műveletet, annak ellenére, hogy minden alkalommal sikertelen lesz.
A folyamatosan sikertelen műveletek folyamatos újrapróbálkozásának megakadályozása érdekében fontolja meg az áramkör-megszakító minta implementálását. Ha ezt a mintát használja, ha egy megadott időkereten belül a hibák száma meghaladja a küszöbértéket, a kérések hibaként azonnal visszatérnek a hívóhoz, és nem kísérlik meg elérni a sikertelen erőforrást vagy szolgáltatást.
Az alkalmazás időszakosan és a kérések közötti hosszú időközökkel időszakosan tesztelheti a szolgáltatást, hogy észlelje, mikor válik elérhetővé. A megfelelő időköz olyan tényezőktől függ, mint a művelet kritikussága és a szolgáltatás jellege. Lehet, hogy néhány perc és több óra között van. Ha a teszt sikeres, az alkalmazás folytathatja a normál műveleteket, és továbbíthatja a kéréseket az újonnan helyreállított szolgáltatásnak.
Addig is előfordulhat, hogy vissza tud esni a szolgáltatás egy másik példányára (esetleg egy másik adatközpontban vagy alkalmazásban), használhat egy hasonló szolgáltatást, amely kompatibilis (talán egyszerűbb) funkciókat kínál, vagy alternatív műveleteket hajthat végre annak reménye alapján, hogy a szolgáltatás hamarosan elérhető lesz. Előfordulhat például, hogy a szolgáltatásra vonatkozó kéréseket egy üzenetsorban vagy adattárban kell tárolni, majd később újrapróbálkoznia. Vagy átirányíthatja a felhasználót az alkalmazás egy másik példányára, csökkentheti az alkalmazás teljesítményét, de továbbra is elfogadható funkciókat kínálhat, vagy egyszerűen elküldhet egy üzenetet a felhasználónak, amely jelzi, hogy az alkalmazás jelenleg nem érhető el.
Egyéb szempontok
Amikor az újrapróbálkozások számának és a szabályzat újrapróbálkozási időközeinek értékéről dönt, fontolja meg, hogy a szolgáltatás vagy erőforrás művelete egy hosszú ideig futó vagy többlépéses művelet része-e. Előfordulhat, hogy nehéz vagy költséges kompenzálni az összes többi olyan működési lépést, amely már sikeres volt, ha az egyik sikertelen. Ebben az esetben egy nagyon hosszú intervallum és sok újrapróbálkozás elfogadható lehet, ha ez a stratégia nem blokkolja a többi műveletet a szűkös erőforrások tartásával vagy zárolásával.
Fontolja meg, hogy ugyanannak a műveletnek az újrapróbálkozása inkonzisztenciákat okozhat-e az adatokban. Ha egy többlépéses folyamat egyes részei ismétlődnek, és a műveletek nem idempotensek, következetlenségek léphetnek fel. Ha például egy értéket növekményes művelet ismétlődik, érvénytelen eredményt eredményez. Ha egy üzenetsorba üzenetet küldő művelet megismétlése inkonzisztencia-problémát okozhat az üzenet fogyasztójában, ha a fogyasztó nem észleli az ismétlődő üzeneteket. A forgatókönyvek elkerülése érdekében minden lépést idempotens műveletként tervezzen meg. További információ: Idempotencia-minták.
Fontolja meg az újrapróbálkozott műveletek hatókörét. Egyszerűbb lehet például újrapróbálkozási kódot implementálni egy olyan szinten, amely több műveletet is magában foglal, és újrapróbálkozza őket, ha az egyik sikertelen. Ez azonban idempotencia-problémákat vagy szükségtelen visszaállítási műveleteket eredményezhet.
Ha több műveletet magában foglaló újrapróbálkozási hatókört választ, vegye figyelembe az újrapróbálkozási időközök meghatározásakor, a művelet eltelt idejének monitorozásakor és a hibákra vonatkozó riasztások létrehozása előtt.
Gondolja át, hogyan befolyásolhatja az újrapróbálkozás stratégiája a megosztott alkalmazás szomszédait és más bérlőit, valamint a megosztott erőforrások és szolgáltatások használatát. Az agresszív újrapróbálkozási szabályzatok egyre több átmeneti hibát okozhatnak a többi felhasználónál, és az olyan alkalmazásokban, amelyek közösen használják ezeket az erőforrásokat és szolgáltatásokat. Hasonlóképpen az alkalmazásra is hatással lehetnek az erőforrások és szolgáltatások más felhasználói által implementált újrapróbálkoztatási szabályzatok. Üzleti szempontból kritikus fontosságú alkalmazások esetén érdemes lehet olyan prémium szintű szolgáltatásokat használni, amelyek nincsenek megosztva. Ezzel nagyobb mértékben szabályozhatja ezen erőforrások és szolgáltatások terhelését és ezáltal szabályozását, ami segíthet igazolni a többletköltségeket.