Voitot:
- Osaa tulkita nopeusrajoituksia (RPM/ITPM/OTPM) ja 429-virheitä
- Toteuttaa eksponentiaalisen perääntymisen ja yrittämisen uudelleen yrittämällä uudelleen
- Luokittelee ja käsittelee oikein yleiset HTTP-virhekoodit (400/401/429/500/529)
Tuotantoympäristössä mikään API ei vastaa täydellisesti koko ajan. Joskus lähetät pyyntöjä liian nopeasti ja saavutat rajan; joskus palvelin on tilapäisesti varattu; Joskus pyyntösi on alusta alkaen väärä. Vahvan integraation erottaa amatööriyrityksestä se, että se käsittelee nämä tilanteet ennakoivasti ja automaattisesti. Tässä osiossa opit nopeusrajoituksista (RPM/ITPM/OTPM), 429-virheestä, uudelleenyrityksestä eksponentiaalisella perääntymisellä ja yleisten HTTP-virhekoodien oikeasta luokittelusta. Tavoitteena on rakentaa virtaus, joka on niin vahva, että käyttäjä ei koskaan huomaa sitä.
Mitä nopeusrajoitukset ovat?
Palveluntarjoaja rajoittaa, kuinka paljon työtä kytkin voi tehdä tietyn ajanjakson aikana. Tämä suoja; Se suojaa sekä infrastruktuuria että sinua äkillisiltä kustannusräjähdyksiltä. On olemassa kolme yleistä rajoitustyyppiä:
- RPM (Requests Per Minute): Pyyntöjen määrä minuutissa.
- ITPM (Input Tokens Per Minute): Syöttötunnus, joka voidaan käsitellä minuutissa.
- OTPM (Output Tokens Per Minute): Lähtötunniste, joka voidaan tuottaa minuutissa.
Jos ylität jonkin näistä rajoista, palveluntarjoaja hylkää pyynnön ja palauttaa 429-virhekoodin. Rajat vaihtelevat yleensä tilisi tason (tason) mukaan, ja niitä voidaan korottaa ajan myötä.
Vinkki: Voit katsoa vastausten otsikoista, kun lähestyt rajaa. Useimmat palveluntarjoajat ilmoittavat jäljellä olevan kiintiösi otsikoilla, kuten x-ratelimit-remaining-*. Näiden arvojen seuraaminen ja edessä olevan liikenteen kuristaminen on kypsin tapa estää ongelma ilman 429:ää.
429 ja eksponentiaalinen jäljitys
429 (nopeusrajoitus) on väliaikainen ja uudelleen yritettävä virhe. Oikea vastaus on odottaa pyyntöä jonkin aikaa ja yrittää uudelleen. Mutta jatkuva odottaminen ei riitä; Jos kaikki yrittävät uudelleen samaan aikaan, raja saavutetaan uudelleen. Ratkaisu on eksponentiaalinen perääntyminen: odotusaika kasvaa eksponentiaalisesti jokaisella epäonnistuneella yrityksellä.
# Eksponentiaalinen peruutuslogiikkakokeilu 1 → 429 → odota 1 sekunti kokeilu 2 → 429 → odota 2 sekuntia yritys 3 → 429 → odota 4 sekuntia yritys 4 → 429 → odota 8 sekuntia (+ pieni satunnainen "värinä")... luovuta ja raportoi enintään N kokeilun jälkeen
Pienen satunnaisuuden (värinän) lisääminen tähän estää pyyntöjen törmäyksen yrittäessään uudelleen samaan aikaan. Lisäksi 429-vastauksessa on usein "retry-after" -otsikko: "yritä uudelleen näin monen sekunnin kuluttua". Tämän tittelin kunnioittaminen on tarkempaa kuin sokea odottaminen.
Varoitus: Kun saat 429:n, "sen pakottaminen lähettämällä lisää pyyntöjä" pahentaa tilannetta. Raja täyttyy edelleen eikä pyyntöjä mene läpi. Oikea vastaus on vetäytyminen, ei kiihdytys. Hyviä uutisia: useimmat viralliset SDK:t yrittävät automaattisesti uudelleen 429 ja palvelinvirheet perääntyen – käytä tätä SDK:n toimintaa ennen sen manuaalista asentamista.
HTTP-virhekoodien luokittelu
Kaikki virheet eivät ole samanlaisia. Kriittinen ero: voidaanko sitä yrittää uudelleen vai onko kyseessä pyyntö/identiteettiongelma?
Koodi
Merkitys
Voiko sitä kokeilla uudelleen?
oikea vastaus
400
Virheellinen pyyntö (muoto-/parametrivirhe)
ei
Korjaa pyyntö; älä lähetä samaa uudestaan
401
Todennusvirhe (avain ei kelpaa/puuttuu)
ei
Korjaa avain/nimike
403
Ei valtuutusta (ei pääsyä malliin/ominaisuuteen)
ei
Tarkista käyttöoikeudet/laajuus
404
Ei löydy (virheellinen mallitunnus/päätepiste)
ei
Oikea mallitunnus/osoite
429
Nopeusrajoitus ylitetty
Kyllä
Retreat + yritä uudelleen jälkeen
500
Palvelinvirhe
Kyllä
Yritä uudelleen perääntymällä
529
Palvelin ylikuormitettu
Kyllä
Yritä uudelleen perääntymällä
Kultainen sääntö: 429, 500 ja 529 ovat väliaikaisia; Sitä yritetään uudelleen vetäytymällä. 400, 401, 403, 404 ovat pyyntö-/identiteettiongelmia; Uudelleen yrittäminen ei ratkaise sitä, ja se hukkaa vaivaa. Koodissasi on erotettava nämä kaksi ryhmää.
Askel askeleelta: kestävä puhelu
- Lähetä pyyntö. Jos onnistut, jatka.
- Luokittele virhekoodi. Voiko sitä kokeilla uudelleen?
- Jos kokeiltava: seuraa uudelleenyritystä jälkeen, käytä eksponentiaalista perääntymistä + värinää, yritä rajoitettu määrä kertoja (esim. enintään 5).
- Jos et ole yrittänyt: Korjaa (muoto/avain) ja pysäytä; Älä toista samaa virheellistä pyyntöä silmukassa.
- Harkitse luovuttamista. Jos epäonnistut vielä n yrityksen jälkeen, näytä käyttäjälle kohtelias viesti ja kirjaa tapahtuma lokiin (seurantayksikkö 11).
# Robust call pseudo-codedene = 0repeat: vastaus = request_at(), jos vastaus.success: palauta vastaus, jos vastaus.koodi kohdassa [429, 500, 529] ja yritä < 5: odota = yritä uudelleen ?? (2^kokeile sekuntia + värinä) nukkua(odota); kokeile += 1; git uudelleen, jos vastaus.koodi kohdassa [400, 401, 403, 404]: save_error(response); return "pyyntö täytyy korjata" return "pysyvä virhe, yritä myöhemmin"
# Kohtelias palaute käyttäjälle (kun uudelleenyritykset ovat loppuneet) "Olen juuri nyt kiireinen, en voinut käsitellä pyyntöäsi. Yritä pian uudelleen tai olen tallentanut pyyntösi. Palaan asiaan, kun se on valmis."
Heikko kehote / Vahva kehote (tässä: virheilmoituksen suunnittelu)
# HEIKKO (näyttää käyttäjälle raakavirheen)"Virhe 429: rate_limit_error"
# VAHVA (käyttäjäystävällinen, rauhoittava, toimintaa ehdottava) "Järjestelmässä oli väliaikainen ruuhka. Olemme vastaanottaneet pyyntösi turvallisesti ja sitä yritetään automaattisesti uudelleen. Jos tulos ei näy muutaman sekunnin kuluessa, voit päivittää sivun."
Raaka teknisen virheen paljastaminen loppukäyttäjälle sekä heikentää luottamusta että voi olla tietoturvahaavoittuvuus. Luokittele virheet sisäisesti ja anna käyttäjälle rauhallinen, toimintaan suuntautunut viesti; kirjoita vain tietueen tekniset tiedot.
Kolme minikoteloa
Tapaus 1 – Vene törmäsi liikenneräjähdyksessä. Asiakaspalvelubotti sai kampanjapäivänä 429 kiihtyvää liikennettä; Koodissa ei ollut uudelleenyritystä, jokainen virhe näkyi suoraan käyttäjälle "virheenä". He lisäsivät eksponentiaalisen jäljityksen + uudelleenyritystä jälkeen; samalla liikenteellä, pyynnöt välitettiin useiden sekuntien viiveellä, käyttäjä ei nähnyt virheitä.
Tapaus 2 – Yritetään 400 silmukassa. Integrointi sai 404:n virheellisen mallitunnuksen takia, mutta käsitteli kaikkia virheitä "transienteinä" ja yritti uudelleen äärettömässä silmukassa; Tukki turvoksi ja tarpeetonta kuormaa syntyi. He lisäsivät virheluokituksen: 404 katsotaan pysyväksi, silmukka pysäytetään ja mallitunnus korjataan. Oppitunti: älä yritä jokaista virhettä uudelleen.
Tapaus 3 – Rajan hallinta edestä. Tietojen rikastustyö oli jatkuvasti käynnissä 429 rajalla. He seurasivat x-ratelimit-remaining -otsikkoa ja kuristivat liikennettä kiintiön mukaan. Joten he pitivät tasaista vauhtia juuri rajan alapuolella ottamatta 429s; Työ tehtiin ennakoitavammin ja nopeammin.
Yleisiä virheitä
- Nopeuden lisääminen 429:ssä: Pahentaa tilannetta; Vaihda vetäytymiseen.
- Kutakin virhettä yritetään uudelleen: 400/401/404 on pysyvä; Uudelleen yrittäminen on turhaa.
- Kiinteän odotuksen käyttäminen: Luo törmäyksen; Käytä eksponentiaalista + värinää.
- "Yritä uudelleen" huomioimatta: On tarkinta noudattaa palveluntarjoajan määrittämää aikaa.
- Raakavirheen paljastaminen käyttäjälle: horjuttaa luottamusta, luo haavoittuvuuksia; Luokittele sisällä.
- Rajoittamaton uudelleenyritys: Aseta yläraja (esim. 5 uudelleenyritystä); luovuta sitten kauniisti.
Syvemmälle: jonotus, samanaikaisuus ja katkaisijat
Yhden halun kestävyys on ensimmäinen askel; Todellinen kypsyys on hallita suurta määrää pyyntöjä ylittämättä rajoja. Tässä tulee esiin kolme käsitettä.
Jono: Laitat pyynnöt jonoon lähettääksesi ne hallitulla tahdilla eikä välittömästi. Jonotus tasoittaa äkillisiä liikennepurskeita: Vaikka 1 000 pyyntöä saapuisi kerralla, jono vapauttaa ne rajan alapuolella. Tällä tavalla estät 429:n, niin sinun ei tarvitse huolehtia sen korjaamisesta.
Samanaikaisuusraja: Rajoitat, kuinka monta pyyntöä on "ilmassa" samanaikaisesti. Rajoittamattomat rinnakkaiset pyynnöt täyttävät nopeasti RPM- ja TPM-rajat. Kohtuullinen samanaikaisuuskatto (esim. enintään 10 samanaikaista pyyntöä) ylläpitää rajoituksia ja tekee järjestelmästä ennustettavan.
Virtakatkaisija: Jos palveluntarjoaja palauttaa jatkuvasti 500/529, sen sijaan, että yrittäisit sinnikkäästi jokaista pyyntöä, "katkaiset piirin" hetkeksi ja epäonnistut nopeasti lähettämättä sitä koskaan. Odotuksen jälkeen kytket piirin takaisin päälle ja yrität. Tämä malli estää järjestelmääsi kaatumasta tilapäisen palveluntarjoajan vian sattuessa.
Yhdessä nämä kolme luovat järjestelmätason joustavuutta, joka ylittää yhden puhelun uudelleenyrityslogiikan. Pienessä mittakaavassa SDK:n automaattinen uudelleenyritys riittää; Kun mittakaava kasvaa, jonoista, samanaikaisuudesta ja katkaisijasta tulee välttämättömiä. Niillä kaikilla on sama yhteinen tavoite: heijastaa väliaikaista ongelmaa käyttäjälle ei kaatumisena, vaan näkymättömänä muutaman sekunnin viiveenä.
Yhteenvetona
429 palauttaa, kun nopeusrajoitukset (RPM/ITPM/OTPM) ylittyvät; Tämä on väliaikainen virhe, ja sitä yritetään uudelleen käyttämällä uudelleenyritystä jälkeen ja eksponentiaalista perääntymistä + värinää. 500 ja 529 ovat myös väliaikaisia; 400/401/403/404 on pyyntö/identiteettiongelma, eikä sitä voi ratkaista yrittämällä uudelleen. Vankka virtaus jakaa virheet näihin kahteen ryhmään, yrittää rajoitetun määrän kertoja, tarkkailee rajaa edestä ja näyttää rauhalliset viestit käyttäjälle.
Sovellustehtävä
Harkitse integraatiotasi. (1) Luettelo virhekoodit, joita saatat kohdata, ja jaa ne "uudelleen yritettäväksi / pysyväksi". (2) Kirjoita ylös eksponentiaalinen takaisinvetosuunnitelmasi (alkupito, kerroin, yläraja, värinä). (3) Määritä, miten yrität uudelleen -otsikkoa käytetään. (4) Kirjoita kohtelias viesti, joka näytetään käyttäjälle, kun uudelleenyritykset ovat loppuneet.
tarkistuslista
- [ ] Osaan selittää RPM/ITPM/OTPM rajat ja 429.
- [ ] Pystyn soveltamaan logiikkaa eksponentiaalinen perääntyminen + värinä + uudelleenyritys-jälkeen.
- [ ] Voin luokitella virhekoodit uudelleen yritettäväksi/pysyviksi.
- [ ] Tiedän, että meidän ei pidä yrittää jokaista virhettä.
- [ ] Raaka virheen sijaan voin näyttää käyttäjälle rauhallisen, toimintaan suuntautuneen viestin.