एक व्यस्त सेंडर अपने सभी संदेश कतार में आने से पहले अपना अनुरोध बजट खर्च कर सकता है। शेष कोटा पढ़ने से वह और कॉल अस्वीकार होने से पहले धीमा हो सकता है।
Bird मेरी सीमा कैसे तय करता है?
Bird एक बेस रेट, कोई प्लान वृद्धि और फिर संबंधित ग्रुप के लिए कोई ओवरराइड लागू करता है। ओवरराइड अन्य मानों को बदल देता है।
संबंधित endpoints एक ग्रुप साझा करते हैं। किसी send ग्रुप का कोटा समाप्त होने से स्टेटस पढ़ने या webhooks प्रबंधित करने वाले अलग ग्रुप स्वयं समाप्त नहीं होते।
प्रत्येक बजट का दायरा ऑपरेशन पर निर्भर करता है:
| ग्रुप | बजट कौन साझा करता है? |
|---|---|
| प्रोडक्ट sends | उस प्रोडक्ट के लिए संगठन में सभी credentials। |
| प्रबंधन reads, lists और writes | संगठन के भीतर एक ही acting credential से अनुरोध। |
| बिना प्रमाणीकरण वाले login या password reset | एक ही client IP से अनुरोध। |
बिना प्रमाणीकरण वाली सीमाएँ निश्चित थ्रेशोल्ड का उपयोग करती हैं। अलग-अलग endpoints को असाइन किए गए ग्रुप के लिए रेट लिमिट गाइड देखें।
भेजने की सीमाएँ अनुरोधों की गिनती करती हैं, प्राप्तकर्ताओं की नहीं। एक बैच अनुरोध कई संदेश कतार में डाल सकता है। इसके ग्रुप का कोटा अलग हो सकता है।
endpoints बदलने से पहले लाइव कोटा और आप कितने प्राप्तकर्ताओं को ग्रुप कर सकते हैं, इसकी तुलना करें। एक प्राप्तकर्ता वाले बैच से थ्रूपुट में लाभ मिले, यह ज़रूरी नहीं है।
प्रतिक्रिया हेडर कैसे पढ़ें?
कोटा और विंडो के लिए RateLimit-Policy पढ़ें, फिर शेष अनुरोधों और रीसेट तक के समय के लिए RateLimit पढ़ें।
उदाहरण के लिए:
RateLimit-Policy: "email_send";q=1000;w=60
RateLimit: "email_send";r=842;t=35यह उदाहरण 60-सेकंड विंडो में 1,000 अनुरोधों की अनुमति देता है। इसमें 842 अनुरोध शेष हैं, रीसेट तक 35 सेकंड बाकी हैं।
ये संख्याएँ हेडर को दर्शाती हैं। ये कोई निश्चित कोटा नहीं हैं। आपके client को लौटाए गए मान पढ़ें।
| फ़ील्ड | अर्थ |
|---|---|
| उद्धृत नाम | वह ग्रुप जिस पर नीति लागू होती है। |
q | प्रति विंडो अनुमत अनुरोध। |
w | विंडो की अवधि सेकंड में। |
r | शेष अनुरोध। |
t | रीसेट तक सेकंड, टाइमस्टैम्प नहीं। |
एक प्रतिक्रिया में एक से अधिक नीति हो सकती है। अगला अनुरोध शेड्यूल करते समय हर लागू नीति को ध्यान में रखें।
रेट-लिमिट विफलता क्या लौटाती है?
API की दर सीमा पूरी होने पर 429 Too Many Requests लौटता है। इसके साथ Retry-After हेडर में प्रतीक्षा की अवधि सेकंड में दी जाती है। रेट-लिमिट हेडर समाप्त हुए ग्रुप की पहचान करते हैं। इसका शेष कोटा r=0 होता है।
त्रुटि प्रतिक्रिया में ये फ़ील्ड शामिल हैं:
{
"error": {
"type": "rate_limit_error",
"code": "E01003",
"name": "RateLimited"
}
}अपने हैंडलर में type या code को मैच करें। मानव-पठनीय संदेश बिना रिकवरी कार्रवाई बदले बदल सकता है।
मेरा client 429 को कैसे संभाले?
Retry-After तक प्रतीक्षा करें, फिर सीमित backoff नीति के साथ फिर से प्रयास करें। उसी write को दोहराते समय वही idempotency key रखें।
एक ही ग्रुप बजट का उपयोग करने वाले वर्कर्स को समन्वित करें। किसी वर्कर की अंतिम प्रतिक्रिया उन अनुरोधों को ध्यान में नहीं रख सकती जो अन्य वर्कर्स ने तब से भेजे हैं।
शेष कोटा घटने पर गति धीमी करें। समवर्ती ट्रैफ़िक के लिए पुनः प्रयास पथ बनाए रखें। गति नियंत्रण विफलताओं को कम करता है, लेकिन यह गारंटी नहीं दे सकता कि कोई भी कॉल 429 नहीं पाएगी।
Bird SDKs 429 पुनः प्रयास और Retry-After को संभालते हैं। ये आपकी सभी प्रक्रियाओं में साझा कतार का समन्वय नहीं करते।
यदि कोटा कार्यभार के लिए बहुत कम रहता है, तो ओवरराइड के बारे में Bird से संपर्क करें। अधिक keys बनाने से संगठन-स्तरीय भेजने की सीमा नहीं बढ़ती।
क्या रेट-लिमिटेड अनुरोध ने कोई कार्य किया है?
Bird रेट-लिमिटेड अनुरोध को अनुरोधित कार्य करने से पहले अस्वीकार कर देता है। वह अस्वीकृति उसकी idempotency key का उपयोग नहीं करती। प्रतीक्षा करने के बाद उसी key के साथ फिर से प्रयास करें।
लिमिटर अनुरोधों को गुज़रने देता है यदि वह सीमा का मूल्यांकन नहीं कर सकता। इसलिए कोटा मूल्यांकन में समस्या स्वयं 429 उत्पन्न नहीं करती।
अन्य विफलताओं के लिए भी idempotency हैंडलिंग बनाए रखें। सर्वर त्रुटि या खोई हुई प्रतिक्रिया write शुरू होने के बाद हो सकती है।
संक्षेप में
प्रतिक्रियाओं से कोटा पढ़ें।
लागू सीमा ग्रुप, प्लान और किसी भी ओवरराइड पर निर्भर करती है। एक निश्चित संख्या गलत हो सकती है।
कोटा साझा करने वाले सेंडर्स को समन्वित करें।
भेजने की सीमाएँ पूरे संगठन पर लागू होती हैं, इसलिए अलग-अलग keys से अलग-अलग भेजने के बजट नहीं बनते।
429 को फिर से प्रयास करने से पहले प्रतीक्षा करें।
Retry-Afterदेरी सेकंड में देता है। अपने पुनः प्रयासों को सीमित रखें। उसी write के लिए idempotency key को बनाए रखें।हेडर को साझा स्थिति मानें।
शेष अनुरोध अन्य वर्कर्स द्वारा उपयोग किए जा सकते हैं, इसलिए गति नियंत्रण रेट-लिमिट विफलताओं को कम करता है, पूरी तरह समाप्त नहीं करता।