Határozza meg a teljes folyamat időkeretét, állítson be timeoutot a kapcsolódásra és a válaszra is, csak a biztonságos, átmeneti hibákat ismételje exponenciális késleltetéssel és szórással, tartsa tiszteletben a szolgáltató limitjeit és az idempotenciát, a próbálkozások kimerülése után pedig helyezze át a feladatot egy látható javítási állapotba.
Az API-integrációnak számolnia kell a lassú válasszal, az átmeneti elérhetetlenséggel és a hívások számának korlátjával is. Időtúllépés nélkül egyetlen kapcsolat lefoglalhatja a workereket és az erőforrásokat. Szabályozott újrapróbálkozás nélkül az átmeneti hibából adatvesztés lesz. A túl agresszív retry viszont megterheli a meggyengült szolgáltatást, és lavinát indít, amely meghosszabbítja a kiesést.
Az ellenálló működés az észszerű időkeret, a hibák megkülönböztetése, az idempotencia, a növekvő várakozási idő, a véletlenszerű szórás és a sor kombinációjából fakad. Az értékek nem másolhatók át univerzálisan. A felhasználói folyamatból, a szolgáltató szerződéséből, a mennyiségből és a késés következményeiből kell kiindulniuk. Minden mechanizmushoz monitorozás és egy olyan határ szükséges, amelyen túl ember avatkozik be.
A timeoutot a teljes felhasználói folyamatból vezesse le
Először határozza meg, mennyi ideig várhat a felhasználó vagy a kapcsolódó rendszer. Ezt az időkeretet ossza fel a DNS, a kapcsolat, az átvitel, a feldolgozás és az esetleges újrapróbálkozások között. A kliens időkorlátja ne legyen hosszabb annál az időnél, amely után a fölérendelt szolgáltatás úgyis megszakítja a kérést. Ellenkező esetben fölösleges munka folyik tovább, amelynek eredményét senki sem kapja meg.
Különböztesse meg a kapcsolat felépítésének idejét és a válasz olvasásának idejét. Egy hosszú export jogosan tarthat tovább, mint egy egyszerű ellenőrzés. Ha a művelet túllépi az interaktív időkeretet, alakítsa át állapotkövetéssel rendelkező aszinkron feladattá. Ne növelje az időkorlátot diagnózis nélkül; az csak elrejtheti a túlterhelést vagy egy elakadt folyamatot.
Osztályozza a hibákat az újrapróbálkozás előtt
Egy átmeneti hálózati hiba, a túlterhelés vagy bizonyos szerverválaszok alkalmasak lehetnek az újrapróbálkozásra. Az érvénytelen bemenet, a hiányzó jogosultság vagy a nem létező erőforrás egy újabb próbálkozással általában nem változik. A konkrét szabályokat az API-szerződés és a hibaválasz törzse alapján határozza meg, ne csak az állapotkódok tág csoportja szerint.
Íráskor ellenőrizze az idempotenciát még az újrapróbálkozás (retry) bekapcsolása előtt. Az időtúllépés nem jelenti azt, hogy a szerver nem hajtotta végre a műveletet. Egy megismételt fizetés vagy rendelés nagyobb kárt okozhat, mint az eredeti kiesés. Ha az API nem biztosít biztonságos mechanizmust, vak ismétlés helyett használjon állapotellenőrzést vagy kézi ellenőrzést.
- átmeneti hiba valós helyreállási eséllyel
- idempotens vagy biztonságosan ellenőrizhető művelet
- korlátozott számú próbálkozás és teljes élettartam
- látható eredmény végleges hiba után
Alkalmazzon várakozást, szórást, és tartsa be a rate limitet
A próbálkozások között növelje a várakozási időt, és adjon hozzá véletlenszerű szórást, hogy ne minden kliens ugyanabban a pillanatban ismételje meg a hívást. Állítson be felső korlátot az időre és a próbálkozások számára is. Ha a szolgáltató visszaadja a következő engedélyezett időpontot vagy a fennmaradó kapacitást, a dokumentáció szerint dolgozza fel, és ossza meg a keretet a workerek között.
A rate limitet a szolgáltatás modelljétől függően fiók, endpoint vagy felhasználó szintjén kövesse. A párhuzamos workereknek koordinációra van szükségük, különben mindegyik azt hiszi, hogy a teljes kapacitás rendelkezésére áll. A kritikus műveleteket priorizálja a kötegelt importálással szemben. A gyorsítótár vagy egy tömeges endpoint csökkentheti a hívások számát, ha megőrzi az adatok helyességét és naprakészségét.
Válassza le a felhasználói kérést a sorról
Ha a külső API nem szükséges az azonnali válaszhoz, mentse el a szándékot, és dolgozza fel sorban. A felhasználó a fogadásról kap visszaigazolást, nem a befejezés hamis ígéretét. A sor lehetővé teszi az egyidejűség korlátozását, az átmeneti hibák újrapróbálását és a feladat megőrzését kiesés idején. Minden üzenetnek stabil azonosítóra és maximális élettartamra van szüksége.
A próbálkozások kimerülése után helyezze a feladatot karanténba, megadva az okot és a biztonságos javítás módját. A végtelen újrapróbálkozás felemészti a kapacitást, és elfedi a tartós adathibát. Hosszabb kiesés esetén egy védelmi mechanizmus ideiglenesen leállíthatja a hívásokat, és rendszeresen ellenőrizheti a helyreállást. Riasztás nélkül azonban nem maradhat kikapcsolva.
Kövesse nyomon a technikai és az üzleti eredményt is
Kövesse a késleltetést, az időtúllépéseket, a próbálkozások számát, a korlátozási válaszokat, a sor korát és a karanténba került feladatok arányát. A metrikákat bontsa szolgáltató és művelet szerint. Az átlagos idő elfedheti a hosszú farkat, amely az ügyfeleket érinti. A riasztásnak gazdára, küszöbértékre és eljárásra van szüksége, nem csupán nyers hibára.
A technikai sikeresség nem jelent teljes folyamatot. Hasonlítsa össze a beérkezett rendelések, exportok vagy dokumentumok számát a várt adatfolyammal. Limit- vagy kliensváltozás után végezzen terheléses és regressziós tesztet egy erre engedélyezett környezetben. A kapacitástervet a volumen növekedésekor frissítse, ne csak az első tömeges hiba után.
- a legrégebbi várakozó művelet kora
- a próbálkozások száma a hiba típusa szerint
- a limit kihasználtsága kliensenként és végpontonként
- a célrendszerből hiányzó üzleti objektumok
- helyreállási idő a külső kapacitás felszabadítása után
- a kötegelt feladatok hatása a kritikus hívásokra
Gyakori kérdések
Hányszor kell megismételni egy API-kérést?
Univerzális szám nem létezik. Ez az időkerettől, a hiba típusától, az idempotenciától, a limitektől és az üzleti hatástól függ. A határ elérése után látható javítási állapotnak kell létrejönnie, nem csendes elvetésnek.
Biztonságosabb a hosszabb timeout?
Nem automatikusan. A hosszú timeout lefoglalja az erőforrásokat, és túllépheti a fölérendelt folyamat idejét. Először diagnosztizálja a késleltetést, hosszú munkánál pedig használjon állapotkezelő aszinkron modellt.
Mi a teendő a rate limit túllépésekor?
Tartsa be a szolgáltató utasításait, állítsa le az agresszív ismétlést, ossza el a kéréseket, és ellenőrizze a párhuzamos futást. Hosszú távon csökkentse a felesleges hívásokat, használjon kötegeket, vagy egyeztessen megfelelő kapacitást.
Források és további olvasnivaló
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
