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