लाभ:
- गति सीमा (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 (दर सीमा) एक अस्थायी र पुन: प्रयास त्रुटि हो। सही प्रतिक्रिया भनेको अनुरोधको लागि केही समय पर्खनु र पुन: प्रयास गर्नु हो। तर निरन्तर पर्खनु पर्याप्त छैन; यदि सबैले एकै समयमा पुन: प्रयास गरे भने, सीमा फेरि पुग्नेछ। समाधान घातीय ब्याकअफ हो: प्रत्येक असफल प्रयासको साथ द्रुत रूपमा प्रतिक्षा समय बढाउँदै।
# एक्सपोनेन्शियल ब्याकअफ तर्क परीक्षण १ → ४२९ → पर्खनुहोस् १ सेकेन्ड परीक्षण २ → ४२९ → पर्खनुहोस् २ सेकेन्ड परीक्षण ३ → ४२९ → पर्खनुहोस् ४ सेकेन्ड परीक्षण ४ → ४२९ → पर्खनुहोस् 8 सेकेन्ड (+ सानो अनियमित "जिटर")... छोड्नुहोस् र धेरैजसो परीक्षण पछि रिपोर्ट गर्नुहोस्
यसमा थोरै अनियमितता (जिटर) थप्दा एकै समयमा पुन: प्रयास गर्ने प्रयास गर्दा अनुरोधहरू टक्कर हुनबाट रोक्छ। थप रूपमा, 429 प्रतिक्रियाले प्राय: 'पुनः प्रयास पछि' हेडर बोक्छ: "यस धेरै सेकेन्डमा पुन: प्रयास गर्नुहोस्"। यस शीर्षकको सम्मान गर्नु अन्धाधुन्ध पर्खनु भन्दा बढी सही छ।
सावधानी: जब तपाइँ 429 पाउनुहुन्छ, "थप अनुरोधहरू पठाएर यसलाई जबरजस्ती" ले स्थितिलाई अझ खराब बनाउनेछ; सीमा भरिने क्रम जारी छ र कुनै पनि अनुरोधहरू जाँदैनन्। सही प्रतिक्रिया रिट्रीट हो, एक्सेलेरेशन होइन। शुभ समाचार: धेरैजसो आधिकारिक SDK हरू स्वचालित रूपमा 429 र सर्भर त्रुटिहरू एक ब्याकअफको साथ पुन: प्रयास गर्नुहोस् — म्यानुअल रूपमा स्थापना गर्नु अघि SDK को यो व्यवहार प्रयोग गर्नुहोस्।
HTTP त्रुटि कोडहरू वर्गीकरण गर्दै
हरेक गल्ती एउटै हुदैन । आलोचनात्मक भिन्नता: के यसलाई पुन: प्रयास गर्न सकिन्छ वा यो अनुरोध/पहिचान मुद्दा हो?
कोड
अर्थ
के यो फेरि प्रयास गर्न सकिन्छ?
सही प्रतिक्रिया
४००
अमान्य अनुरोध (ढाँचा/पैरामिटर त्रुटि)
छैन
अनुरोध सच्याउनुहोस्; फेरि उही नपठाउनुहोस्
४०१
प्रमाणीकरण त्रुटि (कुञ्जी अमान्य/हराइरहेको)
छैन
कुञ्जी/शीर्षक ठीक गर्नुहोस्
४०३
कुनै प्राधिकरण छैन (मोडल/सुविधामा पहुँच छैन)
छैन
अनुमति / दायरा जाँच गर्नुहोस्
४०४
फेला परेन (गलत मोडेल ID/अन्तबिन्दु)
छैन
सही मोडेल आईडी/ठेगाना
४२९
गति सीमा नाघ्यो
हो
रिट्रीट + पुन: प्रयास पछि
५००
सर्भर त्रुटि
हो
रिट्रीट संग पुन: प्रयास गर्नुहोस्
५२९
सर्भर ओभरलोड भयो
हो
रिट्रीट संग पुन: प्रयास गर्नुहोस्
सुनौलो नियम: ४२९, ५०० र ५२९ अस्थायी हुन्; यसलाई फिर्ता लिएर फेरि प्रयास गरिएको छ। 400, 401, 403, 404 अनुरोध/पहिचान मुद्दाहरू हुन्; पुन: प्रयास गर्दा यसको समाधान हुँदैन, र यसले प्रयास बर्बाद गर्दछ। तपाईंको कोडले यी दुई समूहहरू बीचको भिन्नता छुट्याउनुपर्छ।
चरण-दर-चरण: टिकाऊ कल
- अनुरोध पेश गर्नुहोस्। यदि सफल भएमा, जारी राख्नुहोस्।
- त्रुटि कोड वर्गीकृत गर्नुहोस्। के यो फेरि प्रयास गर्न सकिन्छ?
- यदि प्रयास गर्न मिल्छ भने: पुन: प्रयास-पछि पछ्याउनुहोस्, एक्सपोनेन्शियल ब्याकअफ + जिटर लागू गर्नुहोस्, सीमित संख्यामा प्रयास गर्नुहोस् (जस्तै ५ अधिकतम)।
- यदि प्रयास गरिएन भने: फिक्स (ढाँचा/कुञ्जी) र रोक्नुहोस्; लूपमा उही गल्ती अनुरोध दोहोर्याउनुहोस्।
- त्याग गर्ने विचार गर्नुहोस्। यदि n प्रयासहरू पछि पनि असफल भएमा, प्रयोगकर्तालाई विनम्र सन्देश देखाउनुहोस् र घटना लग गर्नुहोस् (ट्र्याकिङ इकाई 11)।
# बलियो कल pseudo-codedene = 0repeat: response = request_at() if response.success: जवाफ फर्काउनुहोस् यदि response.code [429, 500, 529] मा र प्रयास गर्नुहोस् < 5: wait = retry_after ?? (२ ^ प्रयास सेकेन्ड + जिटर) निद्रा (पर्खनुहोस्); प्रयास गर्नुहोस् += 1; git फेरि यदि response.code [400, 401, 403, 404] मा: save_error(response); फिर्ता गर्नुहोस् "अनुरोध निश्चित हुनुपर्छ" फिर्ता "स्थायी त्रुटि, पछि प्रयास गर्नुहोस्"
# प्रयोगकर्तालाई विनम्र प्रतिक्रिया (पुनः प्रयासहरू समाप्त भएपछि) "म अहिले व्यस्त छु, मैले तपाईंको अनुरोधलाई प्रशोधन गर्न सकिन। छिट्टै पुन: प्रयास गर्नुहोस्, वा मैले तपाईंको अनुरोध सुरक्षित गरेको छु, म तयार भएपछि तपाईंलाई फिर्ता आउनेछु।"
कमजोर प्रम्प्ट / बलियो प्रम्प्ट (यहाँ: त्रुटि सन्देश डिजाइन)
# कमजोर (प्रयोगकर्तालाई कच्चा त्रुटि देखाउँदछ)"त्रुटि 429: दर_सीमा_त्रुटि"
# स्ट्रङ्ग (प्रयोगकर्ता-मैत्री, आश्वस्त, कार्य-सुझाव) "प्रणालीमा अस्थायी भीड थियो। हामीले तपाईंको अनुरोध सुरक्षित रूपमा प्राप्त गरेका छौं र यसलाई स्वचालित रूपमा पुन: प्रयास गरिँदैछ। यदि परिणाम केही सेकेन्डमा देखा परेन भने, तपाईंले पृष्ठलाई रिफ्रेस गर्न सक्नुहुन्छ।"
अन्तिम प्रयोगकर्तालाई कच्चा प्राविधिक त्रुटि प्रकट गर्नाले विश्वासलाई कमजोर बनाउँछ र सुरक्षा जोखिम हुन सक्छ। त्रुटिहरूलाई आन्तरिक रूपमा वर्गीकृत गर्नुहोस् र प्रयोगकर्तालाई शान्त, कार्य-उन्मुख सन्देश दिनुहोस्; रेकर्डको लागि प्राविधिक विवरण मात्र लेख्नुहोस्।
तीन मिनी केसहरू
केस १ - ट्राफिक विस्फोटमा डुङ्गा दुर्घटनाग्रस्त भयो। एक ग्राहक सेवा बोटले अभियानको दिनमा बढ्दो ट्राफिकमा 429 प्राप्त गर्यो; कोडमा कुनै पुन: प्रयास गरिएको थिएन, प्रत्येक त्रुटि प्रयोगकर्तालाई "त्रुटि" को रूपमा सीधै प्रतिबिम्बित गरिएको थियो। तिनीहरूले घातीय रिट्रेसमेन्ट + पुन: प्रयास-पछि थपे; उही ट्राफिकको साथ, अनुरोधहरू धेरै सेकेन्डको ढिलाइसँग पारित भयो, प्रयोगकर्ताले कुनै त्रुटिहरू देखेनन्।
केस २ — लूपमा ४०० कोसिस गर्दै। अमान्य मोडेल ID को कारणले एकीकरणले 404 प्राप्त गरिरहेको थियो, तर सबै त्रुटिहरूलाई "अस्थायी" को रूपमा व्यवहार गर्दै र अनन्त लुपमा पुन: प्रयास गरिरहेको थियो; लग सुन्नियो र अनावश्यक भार सिर्जना भयो। तिनीहरूले त्रुटि वर्गीकरण थपे: 404 स्थायी मानिन्छ, लुप रोकिएको छ र मोडेल ID सच्याइन्छ। पाठ: हरेक गल्ती फेरि नगर्नुहोस्।
केस ३ - अगाडिबाट सीमा प्रबन्ध गर्दै। डाटा संवर्धन कार्य लगातार ४२९ सीमामा चलिरहेको थियो। तिनीहरूले एक्स-रेटलिमिट-बाँकी हेडरलाई पछ्याए र कोटा अनुसार ट्राफिक थ्रोटल गरे। त्यसैले तिनीहरूले कुनै पनि 429 s नलिई, सीमा भन्दा तल एक स्थिर गति राखे; काम अधिक अनुमानित र छिटो भयो।
सामान्य गल्तीहरू
- 429 मा गति बढ्दै: स्थिति खराब बनाउँछ; रिट्रीटमा स्विच गर्नुहोस्।
- प्रत्येक त्रुटि पुन: प्रयास गर्दै: 400/401/404 स्थायी छ; फेरि प्रयास गर्नु बेकार हो।
- निश्चित प्रतीक्षा प्रयोग गर्दै: टक्कर सिर्जना गर्दछ; घातांक + जिटर प्रयोग गर्नुहोस्।
- 'पुनः प्रयास पछि' लाई बेवास्ता गर्दै: प्रदायकले तोकेको समयको पालना गर्नु सबैभन्दा सही हो।
- प्रयोगकर्तालाई कच्चा त्रुटि प्रकट गर्दै: विश्वास हल्लाउँछ, कमजोरीहरू सिर्जना गर्दछ; भित्र वर्गीकरण गर्नुहोस्।
- असीमित पुन: प्रयासहरू: माथिल्लो सीमा सेट गर्नुहोस् (जस्तै 5 पुन: प्रयासहरू); त्यसपछि दयालु रूपमा छोड्नुहोस्।
गहिरो: कतारमा, एकरूपता, र सर्किट ब्रेकरहरू
एकल इच्छाको सहनशीलता पहिलो चरण हो; वास्तविक परिपक्वता भनेको सीमा नछोडिकन ठूलो संख्यामा अनुरोधहरू व्यवस्थापन गर्नु हो। तीन अवधारणाहरू यहाँ खेल्न आउँछन्।
कतार: तपाईंले अनुरोधहरूलाई तुरुन्तै नभई नियन्त्रित गतिमा पठाउनको लागि लाइनमा राख्नुहुन्छ। लामबद्ध गर्नाले ट्राफिकको अचानक भत्कनालाई सहज बनाउँछ: 1,000 अनुरोधहरू एकै पटक आइपुगे पनि, लाइनले तिनीहरूलाई सीमाभन्दा कम दरमा रिलिज गर्नेछ। यस तरिकाले तपाइँ 429 लाई रोक्न सक्नुहुन्छ, त्यसपछि तपाइँ यसलाई ठीक गर्ने बारे चिन्ता गर्नुपर्दैन।
समवर्ती सीमा: तपाइँ एकै समयमा "हावामा" कति अनुरोधहरू छन् भनेर सीमित गर्नुहुन्छ। असीमित समानान्तर अनुरोधहरूले द्रुत रूपमा RPM र TPM सीमाहरू भर्छन्। एक उचित समवर्ती छत (जस्तै 10 भन्दा बढी समवर्ती अनुरोधहरू) दुवैले सीमाहरू कायम राख्छ र प्रणालीलाई पूर्वानुमानयोग्य बनाउँछ।
सर्किट ब्रेकर: यदि प्रदायकले 500/529 फिर्ता गरिरहन्छ भने, प्रत्येक अनुरोधलाई कडाइका साथ प्रयास गर्नुको सट्टा, तपाईंले केही समयको लागि "सर्किट तोड्नुहोस्" र अनुरोधलाई कहिल्यै नपठाई तुरुन्तै असफल गर्नुहुन्छ। एक पर्खाइ पछि, तपाइँ सर्किट फिर्ता खोल्नुहोस् र प्रयास गर्नुहोस्। यो ढाँचाले तपाइँको प्रणालीलाई अस्थायी प्रदायक विफलताको घटनामा क्र्यास हुनबाट रोक्छ।
सँगै, यी तीनले एकल कलको पुन: प्रयास तर्क भन्दा बाहिर प्रणाली-स्तर लचिलोपन स्थापना गर्दछ। सानो स्तरमा, SDK को स्वचालित पुन: प्रयास पर्याप्त छ; मापन बढ्दै जाँदा, लामबद्ध, समरूपता, र सर्किट ब्रेकर अपरिहार्य हुन्छ। तिनीहरू सबैको एउटै साझा लक्ष्य छ: प्रयोगकर्तालाई अस्थायी समस्यालाई दुर्घटनाको रूपमा होइन, तर केही सेकेन्डको अदृश्य ढिलाइको रूपमा प्रतिबिम्बित गर्न।
संक्षेपमा
गति सीमा (RPM/ITPM/OTPM) नाघेको अवस्थामा 429 फिर्ता हुन्छ; यो एक अस्थायी त्रुटि हो र पुन: प्रयास पछि र घातांक ब्याकअफ + जिटर प्रयोग गरी पुन: प्रयास गरिनेछ। ५०० र ५२९ पनि अस्थायी छन्; 400/401/403/404 एक अनुरोध/पहिचान मुद्दा हो र पुन: प्रयास गरेर समाधान गर्न सकिँदैन। एक बलियो प्रवाहले यी दुई समूहहरूमा त्रुटिहरू अलग गर्दछ, सीमित संख्यामा प्रयास गर्दछ, अगाडिबाट सीमा निगरानी गर्दछ र प्रयोगकर्तालाई शान्त सन्देशहरू देखाउँदछ।
आवेदन कार्य
आफ्नो एकीकरण विचार गर्नुहोस्। (१) तपाईंले सामना गर्न सक्ने त्रुटि कोडहरू सूचीबद्ध गर्नुहोस् र तिनीहरूलाई "पुनः प्रयासयोग्य / स्थायी" मा विभाजन गर्नुहोस्। (२) आफ्नो घातीय पुलब्याक योजना (प्रारम्भिक होल्ड, गुणांक, क्याप, जिटर) लेख्नुहोस्। (३) पुन: प्रयास पछि हेडर कसरी प्रयोग गर्ने भनेर निर्दिष्ट गर्नुहोस्। (४) पुन: प्रयासहरू समाप्त भएपछि प्रयोगकर्तालाई देखाइने विनम्र सन्देश लेख्नुहोस्।
चेकलिस्ट
- [ ] म RPM/ITPM/OTPM सीमाहरू र 429 व्याख्या गर्न सक्छु।
- [ ] म घातीय रिट्रीट + जिटर + पुन: प्रयास-पछिको तर्क लागू गर्न सक्छु।
- [] म त्रुटि कोडहरूलाई पुन: प्रयासयोग्य/स्थायी रूपमा वर्गीकृत गर्न सक्छु।
- [ ] मलाई थाहा छ कि हामीले हरेक गल्ती प्रयास गर्नु हुँदैन।
- कच्चा त्रुटिको सट्टा, म प्रयोगकर्तालाई शान्त, कार्य-उन्मुख सन्देश देखाउन सक्छु।