रेट लिमिटिंग कैसे काम करता है?
Scrapeless Web Unlocker ऐसे कलेक्शन वर्कफ़्लो के लिए वेब सामग्री प्राप्त करता है जिनके अनुप्रयोगों को अब भी स्रोत एक्सेस नीतियों का सम्मान करना होता है और अपना स्वयं का वर्कलोड प्रबंधित करना होता है।
रेट लिमिटिंग कैसे काम करता है?
रेट लिमिटिंग समय के साथ किसी अलाउंस के संदर्भ में गतिविधि का मूल्यांकन करती है और यह तय करती है कि कोई अनुरोध आगे बढ़ सकता है या नहीं। एक नीति यह परिभाषित करती है कि कौन‑सी गतिविधि गिनी जा रही है, वह किस पहचान या स्कोप से संबंधित है, अनुमत दर या बर्स्ट क्या है, और जब अलाउंस समाप्त हो जाए तो कौन‑सी कार्रवाई की जाए। यह तंत्र किसी सेवा की रक्षा कर सकता है, क्षमता को निष्पक्ष रूप से बाँट सकता है, या उपयोग समझौते को लागू कर सकता है।
अनुरोध अलाउंस प्राधिकरण (authorization) के समान नहीं है। कोई कॉलर वैध क्रेडेंशियल रख सकता है लेकिन अपना अलाउंस पार कर सकता है, या दर सीमा से नीचे रहकर भी किसी संसाधन तक पहुँचने की अनुमति न रख सकता हो। इन दो स्थितियों का निदान केवल वास्तविक प्रतिक्रिया और सेवा नीति से किया जा सकता है, न कि केवल ट्रैफ़िक वॉल्यूम पर आधारित किसी अनुमान से।
संक्षेप में
- एक रेट लिमिट को एक पहचान और एक गिनती नियम की ज़रूरत होती है। एक ही अनुरोध पर कई स्वतंत्र नीतियाँ लागू हो सकती हैं।
- बर्स्ट अलाउंस निरंतर दर से अलग होता है। एल्गोरिद्म ट्रैफ़िक सीमाओं को अलग‑अलग तरीकों से संभालते हैं।
- Concurrency सीमाएँ सक्रिय कार्य को गिनती हैं। वे सीधे तौर पर समय अंतराल के प्रति अनुरोधों को परिभाषित नहीं करतीं।
- HTTP 429 प्रतिक्रिया स्तर पर रेट लिमिटिंग की पहचान कराता है। अन्य एक्सेस और क्षमता विफलताओं को अलग से निदान की आवश्यकता होती है।
रेट‑लिमिट नीति वास्तव में क्या गिनती है?
एक रेट‑लिमिट नीति किसी परिभाषित स्कोप के भीतर परिभाषित कार्य इकाई को गिनती है। इकाई अनुरोध, bytes, operations, या weighted cost हो सकती है। स्कोप कोई अकाउंट, क्रेडेंशियल, endpoint, tenant, या नेटवर्क पहचान हो सकता है। एक साथ कई स्कोप लागू हो सकते हैं, जैसे tenant अलाउंस और अलग से महँगे‑ऑपरेशन का अलाउंस।
गिनती के लिए चुनी गई पहचान निष्पक्षता को प्रभावित करती है। एक नेटवर्क पता साझा इन्फ्रास्ट्रक्चर के पीछे कई असंबंधित उपयोगकर्ताओं का प्रतिनिधित्व कर सकता है। एक अकाउंट कई क्रेडेंशियल का उपयोग कर सकता है। यदि इरादे की नीति अकाउंट‑वाइड है, तो नया क्रेडेंशियल बनाना नया वैध अलाउंस नहीं बनाता, जब तक कि सेवा स्पष्ट रूप से ऐसा न कहे।
Weighted सीमाएँ महँगे ऑपरेशनों को बेहतर रूप से दर्शा सकती हैं, लेकिन उनकी cost rules समझ में आने योग्य होनी चाहिए। किसी बड़े संग्रह पर फैली खोज cached रिकॉर्ड पढ़ने की तुलना में अधिक क्षमता उपयोग कर सकती है। कोई क्लाइंट केवल response size या latency से उन weights का अनुमान नहीं लगा सकता।
निरंतर दर, बर्स्ट अलाउंस, और दीर्घकालीन कोटा को अलग रखें। कोई सेवा कम औसत दर बनाए रखते हुए अल्पकालिक बर्स्ट की अनुमति दे सकती है। मासिक उपयोग अधिकार एक और सीमा है। अल्पकालिक दर को पूरा करना यह सिद्ध नहीं करता कि दीर्घकालीन क्षमता अब भी उपलब्ध है।
Fixed और Sliding Windows कैसे काम करते हैं?
एक fixed‑window limiter पृथक अंतरालों के भीतर गतिविधि गिनता है, जबकि एक sliding‑window limiter एक चलती हुई अवधि का मूल्यांकन करता है। fixed windows बताने में सरल हैं, लेकिन किसी अंतराल सीमा के पास ट्रैफ़िक आस‑पास की खिड़कियों में एकत्रित हो सकता है। वह बर्स्ट स्वीकार्य है या नहीं, यह संरक्षित सिस्टम पर निर्भर करता है।
एक sliding log प्रासंगिक अनुरोधों के timestamps को रख सकता है और उन अनुरोधों को गिन सकता है जो अब भी चलती अवधि के भीतर हैं। एक sliding counter पड़ोसी काउंटरों से चलती अवधि का अनुमान लगा सकता है। दोनों तरीकों में state लागत और precision अलग होते हैं, इसलिए केवल “sliding window” कहना पूरा एल्गोरिद्म विनिर्देशन नहीं है।
The rate-limiter algorithm comparison fixed windows, sliding तरीकों, token buckets, और leaky buckets का वर्णन करती है। चुनाव को आवश्यक बर्स्ट व्यवहार और implementation constraints के अनुरूप होना चाहिए, न कि इस दावे के आधार पर कि कोई एक तरीका हमेशा सबसे अच्छा है।
समय स्रोत और अपडेट semantics को परिभाषित करें। एक distributed सेवा में, अलग‑अलग workers यदि stale काउंटरों का मूल्यांकन कर रहे हों, तो वे इच्छित से अधिक work स्वीकार सकते हैं। जाँच और state अपडेट में नीति द्वारा आवश्यक atomicity होनी चाहिए। एक सही single‑process एल्गोरिद्म अपने आप सही global अलाउंस प्रदान नहीं करता।
| तंत्र | मुख्य विचार | महत्त्वपूर्ण tradeoff |
|---|---|---|
| Fixed window | पृथक अंतरालों के भीतर गिनती करें | ट्रैफ़िक सीमाओं के आस‑पास समूहित हो सकता है |
| Sliding window | चलती समय अवधि का मूल्यांकन करें | precision और संग्रहीत state तरीके के अनुसार बदलते हैं |
| Token bucket | समय के साथ सीमित अलाउंस को refill करें | नियंत्रित बर्स्ट की अनुमति देता है |
| Leaky-bucket shaping | queued work को नियंत्रित दर पर रिलीज़ करें | सीमित queue और delay नीति की आवश्यकता होती है |
| Concurrency limiter | वर्तमान सक्रिय operations को सीमित करें | throughput ऑपरेशन की अवधि के साथ बदलता है |
Token और Leaky Buckets अलग कैसे हैं?
एक token bucket अधिकतम क्षमता तक अलाउंस को फिर से भरता है और काम स्वीकार करते समय उस अलाउंस को खर्च करता है। अप्रयुक्त अलाउंस बाद में बर्स्ट का समर्थन कर सकता है, जिसकी सीमा bucket क्षमता से बँधी होती है। refill rate समय के साथ निरंतर admission को नियंत्रित करती है।
The token-bucket और leaky-bucket ट्रैफ़िक मॉडल दर, बर्स्ट आकार और समय के बीच संबंध समझाएँ। इन अवधारणाओं को API अनुरोधों पर लागू करने के लिए यह परिभाषित करना पड़ता है कि एक टोकन क्या दर्शाता है। यह एक अनुरोध या लागत की किसी अन्य इकाई का प्रतिनिधित्व कर सकता है।
Leaky-bucket शब्दावली policing या shaping का वर्णन कर सकती है। एक shaping डिज़ाइन में, कतारबद्ध कार्य को नियंत्रित दर पर छोड़ा जाता है। कतार के लिए अधिकतम आकार, समाप्ति नीति, और उस कार्य के लिए निर्णय चाहिए जिसे स्वीकार नहीं किया जा सकता। एक अनबाउंडेड कतार केवल ओवरलोड को बढ़ती मेमोरी खपत और देरी में बदल देती है।
यह न मानें कि हर एंडपॉइंट के लिए बर्स्ट अलाउंस अतिरिक्त क्षमता है। कई क्लाइंट एक ही समय में अपना अलाउंस उपयोग कर सकते हैं। क्षमता नियोजन को उस संयुक्त व्यवहार को ध्यान में रखना चाहिए जिसकी नीति अनुमति देती है।
HTTP 429 क्लाइंट को क्या बताता है?
HTTP 429 यह दर्शाता है कि सर्वर मानता है कि क्लाइंट ने प्रासंगिक अवधि के भीतर बहुत अधिक अनुरोध भेजे हैं। 429 status-code definition गिनती तंत्र और क्लाइंट-पहचान नीति को सर्वर पर छोड़ देता है। केवल स्टेटस यह खुलासा नहीं करता कि अलाउंस किसी क्रेडेंशियल, उपयोगकर्ता, एंडपॉइंट या किसी और स्कोप का है।
वास्तविक नीति की पहचान करने के लिए प्रलेखित प्रतिक्रिया फ़ील्ड और प्रदाता डैशबोर्ड की जाँच करें। यह न मानें कि हर सेवा एक जैसे हेडर नाम या इकाइयाँ उपयोग करती है। शेष-अलाउंस मान एक नीति का संदर्भ दे सकता है जबकि कोई अन्य सख्त नीति भी लागू हो सकती है।
HTTP 403 एक अस्वीकार किए गए ऑपरेशन का वर्णन करता है, न कि विशेष रूप से दर समाप्त होने की पहचान करता है। HTTP 503 सेवा उपलब्धता से संबंधित है और इसके कई कारण हो सकते हैं। HTTP response semantics व्यापक भेद प्रदान करते हैं। सफल स्टेटस के साथ परोसा गया HTML एक्सेस पेज भी एक संग्राहक द्वारा डेटा के रूप में स्वीकार किए जाने से पहले सामग्री निरीक्षण की आवश्यकता रखता है।
जब वर्कलोड प्रलेखित अलाउंस से अधिक हो जाए, तो प्रभावित कार्य को तब तक स्वीकार करना बंद कर दें जब तक कि एप्लिकेशन की ऑपरेटिंग नीति इसे अनुमति न दे। अधूरे कार्य की स्थिति संरक्षित रखें और सीमित करने वाले स्कोप की रिपोर्ट करें। क्षमता या अधिकारों में परिवर्तन प्रदाता की समर्थित प्रक्रिया के माध्यम से ही होना चाहिए।
दर, समकालिकता से कैसे अलग है?
दर समय के साथ गतिविधि को मापती है; समकालिकता यह मापती है कि एक साथ कितने ऑपरेशन सक्रिय हैं। एक छोटे वर्कर पूल वाला क्लाइंट भी उच्च अनुरोध दर उत्पन्न कर सकता है यदि प्रत्येक ऑपरेशन जल्दी समाप्त हो जाता है। कम अनुरोध दर भी पर्याप्त समकालिक क्षमता का उपभोग कर सकती है जब ऑपरेशन लंबे समय तक सक्रिय रहते हैं।
जब दोनों मायने रखते हों तो अलग नियंत्रणों का उपयोग करें। एक शेड्यूलर प्रवेश दर को नियंत्रित कर सकता है, जबकि वर्कर पूल सक्रिय कार्य को सीमित करता है। प्रति-स्रोत नियंत्रण एक बड़े ग्लोबल क्यू को किसी एक गंतव्य को अभिभूत करने से रोकते हैं। अकाउंट-स्तरीय नियंत्रण अन्यथा स्वतंत्र जॉब्स में साझा संयुक्त अलाउंस को संरक्षित करते हैं।
पेजिनेशन यह भेद स्पष्ट करती है। एक अनुक्रमिक कर्सर वॉक केवल एक सक्रिय अनुरोध का उपयोग कर सकता है, फिर भी बड़े निर्यात के दौरान कई अनुरोधों की खपत कर सकता है। एक ब्राउज़र सत्र किसी पेज इंटरेक्शन की प्रतीक्षा करते हुए सक्रिय रह सकता है, भले ही वह कम संग्रह अनुरोध भेजे। उन संसाधनों को मॉडल करें जिन्हें प्रदाता वास्तव में सीमित करता है।
कतार में प्रतीक्षा कर रहे कार्य के लिए निरस्तीकरण और डेडलाइन निर्धारित करें। एक पुराना संग्रह अनुरोध उसकी ताजगी डेडलाइन के बाद शायद अब उपयोगी न हो। दर्ज किए गए कारण के साथ समाप्त हो चुका कार्य छोड़ देना, उसे बाद में वर्तमान दिखने वाले समाप्ति टाइमस्टैम्प के साथ वितरित करने से अधिक ईमानदार है।
Scrapeless वर्कलोड नियंत्रण में कहाँ फिट बैठता है?
Scrapeless एक संग्रह क्षमता प्रदान करता है, जबकि आपका एप्लिकेशन उसके अनुमत वर्कलोड और स्वीकृति नीति को निर्धारित करता है। Web Unlocker किसी स्रोत के एक्सेस नियमों से अधिक जाने की अनुमति नहीं बनाता। संग्रह क्रेडेंशियल, स्रोत अनुमतियाँ और शेड्यूलिंग नीति को अलग रखें।
वहीं Scrapeless API key requirements प्रमाणीकरण का वर्णन करते हैं। एक कार्यशील कुंजी न तो असीमित समकालिकता की पुष्टि करती है और न ही हर उत्पाद तक पहुँच की। चयनित सेवा पर लागू नियंत्रणों और अकाउंट एंटाइटलमेंट्स का उपयोग करें।
अनावश्यक कार्य को कम करना क्षमता उपयोग और डेटा की ताजगी दोनों में सुधार कर सकता है। Incremental collection और रिकॉर्ड परिवर्तन पहचान अपरिवर्तित सामग्री को बदले हुए व्यावसायिक रिकॉर्ड से अलग करती है। उन तंत्रों को केवल वहीं लागू करें जहाँ स्रोत व्यवहार उन्हें समर्थन देता हो।
स्वीकृत कार्य, अस्वीकृत कार्य, कतार की आयु, स्वीकृत रिकॉर्ड और शामिल नीति स्कोप की निगरानी करें। केवल संग्रह अनुरोधों की गिनती यह नहीं समझा सकती कि क्या सीमित रन ने उपयोगी डेटासेट तैयार किया। लागत नियोजन के लिए Scrapeless pricing का उपयोग स्रोत के स्वतंत्र एक्सेस और क्षमता नियमों के साथ करें।
निष्कर्ष
एक स्पष्ट रेट-लिमिट डिज़ाइन गिने जाने वाले कार्य, पहचान, समय मॉडल और ओवरलोड निर्णय का नाम लेता है। प्रवेश और समकालिकता नियंत्रणों को उन सीमाओं से मिलाएँ, फिर अधूरे कार्य को स्पष्ट रूप से रिकॉर्ड करें ताकि ट्रैफ़िक नियंत्रण चुपचाप गायब डेटा न बन जाए।
कलेक्शन लेयर को व्यवहार में लाएँ
अपने स्रोत से मेल खाने वाली Scrapeless संग्रह क्षमता चुनें, फिर ऊपर वर्णित सत्यापन और ऑपरेटिंग निर्णय लागू करें।
आज ही साइन अप करें और पाएं $5 का फ्री क्रेडिट — कोई क्रेडिट कार्ड आवश्यक नहीं.
अपना $5 क्रेडिट क्लेम करें →FAQ
क्या हर access-denied प्रतिक्रिया एक रेट लिमिट होती है?
नहीं। एक्सेस अनुमति, नीति, प्रमाणीकरण या अन्य स्थितियों के कारण अस्वीकार किया जा सकता है। वास्तविक कारण की पहचान करने के लिए प्रलेखित स्टेटस, बॉडी और अकाउंट संदर्भ का उपयोग करें।
क्या एक token bucket स्थिर अनुरोध गति को लागू करता है?
नहीं। एक token bucket अपनी उपलब्ध सीमित अनुमति तक बर्स्ट की अनुमति देता है। इसकी refill दर दीर्घकालिक अनुमति को नियंत्रित करती है, जबकि एक shaping queue रिलीज़ की गति को नियंत्रित कर सकती है।
क्या workers को कम करना हमेशा rate exhaustion हल कर देता है?
नहीं। worker की संख्या सक्रिय operations को सीमित करती है, जबकि request rate अवधि और scheduling पर भी निर्भर करता है। जब सेवा समय के साथ activity को सीमित करती है तो एक admission policy की आवश्यकता होती है।
क्या कई API keys एक ही limit साझा कर सकती हैं?
हाँ। एक provider क्रेडेंशियल्स के पार account-wide या tenant-wide policy लागू कर सकता है। यह मानने के बजाय कि हर key को स्वतंत्र क्षमता मिलती है, documented scope का पालन करें।