స్పీడ్ లిమిట్స్ మరియు రెసిలెంట్ ఎర్రర్ మేనేజ్‌మెంట్

లాభాలు:

• వేగ పరిమితులు (RPM/ITPM/OTPM) మరియు 429 ఎర్రర్‌లను అర్థం చేసుకోవచ్చు
• ఎక్స్‌పోనెన్షియల్ బ్యాక్‌ఆఫ్‌ని అమలు చేస్తుంది మరియు మళ్లీ ప్రయత్నించిన తర్వాత మళ్లీ ప్రయత్నించండి
• సాధారణ HTTP లోపం కోడ్‌లను సరిగ్గా వర్గీకరిస్తుంది మరియు నిర్వహిస్తుంది (400/401/429/500/529)

ఉత్పత్తి వాతావరణంలో, ఏ API అన్ని సమయాలలో సంపూర్ణంగా స్పందించదు. కొన్నిసార్లు మీరు చాలా త్వరగా అభ్యర్థనలను పంపుతారు మరియు పరిమితిని చేరుకుంటారు; కొన్నిసార్లు సర్వర్ తాత్కాలికంగా బిజీగా ఉంటుంది; కొన్నిసార్లు మీ అభ్యర్థన మొదటి నుండి తప్పుగా ఉంటుంది. ఔత్సాహిక ప్రయత్నం నుండి ఘనమైన ఏకీకరణను వేరు చేసేది ఏమిటంటే, ఇది ఈ పరిస్థితులను ఊహాత్మకంగా మరియు స్వయంచాలకంగా నిర్వహిస్తుంది. ఈ యూనిట్‌లో మీరు రేట్ పరిమితులు (RPM/ITPM/OTPM), 429 ఎర్రర్, ఎక్స్‌పోనెన్షియల్ బ్యాక్‌ఆఫ్‌తో మళ్లీ ప్రయత్నించండి మరియు సాధారణ HTTP ఎర్రర్ కోడ్‌ల సరైన వర్గీకరణ గురించి నేర్చుకుంటారు. లక్ష్యం: వినియోగదారు ఎప్పటికీ గమనించని విధంగా బలమైన ప్రవాహాన్ని నిర్మించడం.

వేగ పరిమితులు ఏమిటి?

నిర్ణీత వ్యవధిలో స్విచ్ ఎంత పని చేయగలదో ప్రొవైడర్ పరిమితం చేస్తారు. ఈ రక్షణ; ఇది ఇన్‌ఫ్రాస్ట్రక్చర్‌ను మరియు మిమ్మల్ని ఆకస్మిక ఖర్చు పేలుళ్ల నుండి రక్షిస్తుంది. మూడు సాధారణ రకాల పరిమితులు ఉన్నాయి:

• RPM (నిమిషానికి అభ్యర్థనలు): నిమిషానికి అభ్యర్థనల సంఖ్య.
• ITPM (నిమిషానికి ఇన్‌పుట్ టోకెన్‌లు): నిమిషానికి ప్రాసెస్ చేయగల ఇన్‌పుట్ టోకెన్.
• OTPM (నిమిషానికి అవుట్‌పుట్ టోకెన్‌లు): నిమిషానికి ఉత్పత్తి చేయగల అవుట్‌పుట్ టోకెన్.

మీరు ఈ పరిమితుల్లో దేనినైనా మించిపోయినట్లయితే, ప్రొవైడర్ అభ్యర్థనను తిరస్కరిస్తారు మరియు 429 ఎర్రర్ కోడ్‌ను అందిస్తారు. పరిమితులు సాధారణంగా మీ ఖాతా స్థాయి (టైర్) ఆధారంగా మారుతూ ఉంటాయి మరియు కాలక్రమేణా పెంచవచ్చు.

చిట్కా: మీరు ప్రతిస్పందన శీర్షికల నుండి పరిమితిని చేరుకున్నప్పుడు మీరు చూడవచ్చు. చాలా మంది ప్రొవైడర్లు మీ మిగిలిన కోటాను x-ratelimit-remaining-* వంటి హెడర్‌లతో నివేదిస్తారు. ఈ విలువలను పర్యవేక్షించడం మరియు ముందు ట్రాఫిక్‌ను అడ్డుకోవడం అనేది 429ని పొందకుండా సమస్యను నివారించడానికి అత్యంత పరిణతి చెందిన మార్గం.

429 మరియు ఎక్స్‌పోనెన్షియల్ రీట్రేస్‌మెంట్

429 (రేటు పరిమితి) అనేది తాత్కాలిక మరియు మళ్లీ ప్రయత్నించదగిన లోపం. అభ్యర్థన కోసం కొంతకాలం వేచి ఉండి, మళ్లీ ప్రయత్నించడం సరైన ప్రతిస్పందన. కానీ నిరంతర నిరీక్షణ సరిపోదు; అందరూ ఒకే సమయంలో మళ్లీ ప్రయత్నిస్తే, పరిమితి మళ్లీ చేరుకుంటుంది. దీనికి పరిష్కారం ఎక్స్‌పోనెన్షియల్ బ్యాక్‌ఆఫ్: ప్రతి విఫల ప్రయత్నంతో నిరీక్షణ సమయాన్ని విపరీతంగా పెంచడం.

# ఎక్స్‌పోనెన్షియల్ బ్యాక్‌ఆఫ్ లాజిక్ ట్రయల్ 1 → 429 → వేచి ఉండండి 1 సెకను ట్రయల్ 2 → 429 → వేచి ఉండండి 2 సెకన్ల ట్రయల్ 3 → 429 → వేచి ఉండండి 4 సెకన్ల ట్రయల్ 4 → 429 → 8 సెకన్‌లు వేచి ఉండండి

దీనికి కొద్దిగా యాదృచ్ఛికత (జిట్టర్) జోడించడం వలన అదే సమయంలో మళ్లీ ప్రయత్నించడానికి ప్రయత్నించినప్పుడు అభ్యర్థనలు ఢీకొనడాన్ని నిరోధిస్తుంది. అదనంగా, 429 ప్రతిస్పందన తరచుగా `రీట్రీ-ఆఫ్టర్` హెడర్‌ను కలిగి ఉంటుంది: "ఇన్ని సెకన్లలో మళ్లీ ప్రయత్నించండి". గుడ్డిగా వేచి ఉండటం కంటే ఈ శీర్షికను గౌరవించడం చాలా ఖచ్చితమైనది.

హెచ్చరిక: మీరు 429ని పొందినప్పుడు, "మరిన్ని అభ్యర్థనలను పంపడం ద్వారా బలవంతం చేయడం" పరిస్థితిని మరింత దిగజార్చుతుంది; పరిమితి పూరించబడుతూనే ఉంది మరియు అభ్యర్థనలు ఏవీ అమలు చేయబడవు. సరైన ప్రతిస్పందన తిరోగమనం, త్వరణం కాదు. శుభవార్త: చాలా అధికారిక SDKలు స్వయంచాలకంగా 429ని మళ్లీ ప్రయత్నిస్తాయి మరియు బ్యాక్‌ఆఫ్‌తో సర్వర్ లోపాలు — మాన్యువల్‌గా ఇన్‌స్టాల్ చేసే ముందు SDK యొక్క ఈ ప్రవర్తనను ఉపయోగించండి.

HTTP ఎర్రర్ కోడ్‌లను వర్గీకరిస్తోంది

ప్రతి తప్పు ఒకేలా ఉండదు. క్లిష్టమైన వ్యత్యాసం: దీన్ని మళ్లీ ప్రయత్నించవచ్చా లేదా అభ్యర్థన/గుర్తింపు సమస్యా?

కోడ్

అర్థం

మళ్లీ ప్రయత్నించవచ్చా?

సరైన ప్రతిస్పందన

400

చెల్లని అభ్యర్థన (ఫార్మాట్/పారామీటర్ లోపం)

సంఖ్య

అభ్యర్థనను సరిచేయండి; మళ్లీ అదే పంపవద్దు

401

ప్రమాణీకరణ లోపం (కీ చెల్లదు/తప్పిపోయింది)

సంఖ్య

కీ/శీర్షికను పరిష్కరించండి

403

అధికారం లేదు (మోడల్/ఫీచర్‌కి యాక్సెస్ లేదు)

సంఖ్య

అనుమతులు/పరిధిని తనిఖీ చేయండి

404

కనుగొనబడలేదు (తప్పు మోడల్ ID/ఎండ్ పాయింట్)

సంఖ్య

సరైన మోడల్ ID/చిరునామా

429

వేగ పరిమితి మించిపోయింది

అవును

తిరోగమనం + తర్వాత మళ్లీ ప్రయత్నించండి

500

సర్వర్ లోపం

అవును

తిరోగమనంతో మళ్లీ ప్రయత్నించండి

529

సర్వర్ ఓవర్‌లోడ్ చేయబడింది

అవును

తిరోగమనంతో మళ్లీ ప్రయత్నించండి

గోల్డెన్ రూల్: 429, 500 మరియు 529 తాత్కాలికమైనవి; ఇది ఉపసంహరణతో మళ్లీ ప్రయత్నించబడింది. 400, 401, 403, 404 అభ్యర్థన/గుర్తింపు సమస్యలు; మళ్లీ ప్రయత్నించినా అది పరిష్కరించబడదు మరియు అది శ్రమను వృధా చేస్తుంది. మీ కోడ్ తప్పనిసరిగా ఈ రెండు సమూహాల మధ్య తేడాను గుర్తించాలి.

దశల వారీగా: మన్నికైన కాల్

1. అభ్యర్థనను సమర్పించండి. విజయవంతమైతే, కొనసాగించండి.
2. లోపం కోడ్‌ను వర్గీకరించండి. మళ్లీ ప్రయత్నించవచ్చా?
3. ప్రయత్నించగలిగితే: మళ్లీ ప్రయత్నించండి-తర్వాత, ఎక్స్‌పోనెన్షియల్ బ్యాక్‌ఆఫ్ + జిట్టర్‌ని వర్తింపజేయండి, పరిమిత సంఖ్యలో (ఉదా. 5 గరిష్టంగా) ప్రయత్నించండి.
4. ప్రయత్నించకపోతే: పరిష్కరించండి (ఫార్మాట్/కీ) మరియు ఆపండి; లూప్‌లో అదే తప్పు అభ్యర్థనను పునరావృతం చేయవద్దు.
5. వదులుకోవడాన్ని పరిగణించండి. n ప్రయత్నాల తర్వాత కూడా విఫలమైతే, వినియోగదారుకు మర్యాదపూర్వక సందేశాన్ని చూపండి మరియు ఈవెంట్‌ను లాగ్ చేయండి (ట్రాకింగ్ యూనిట్ 11).

# బలమైన కాల్ pseudo-codedene = 0repeat: response = request_at() if response.success: response.code in [429, 500, 529] మరియు ప్రయత్నించండి < 5: wait = retry_after ?? (2^ సెకను + జిట్టర్ ప్రయత్నించండి) నిద్ర(వేచి ఉండండి); += 1 ప్రయత్నించండి; [400, 401, 403, 404]లో response.code అయితే మళ్లీ git చేయండి: save_error(response); రిటర్న్ "అభ్యర్థన తప్పక పరిష్కరించబడాలి" రిటర్న్ "శాశ్వత లోపం, తర్వాత ప్రయత్నించండి"

# వినియోగదారుకు మర్యాదపూర్వక అభిప్రాయం (మళ్లీ ప్రయత్నాలు అయిపోయినప్పుడు) "నేను ప్రస్తుతం బిజీగా ఉన్నాను, నేను మీ అభ్యర్థనను ప్రాసెస్ చేయలేకపోయాను. త్వరలో మళ్లీ ప్రయత్నించండి, లేదా నేను మీ అభ్యర్థనను సేవ్ చేసాను, అది సిద్ధంగా ఉన్నప్పుడు నేను మిమ్మల్ని సంప్రదిస్తాను."

బలహీనమైన ప్రాంప్ట్ / బలమైన ప్రాంప్ట్ (ఇక్కడ: ఎర్రర్ మెసేజ్ డిజైన్)

# బలహీనత (వినియోగదారునికి ముడి లోపాన్ని ప్రదర్శిస్తుంది)"లోపం 429: రేటు_పరిమితి_లోపం"

# STRONG (యూజర్-ఫ్రెండ్లీ, భరోసా, చర్య-సూచించేది) "సిస్టమ్‌లో తాత్కాలిక రద్దీ ఏర్పడింది. మేము మీ అభ్యర్థనను సురక్షితంగా స్వీకరించాము మరియు అది స్వయంచాలకంగా మళ్లీ ప్రయత్నించబడుతోంది. కొన్ని సెకన్లలో ఫలితం కనిపించకపోతే, మీరు పేజీని రిఫ్రెష్ చేయవచ్చు."

తుది వినియోగదారుకు ముడి సాంకేతిక లోపాన్ని బహిర్గతం చేయడం రెండూ నమ్మకాన్ని దెబ్బతీస్తాయి మరియు భద్రతా దుర్బలత్వం కావచ్చు. అంతర్గతంగా లోపాలను వర్గీకరించండి మరియు వినియోగదారుకు ప్రశాంతమైన, చర్య-ఆధారిత సందేశాన్ని అందించండి; కేవలం రికార్డు కోసం సాంకేతిక వివరాలను వ్రాయండి.

మూడు మినీ కేసులు

కేసు 1 - ట్రాఫిక్ పేలుడులో పడవ కూలిపోయింది. ప్రచార రోజున ఉప్పెన ట్రాఫిక్‌లో కస్టమర్ సర్వీస్ బోట్ 429 అందుకుంది; కోడ్‌లో మళ్లీ ప్రయత్నించలేదు, ప్రతి లోపం వినియోగదారుకు నేరుగా "ఎర్రర్"గా ప్రతిబింబిస్తుంది. వారు ఎక్స్‌పోనెన్షియల్ రీట్రేస్‌మెంట్ + మళ్లీ ప్రయత్నించిన తర్వాత; అదే ట్రాఫిక్‌తో, అభ్యర్థనలు చాలా సెకన్ల ఆలస్యంతో ఆమోదించబడ్డాయి, వినియోగదారుకు ఎలాంటి లోపాలు కనిపించలేదు.

కేస్ 2 — లూప్‌లో 400ని ప్రయత్నిస్తోంది. చెల్లని మోడల్ ID కారణంగా ఒక ఇంటిగ్రేషన్ 404ని పొందుతోంది, కానీ అన్ని లోపాలను "తాత్కాలికం"గా పరిగణిస్తోంది మరియు అనంతమైన లూప్‌లో మళ్లీ ప్రయత్నిస్తోంది; లాగ్ వాపుగా మారింది మరియు అనవసరమైన లోడ్ సృష్టించబడింది. వారు దోష వర్గీకరణను జోడించారు: 404 శాశ్వతంగా పరిగణించబడుతుంది, లూప్ నిలిపివేయబడింది మరియు మోడల్ ID సరిదిద్దబడింది. పాఠం: ప్రతి తప్పును మళ్లీ ప్రయత్నించవద్దు.

కేస్ 3 - ముందు నుండి పరిమితిని నిర్వహించడం. డేటా సుసంపన్నం చేసే పని నిరంతరం 429 పరిమితిలో నడుస్తోంది. వారు x-రేట్లిమిట్-మిగిలిన హెడర్‌ను అనుసరించారు మరియు కోటా ప్రకారం ట్రాఫిక్‌ను తగ్గించారు. కాబట్టి వారు ఎటువంటి 429లను తీసుకోకుండా పరిమితి కంటే కొంచెం దిగువన స్థిరమైన వేగాన్ని కొనసాగించారు; పని మరింత ఊహాజనితంగా మరియు వేగంగా జరిగింది.

సాధారణ తప్పులు

• 429లో వేగం పెరగడం: పరిస్థితిని మరింత దిగజార్చింది; తిరోగమనానికి మారండి.
• ప్రతి లోపాన్ని మళ్లీ ప్రయత్నించడం: 400/401/404 శాశ్వతమైనది; మళ్లీ ప్రయత్నించడం వ్యర్థం.
• స్థిర నిరీక్షణను ఉపయోగించడం: ఘర్షణను సృష్టిస్తుంది; ఎక్స్‌పోనెన్షియల్ + జిట్టర్ ఉపయోగించండి.
• 'తర్వాత మళ్లీ ప్రయత్నించండి'ని విస్మరించడం: ప్రొవైడర్ పేర్కొన్న సమయానికి కట్టుబడి ఉండటం అత్యంత ఖచ్చితమైనది.
• వినియోగదారుకు ముడి లోపాన్ని బహిర్గతం చేయడం: నమ్మకాన్ని కదిలిస్తుంది, దుర్బలత్వాలను సృష్టిస్తుంది; లోపల వర్గీకరించండి.
• అపరిమిత పునఃప్రయత్నాలు: ఎగువ పరిమితిని సెట్ చేయండి (ఉదా. 5 ప్రయత్నాలు); అప్పుడు సరసముగా వదులుకో.

లోతుగా: క్యూయింగ్, కరెన్సీ మరియు సర్క్యూట్ బ్రేకర్లు

ఒకే కోరిక యొక్క ఓర్పు మొదటి అడుగు; అధిక సంఖ్యలో అభ్యర్థనలను పరిమితులను తాకకుండా నిర్వహించడమే నిజమైన పరిపక్వత. ఇక్కడ మూడు భావనలు అమలులోకి వస్తాయి.

క్యూ: మీరు అభ్యర్థనలను తక్షణమే కాకుండా నియంత్రిత వేగంతో పంపడానికి క్యూలో ఉంచారు. క్యూలో ఉండటం వలన అకస్మాత్తుగా ఏర్పడే ట్రాఫిక్‌ను సున్నితంగా చేస్తుంది: ఒకేసారి 1,000 అభ్యర్థనలు వచ్చినప్పటికీ, క్యూ వాటిని పరిమితి కంటే తక్కువ రేటుతో విడుదల చేస్తుంది. ఈ విధంగా మీరు 429ని నిరోధించవచ్చు, ఆపై దాన్ని పరిష్కరించడం గురించి మీరు చింతించాల్సిన అవసరం లేదు.

కరెన్సీ పరిమితి: మీరు ఒకే సమయంలో "ఎయిర్‌లో" ఎన్ని అభ్యర్థనలను పరిమితం చేస్తారు. అపరిమిత సమాంతర అభ్యర్థనలు త్వరగా RPM మరియు TPM పరిమితులను నింపుతాయి. సహేతుకమైన కరెన్సీ సీలింగ్ (ఉదా. 10 కంటే ఎక్కువ ఏకకాల అభ్యర్థనలు) రెండూ పరిమితులను నిర్వహిస్తాయి మరియు సిస్టమ్‌ను ఊహాజనితంగా చేస్తాయి.

సర్క్యూట్ బ్రేకర్: ప్రొవైడర్ 500/529ని తిరిగి ఇస్తూ ఉంటే, ప్రతి అభ్యర్థనను గట్టిగా ప్రయత్నించే బదులు, మీరు కొంతకాలం "సర్క్యూట్‌ను విచ్ఛిన్నం" చేసి, అభ్యర్థనను పంపకుండానే త్వరగా విఫలమవుతారు. వేచి ఉన్న తర్వాత, మీరు సర్క్యూట్‌ను తిరిగి ఆన్ చేసి ప్రయత్నించండి. తాత్కాలిక ప్రొవైడర్ వైఫల్యం సంభవించినప్పుడు మీ సిస్టమ్ క్రాష్ కాకుండా ఈ నమూనా నిరోధిస్తుంది.

ఈ మూడు కలిసి, ఒకే కాల్‌కి మళ్లీ ప్రయత్నించే తర్కాన్ని మించి సిస్టమ్-స్థాయి స్థితిస్థాపకతను ఏర్పరుస్తాయి. చిన్న స్థాయిలో, SDK యొక్క స్వయంచాలక పునఃప్రయత్నం సరిపోతుంది; స్కేల్ పెరిగేకొద్దీ, క్యూయింగ్, కాన్‌కరెన్సీ మరియు సర్క్యూట్ బ్రేకర్ అనివార్యమవుతాయి. వారందరికీ ఒకే సాధారణ లక్ష్యం ఉంది: వినియోగదారుకు తాత్కాలిక సమస్యను క్రాష్‌గా కాకుండా కొన్ని సెకన్ల అదృశ్య ఆలస్యంగా ప్రతిబింబించడం.

సారాంశంలో

వేగ పరిమితులు (RPM/ITPM/OTPM) మించిపోయినప్పుడు 429 తిరిగి వస్తుంది; ఇది తాత్కాలిక లోపం మరియు మళ్లీ ప్రయత్నించిన తర్వాత మరియు ఎక్స్‌పోనెన్షియల్ బ్యాక్‌ఆఫ్ + జిట్టర్ ఉపయోగించి మళ్లీ ప్రయత్నించబడుతుంది. 500 మరియు 529 కూడా తాత్కాలికమైనవి; 400/401/403/404 అభ్యర్థన/గుర్తింపు సమస్య మరియు మళ్లీ ప్రయత్నించడం ద్వారా పరిష్కరించబడదు. బలమైన ప్రవాహం ఈ రెండు సమూహాలలో లోపాలను వేరు చేస్తుంది, పరిమిత సంఖ్యలో సార్లు ప్రయత్నిస్తుంది, ముందు నుండి పరిమితిని పర్యవేక్షిస్తుంది మరియు వినియోగదారుకు ప్రశాంత సందేశాలను చూపుతుంది.

అప్లికేషన్ టాస్క్

మీ ఏకీకరణను పరిగణించండి. (1) మీరు ఎదుర్కొనే ఎర్రర్ కోడ్‌లను జాబితా చేయండి మరియు వాటిని "తిరిగి ప్రయత్నించవచ్చు / శాశ్వతం"గా విభజించండి. (2) మీ ఎక్స్‌పోనెన్షియల్ పుల్‌బ్యాక్ ప్లాన్‌ను వ్రాయండి (ప్రారంభ హోల్డ్, కోఎఫీషియంట్, క్యాప్, జిట్టర్). (3) మళ్లీ ప్రయత్నించిన తర్వాత శీర్షికను ఎలా ఉపయోగించాలో పేర్కొనండి. (4) పునఃప్రయత్నాలు అయిపోయినప్పుడు వినియోగదారుకు ప్రదర్శించబడే మర్యాదపూర్వక సందేశాన్ని వ్రాయండి.

చెక్లిస్ట్

• [ ] నేను RPM/ITPM/OTPM పరిమితులు మరియు 429ని వివరించగలను.
• [ ] నేను ఎక్స్‌పోనెన్షియల్ రిట్రీట్ + జిట్టర్ + రిట్రీ-తర్వాత లాజిక్‌ని అన్వయించగలను.
• [ ] నేను ఎర్రర్ కోడ్‌లను మళ్లీ ప్రయత్నించదగినవి/శాశ్వతమైనవిగా వర్గీకరించగలను.
• [ ] ప్రతి తప్పును మనం ప్రయత్నించకూడదని నాకు తెలుసు.
• [ ] ముడి ఎర్రర్‌కు బదులుగా, నేను వినియోగదారుకు ప్రశాంతమైన, చర్య-ఆధారిత సందేశాన్ని చూపగలను.