लाभ:
- गति सीमा (आरपीएम/आईटीपीएम/ओटीपीएम) और 429 त्रुटियों की व्याख्या कर सकता है
- घातीय बैकऑफ लागू करता है और पुनः प्रयास के बाद पुनः प्रयास करता है
- सामान्य HTTP त्रुटि कोड (400/401/429/500/529) को सही ढंग से वर्गीकृत और संभालता है
उत्पादन परिवेश में, कोई भी एपीआई हर समय पूरी तरह से प्रतिक्रिया नहीं देता है। कभी-कभी आप बहुत जल्दी अनुरोध भेजते हैं और सीमा पार कर जाते हैं; कभी-कभी सर्वर अस्थायी रूप से व्यस्त रहता है; कभी-कभी आपका अनुरोध शुरू से ही गलत होता है। एक ठोस एकीकरण को एक शौकिया प्रयास से अलग करने वाली बात यह है कि यह इन स्थितियों को पूर्वानुमानित और स्वचालित रूप से संभालता है। इस इकाई में आप दर सीमा (आरपीएम/आईटीपीएम/ओटीपीएम), 429 त्रुटि, घातीय बैकऑफ़ के साथ पुनः प्रयास और सामान्य HTTP त्रुटि कोड के उचित वर्गीकरण के बारे में सीखेंगे। लक्ष्य: एक ऐसा प्रवाह बनाना जो इतना मजबूत हो कि उपयोगकर्ता कभी भी उस पर ध्यान न दे सके।
गति सीमाएँ क्या हैं?
प्रदाता यह सीमित करता है कि एक स्विच किसी निश्चित समयावधि में कितना काम कर सकता है। यह सुरक्षा; यह बुनियादी ढांचे और आपको अचानक लागत विस्फोटों से बचाता है। तीन सामान्य प्रकार की सीमाएँ हैं:
- आरपीएम (प्रति मिनट अनुरोध): प्रति मिनट अनुरोधों की संख्या।
- आईटीपीएम (इनपुट टोकन प्रति मिनट): इनपुट टोकन जिसे प्रति मिनट संसाधित किया जा सकता है।
- ओटीपीएम (आउटपुट टोकन प्रति मिनट): आउटपुट टोकन जो प्रति मिनट उत्पादित किया जा सकता है।
यदि आप इनमें से किसी भी सीमा को पार कर जाते हैं, तो प्रदाता अनुरोध को अस्वीकार कर देता है और 429 त्रुटि कोड लौटाता है। सीमाएं आम तौर पर आपके खाते के स्तर (टियर) के आधार पर भिन्न होती हैं और समय के साथ बढ़ाई जा सकती हैं।
टिप: जब आप प्रतिक्रिया हेडर से सीमा के करीब पहुंच रहे हों तो आप देख सकते हैं। अधिकांश प्रदाता आपके शेष कोटा को x-ratelimit-remaining-* जैसे हेडर के साथ रिपोर्ट करते हैं। इन मूल्यों की निगरानी करना और सामने वाले ट्रैफ़िक को रोकना 429 प्राप्त किए बिना समस्या को रोकने का सबसे परिपक्व तरीका है।
429 और एक्सपोनेंशियल रिट्रेसमेंट
429 (दर सीमा) एक अस्थायी और पुनः प्रयास योग्य त्रुटि है। सही प्रतिक्रिया यह है कि अनुरोध के लिए कुछ देर प्रतीक्षा करें और पुनः प्रयास करें। लेकिन निरंतर प्रतीक्षा पर्याप्त नहीं है; यदि हर कोई एक ही समय में दोबारा प्रयास करता है, तो सीमा फिर से पहुंच जाएगी। समाधान घातीय बैकऑफ़ है: प्रत्येक असफल प्रयास के साथ प्रतीक्षा समय को तेजी से बढ़ाना।
# घातीय बैकऑफ लॉजिक परीक्षण 1 → 429 → 1 सेकंड प्रतीक्षा करें परीक्षण 2 → 429 → 2 सेकंड प्रतीक्षा करें परीक्षण 3 → 429 → 4 सेकंड प्रतीक्षा करें परीक्षण 4 → 429 → 8 सेकंड प्रतीक्षा करें (+ छोटा यादृच्छिक "घबराना")... हार मान लें और अधिकतम एन परीक्षणों के बाद रिपोर्ट करें
इसमें थोड़ी सी यादृच्छिकता (घबराहट) जोड़ने से एक ही समय में पुनः प्रयास करने पर अनुरोधों को टकराने से रोका जा सकता है। इसके अतिरिक्त, 429 प्रतिक्रिया में अक्सर 'पुनः प्रयास करें' शीर्षक होता है: "इतने सेकंड में पुनः प्रयास करें"। इस उपाधि का सम्मान करना आँख मूँद कर इंतज़ार करने से अधिक सटीक है।
सावधानी: जब आपको 429 मिलता है, तो "अधिक अनुरोध भेजकर इसे मजबूर करना" स्थिति को और खराब कर देगा; सीमा भरती रहती है और कोई अनुरोध पूरा नहीं होता। सही प्रतिक्रिया पीछे हटना है, त्वरण नहीं। अच्छी खबर: अधिकांश आधिकारिक एसडीके स्वचालित रूप से बैकऑफ़ के साथ 429 और सर्वर त्रुटियों का पुनः प्रयास करते हैं - इसे मैन्युअल रूप से स्थापित करने से पहले एसडीके के इस व्यवहार का उपयोग करें।
HTTP त्रुटि कोड वर्गीकृत करना
हर गलती एक जैसी नहीं होती. महत्वपूर्ण अंतर: क्या इसका पुनः प्रयास किया जा सकता है या यह एक अनुरोध/पहचान मुद्दा है?
कोड
मतलब
क्या इसे दोबारा आज़माया जा सकता है?
सही प्रतिक्रिया
400
अमान्य अनुरोध (प्रारूप/पैरामीटर त्रुटि)
नहीं
अनुरोध ठीक करें; दोबारा वही न भेजें
401
प्रमाणीकरण त्रुटि (कुंजी अमान्य/अनुपलब्ध)
नहीं
कुंजी/शीर्षक ठीक करें
403
कोई प्राधिकरण नहीं (मॉडल/फीचर तक कोई पहुंच नहीं)
नहीं
अनुमतियाँ/दायरा जाँचें
404
नहीं मिला (गलत मॉडल आईडी/एंडपॉइंट)
नहीं
सही मॉडल आईडी/पता
429
गति सीमा पार हो गई
हाँ
पीछे हटना + पुनःप्रयास करना
500
सर्वर त्रुटि
हाँ
पीछे हटने के साथ पुनः प्रयास करें
529
सर्वर ओवरलोड हो गया
हाँ
पीछे हटने के साथ पुनः प्रयास करें
सुनहरा नियम: 429, 500 और 529 अस्थायी हैं; इसे वापसी के साथ फिर से आजमाया जाता है। 400, 401, 403, 404 अनुरोध/पहचान संबंधी मुद्दे हैं; दोबारा प्रयास करने से इसका समाधान नहीं होगा और इससे प्रयास बर्बाद होगा। आपके कोड को इन दोनों समूहों के बीच अंतर करना चाहिए।
चरण दर चरण: टिकाऊ कॉल
- अनुरोध सबमिट करें. यदि सफल हो तो जारी रखें.
- त्रुटि कोड को वर्गीकृत करें. क्या इसे दोबारा आज़माया जा सकता है?
- यदि प्रयास योग्य है: पुनः प्रयास करें का पालन करें, घातीय बैकऑफ़ + जिटर लागू करें, सीमित संख्या में प्रयास करें (उदाहरण के लिए अधिकतम 5)।
- यदि प्रयास नहीं किया गया है: ठीक करें (प्रारूप/कुंजी) और रोकें; लूप में वही गलत अनुरोध न दोहराएं।
- त्याग करने पर विचार करें. यदि n प्रयासों के बाद भी असफल रहता है, तो उपयोगकर्ता को एक विनम्र संदेश दिखाएं और ईवेंट लॉग करें (ट्रैकिंग यूनिट 11)।
# मजबूत कॉल स्यूडो-कोडीन = 0दोहराएँ: प्रतिक्रिया = request_at() यदि प्रतिक्रिया.सफलता: प्रतिक्रिया लौटाएँ यदि प्रतिक्रिया.कोड [429, 500, 529] में और प्रयास करें <5: प्रतीक्षा करें = पुनः प्रयास करें ?? (2^कोशिश सेकंड + घबराना) नींद(प्रतीक्षा); प्रयास करें += 1; यदि प्रतिक्रिया.कोड [400, 401, 403, 404] में है तो फिर से गिट करें: save_error(प्रतिक्रिया); वापसी "अनुरोध को ठीक किया जाना चाहिए" वापसी "स्थायी त्रुटि, बाद में प्रयास करें"
# उपयोगकर्ता को विनम्र प्रतिक्रिया (जब पुनः प्रयास समाप्त हो जाए) "मैं अभी व्यस्त हूं, मैं आपके अनुरोध पर कार्रवाई नहीं कर सका। जल्द ही पुनः प्रयास करें, या मैंने आपका अनुरोध सहेज लिया है, जब यह तैयार हो जाएगा तो मैं आपसे संपर्क करूंगा।"
कमज़ोर संकेत / सशक्त संकेत (यहां: त्रुटि संदेश डिज़ाइन)
# WEAK (उपयोगकर्ता को मूल त्रुटि प्रदर्शित करता है)"त्रुटि 429: दर_सीमा_त्रुटि"
# मजबूत (उपयोगकर्ता-अनुकूल, आश्वस्त करने वाला, कार्रवाई-सुझाव देने वाला) "सिस्टम में एक अस्थायी रुकावट थी। हमें आपका अनुरोध सुरक्षित रूप से प्राप्त हुआ है और इसे स्वचालित रूप से फिर से प्रयास किया जा रहा है। यदि कोई परिणाम कुछ सेकंड के भीतर प्रकट नहीं होता है, तो आप पृष्ठ को ताज़ा कर सकते हैं।"
अंतिम उपयोगकर्ता के सामने मूल तकनीकी त्रुटि का खुलासा करना विश्वास को कमजोर करता है और सुरक्षा भेद्यता हो सकता है। त्रुटियों को आंतरिक रूप से वर्गीकृत करें और उपयोगकर्ता को एक शांत, कार्रवाई-उन्मुख संदेश दें; बस रिकॉर्ड के लिए तकनीकी विवरण लिखें।
तीन मिनी मामले
केस 1 - यातायात विस्फोट में नाव दुर्घटनाग्रस्त हो गई। अभियान के दिन एक ग्राहक सेवा बॉट को 429 ट्रैफ़िक प्राप्त हुआ; कोड में कोई पुनः प्रयास नहीं था, प्रत्येक त्रुटि सीधे उपयोगकर्ता को "त्रुटि" के रूप में दिखाई देती थी। उन्होंने घातीय रिट्रेसमेंट + पुनः प्रयास के बाद जोड़ा; समान ट्रैफ़िक के साथ, अनुरोध कई सेकंड की देरी से पारित हुए, उपयोगकर्ता को कोई त्रुटि नहीं दिखाई दी।
केस 2 - लूप में 400 का प्रयास करना। एक अमान्य मॉडल आईडी के कारण एकीकरण को 404 मिल रहा था, लेकिन सभी त्रुटियों को "क्षणिक" मान रहा था और अनंत लूप में फिर से प्रयास कर रहा था; लॉग सूज गया और अनावश्यक भार पैदा हो गया। उन्होंने त्रुटि वर्गीकरण जोड़ा: 404 को स्थायी माना जाता है, लूप बंद कर दिया जाता है और मॉडल आईडी को सही किया जाता है। सीख: हर गलती दोबारा न करें।
केस 3 - सामने से सीमा का प्रबंधन करना। डेटा संवर्धन कार्य लगातार 429 सीमा पर चल रहा था। उन्होंने एक्स-रेटलिमिट-शेष हेडर का पालन किया और कोटा के अनुसार ट्रैफिक को रोक दिया। इसलिए उन्होंने बिना कोई 429 लिए, सीमा के ठीक नीचे एक स्थिर गति बनाए रखी; काम अधिक पूर्वानुमानित और तेजी से किया गया।
सामान्य गलतियाँ
- 429 में बढ़ती गति: स्थिति को बदतर बना देती है; पीछे हटने पर स्विच करें.
- प्रत्येक त्रुटि का पुन: प्रयास करना: 400/401/404 स्थायी है; दोबारा कोशिश करना बर्बादी है.
- निश्चित प्रतीक्षा का उपयोग करना: टकराव पैदा करता है; एक्सपोनेंशियल + जिटर का प्रयोग करें।
- 'पुनः प्रयास-बाद' को अनदेखा करना: प्रदाता द्वारा निर्दिष्ट समय का अनुपालन करना सबसे सटीक है।
- उपयोगकर्ता को मूल त्रुटि का खुलासा करना: विश्वास को हिलाता है, कमजोरियाँ पैदा करता है; अंदर वर्गीकृत करें.
- असीमित पुनर्प्रयास: एक ऊपरी सीमा निर्धारित करें (उदा. 5 पुनर्प्रयास); फिर शालीनता से त्याग दो।
गहरा: कतारबद्धता, संगामिति, और सर्किट ब्रेकर
एक ही इच्छा का धैर्य पहला कदम है; वास्तविक परिपक्वता बिना किसी सीमा को पार किए बड़ी संख्या में अनुरोधों को प्रबंधित करना है। यहां तीन अवधारणाएं चलन में आती हैं।
कतार: आप अनुरोधों को तुरंत के बजाय नियंत्रित गति से भेजने के लिए उन्हें कतार में रखते हैं। कतार लगाने से अचानक आने वाले ट्रैफ़िक को सुचारू किया जा सकता है: भले ही 1,000 अनुरोध एक साथ आएँ, कतार उन्हें सीमा से कम दर पर जारी करेगी। इस तरह आप 429 को रोकते हैं, फिर आपको इसे ठीक करने के बारे में चिंता करने की ज़रूरत नहीं है।
समवर्ती सीमा: आप एक ही समय में "हवा में" कितने अनुरोधों को सीमित करते हैं। असीमित समानांतर अनुरोध RPM और TPM सीमाएँ शीघ्रता से भर देते हैं। एक उचित समवर्ती सीमा (उदाहरण के लिए 10 से अधिक समवर्ती अनुरोध नहीं) दोनों सीमाएं बनाए रखती हैं और सिस्टम को पूर्वानुमानित बनाती हैं।
सर्किट ब्रेकर: यदि प्रदाता हर अनुरोध को हठपूर्वक प्रयास करने के बजाय 500/529 लौटाता रहता है, तो आप थोड़ी देर के लिए "सर्किट तोड़ देते हैं" और अनुरोध को बिना भेजे ही तुरंत विफल कर देते हैं। प्रतीक्षा के बाद, आप सर्किट को वापस चालू करें और प्रयास करें। यह पैटर्न अस्थायी प्रदाता विफलता की स्थिति में आपके सिस्टम को क्रैश होने से बचाता है।
साथ में, ये तीनों एक कॉल के पुनः प्रयास तर्क से परे सिस्टम-स्तरीय लचीलापन स्थापित करते हैं। छोटे पैमाने पर, एसडीके का स्वचालित पुनः प्रयास पर्याप्त है; जैसे-जैसे पैमाना बढ़ता है, कतारबद्धता, समवर्तीता और सर्किट ब्रेकर अपरिहार्य हो जाते हैं। उन सभी का एक ही सामान्य लक्ष्य है: उपयोगकर्ता को एक अस्थायी समस्या को दुर्घटना के रूप में नहीं, बल्कि कुछ सेकंड की अदृश्य देरी के रूप में प्रतिबिंबित करना।
संक्षेप में
गति सीमा (आरपीएम/आईटीपीएम/ओटीपीएम) पार होने पर 429 रिटर्न; यह एक अस्थायी त्रुटि है और पुनः प्रयास-आफ्टर और एक्सपोनेंशियल बैकऑफ़ + जिटर का उपयोग करके पुनः प्रयास किया जाएगा। 500 और 529 भी अनंतिम हैं; 400/401/403/404 एक अनुरोध/पहचान समस्या है और इसे दोबारा प्रयास करके हल नहीं किया जा सकता है। एक मजबूत प्रवाह इन दो समूहों में त्रुटियों को अलग करता है, सीमित संख्या में प्रयास करता है, सामने से सीमा की निगरानी करता है और उपयोगकर्ता को शांत संदेश दिखाता है।
आवेदन कार्य
अपने एकीकरण पर विचार करें. (1) आपके सामने आने वाले त्रुटि कोडों की सूची बनाएं और उन्हें "पुन: प्रयास योग्य/स्थायी" में अलग करें। (2) अपनी घातीय पुलबैक योजना (प्रारंभिक पकड़, गुणांक, टोपी, घबराना) लिखें। (3) निर्दिष्ट करें कि पुनः प्रयास-आफ्टर हेडर का उपयोग कैसे करें। (4) पुन: प्रयास समाप्त होने पर उपयोगकर्ता को प्रदर्शित किया जाने वाला विनम्र संदेश लिखें।
चेकलिस्ट
- [ ] मैं आरपीएम/आईटीपीएम/ओटीपीएम सीमाएं और 429 समझा सकता हूं।
- [ ] मैं घातीय वापसी + घबराना + पुनः प्रयास के तर्क को लागू कर सकता हूं।
- [ ] मैं त्रुटि कोड को पुनः प्रयास योग्य/स्थायी के रूप में वर्गीकृत कर सकता हूं।
- [ ] मैं जानता हूं कि हमें हर गलती की कोशिश नहीं करनी चाहिए।
- [ ] एक मूल त्रुटि के बजाय, मैं उपयोगकर्ता को एक शांत, कार्रवाई-उन्मुख संदेश दिखा सकता हूं।