रेट लिमिटर क्या है? एल्गोरिद्म, बजट, और स्कोप

Scrapeless Web Unlocker URL-आधारित कंटेंट रिट्रीवल को संभालता है जबकि आपका एप्लिकेशन उन रिक्वेस्ट्स के चारों ओर एक रेट लिमिटर लगा सकता है जिन्हें वह स्वीकार करता है।

एक रेट लिमिटर किसी ऑपरेशन में प्रवेश (admission) को नियंत्रित करता है

रेट लिमिटर एक ऐसा घटक है जो समय के साथ होने वाली गतिविधि से जुड़ी किसी पॉलिसी के तहत यह तय करता है कि कोई ऑपरेशन आगे बढ़ सकता है या नहीं। यह रिक्वेस्ट भेजे जाने से पहले किसी क्लाइंट में, किसी API गेटवे पर, या किसी महँगे ऑपरेशन के पास एप्लिकेशन के भीतर बैठ सकता है। यह घटक लागू स्टेट को देखता है और एक एडमिशन निर्णय लेता है, जबकि पॉलिसी यह परिभाषित करती है कि किसके लिए क्या और कैसे गिना जाएगा।

एक उपयोगी पॉलिसी सब्जेक्ट, ऑपरेशन, काउंटिंग यूनिट, टाइम मॉडल, और एक्सॉशन होने पर की जाने वाली कार्रवाई को नाम देती है। उदाहरण के लिए, एक काल्पनिक एक्सपोर्ट सर्विस एक्सपोर्ट शुरू करने के लिए प्रति टेनेंट एक अलाउंस और सक्रिय एक्सपोर्ट्स के लिए दूसरी सीमा आवंटित कर सकती है। यह एक उदाहरणात्मक डिज़ाइन है, Scrapeless कोटा नहीं। इन विवरणों के बिना, प्रति मिनट रिक्वेस्ट जैसी स्टेटमेंट लोड के समय उस व्यवहार को छिपा सकती है जो सबसे अधिक मायने रखता है।

The HTTP 429 definition HTTP सेवाओं को अत्यधिक रिक्वेस्ट गतिविधि के लिए एक स्टेटस देती है, लेकिन यह स्टेटस किसी सार्वभौमिक लिमिटर एल्गोरिद्म को निर्धारित नहीं करती। सर्वर अपने हिसाब से कॉलर्स की पहचान कर सकता है और अपने पॉलिसी के अनुसार ऑपरेशनों को गिन सकता है। 429 देख रहा क्लाइंट यह नहीं जान सकता कि सर्विस फिक्स्ड विंडो, टोकन बकेट, या किसी और अधिक जटिल रिसोर्स बजट का उपयोग कर रही है।

स्कोप यह निर्धारित करता है कि कौन अलाउंस साझा करता है

लिमिटर स्कोप यह तय करता है कि कौन सी रिक्वेस्ट्स एक ही क्षमता के लिए प्रतिस्पर्धा करती हैं। कोई सर्विस अकाउंट, टेनेंट, API की, यूज़र, रूट, IP एड्रेस, या किसी कंपोज़िट की के आधार पर गतिविधि गिन सकती है। IP-आधारित पॉलिसी असंबंधित यूज़र्स को एक साझा नेटवर्क के पीछे समूहित कर सकती है, जबकि अकाउंट-आधारित पॉलिसी कई अलग-अलग प्रॉसेसेज़ से आने वाले ट्रैफिक को जोड़ सकती है। स्कोप इस प्रकार चुनें कि वह उस संसाधन या निष्पक्षता सीमा से मेल खाए जिसकी सर्विस को रक्षा करनी है।

पदानुक्रमित (hierarchical) पॉलिसियाँ एक साथ लागू हो सकती हैं। किसी रिक्वेस्ट को टेनेंट अलाउंस, किसी एंडपॉइंट अलाउंस, और एक सर्विस-व्यापी ऊपरी सीमा के तहत क्षमता की जरूरत हो सकती है। एडमिशन सिस्टम को यह परिभाषित करना होगा कि ये जाँचें एक-दूसरे के साथ कैसे इंटरैक्ट करती हैं और स्वीकृत कार्य को कैसे दर्ज किया जाता है। ढीले-ढाले स्वतंत्र चेक्स का समूह असंगत कटौतियाँ बना सकता है या ऐसे काम को भी स्वीकार कर सकता है जिसे किसी दूसरी बाधा पर रुक जाना चाहिए था।

क्लाइंट-साइड एप्लिकेशनों को भी वही स्कोप जागरूकता चाहिए। यदि कई कलेक्टर्स एक ही प्रोवाइडर अकाउंट का उपयोग करते हैं, तो उनके डिस्पैच निर्णयों को अकाउंट के अलाउंस को साझा करना चाहिए, न कि हर एक को पूरा अलाउंस अपने लिए मान लेना चाहिए। एक लोकल लिमिटर अब भी किसी एक प्रॉसेस की रक्षा कर सकता है, लेकिन जब तक उसकी कोऑर्डिनेशन मैकेनिज़्म हर संबंधित कंज़्यूमर को कवर न करे, तब तक उसे एक सटीक ग्लोबल पॉलिसी के रूप में वर्णित नहीं करना चाहिए।

फिक्स्ड विंडोज़ और स्लाइडिंग विंडोज़ समय को अलग तरह से गिनते हैं

एक फिक्स्ड-विंडो लिमिटर नामित इंटरवल के भीतर स्वीकृत ऑपरेशनों को गिनता है और सीमा पर काउंट को रीसेट कर देता है। यह तरीका समझाने में सरल और ऑपरेट करने में सस्ता हो सकता है। इसकी सीमा का व्यवहार महत्वपूर्ण है: क्लाइंट किसी इंटरवल के अंत के पास उसकी अलाउंस खर्च कर सकता है और तुरंत बाद अगले इंटरवल की अलाउंस भी ले सकता है। अलग-अलग इंटरवल पर कम औसत इस प्रकार एक सघन बर्स्ट को शामिल कर सकता है।

एक स्लाइडिंग-लॉग लिमिटर किसी चलती हुई इंटरवल के भीतर गतिविधि के टाइमस्टैम्प रखता है और मौजूदा विंडो का सीधे मूल्यांकन करता है। यह एक अधिक कड़ा रोलिंग पॉलिसी बता सकता है, लेकिन प्रति-ऑपरेशन टाइमस्टैम्प स्टोर करने की एक स्टेट लागत होती है। एक स्लाइडिंग-विंडो काउंटर इस व्यवहार को संचित काउंट्स के साथ अनुमानित करता है। इसकी सटीकता और सीमा का व्यवहार चुने गए एल्गोरिद्म पर निर्भर करते हैं, इसलिए यह दस्तावेज़ करें कि पॉलिसी सटीक है या अनुमानित।

इन डिज़ाइनों का परीक्षण करते समय इंटरवल सीमाओं पर synthetic ट्रैफिक का उपयोग करें। एक स्थिर वर्कलोड कभी भी सीमा पर होने वाले बर्स्ट या घड़ी-संबंधी असंगति को उजागर नहीं कर सकती। परीक्षण चलाने से पहले अपेक्षित एडमिशन परिभाषित करें, फिर केवल एरर रिस्पॉन्स गिनने के बजाय स्वीकृत ऑपरेशनों को पॉलिसी से मिलान करें। लिमिटर की शुद्धता उसके घोषित मॉडल के तहत उसके निर्णय इतिहास का गुण है।

टोकन बकेट स्थायी दर को बर्स्ट क्षमता से अलग करता है

टोकन बकेट एक अलाउंस बनाए रखता है जो समय के साथ भरता है और अधिकतम क्षमता तक पहुँचता है। स्वीकृत ऑपरेशन अपनी निर्धारित लागत के अनुसार टोकन खर्च करता है। रिफिल रेट टिकाऊ गतिविधि का वर्णन करता है, जबकि बकेट क्षमता बताती है कि संचित अलाउंस से एक बर्स्ट में कितना खर्च किया जा सकता है। ये अलग-अलग सेटिंग्स हैं और इन्हें क्लाइंट्स को अलग से समझाया जाना चाहिए।

एक काल्पनिक बकेट शांत अवधि के बाद छोटे बर्स्ट की अनुमति दे सकता है, जबकि दीर्घकालिक गतिविधि को अब भी सीमित रखता है। यह व्यवहार इंटरैक्टिव ट्रैफिक के लिए उपयुक्त हो सकता है, लेकिन ऐसे बैकएंड के लिए अनुपयुक्त हो सकता है जो बर्स्ट को झेल नहीं सकता। क्षमता को किसी डिफ़ॉल्ट को केवल इसीलिए कॉपी करने के बजाय सर्विस की वास्तविक प्रोसेसिंग सहनशीलता से चुनें क्योंकि वह वांछित औसत दर से मेल खाती है।

The rate-limiting algorithm overview टोकन-बकेट और लीक़ी-बकेट कॉन्सेप्ट्स का वर्णन करता है। लीक़ी-बकेट शब्दावली अलग-अलग policing या shaping डिज़ाइनों के लिए उपयोग हो सकती है, इसलिए यह स्पष्ट करें कि आपका इम्प्लीमेंटेशन अतिरिक्त ऑपरेशनों को अस्वीकार करता है या उन्हें नियंत्रित ड्रेन रेट के लिए कतारबद्ध करता है। जब दो लाइब्रेरीज़ एक ही नाम का उपयोग अलग-अलग ऑपरेशनल व्यवहार के लिए करती हैं, तो केवल इम्प्लीमेंटेशन नाम पर्याप्त नहीं होता।

वितरित अकाउंटिंग को एटॉमिक निर्णयों की आवश्यकता होती है

एक वितरित लिमिटर को अपना चेक और अपडेट इस तरह समन्वित करना होता है कि समवर्ती कॉलर एक ही बची हुई क्षमता को सब मिलकर खर्च न कर सकें। एक काउंटर को पढ़ना और बाद में उसे अपडेट करना तब रेस पैदा करता है जब कई वर्कर पुरानी वैल्यू देखते हैं। चुने गए स्टेट स्टोर और कंसिस्टेंसी आवश्यकता के अनुसार एटॉमिक ऑपरेशन या कोई अन्य समन्वय तंत्र उपयोग करें। सटीक इम्प्लीमेंटेशन चुने हुए इन्फ्रास्ट्रक्चर पर निर्भर होता है।

समन्वय की भी एक लागत होती है। एक केंद्रीकृत निर्णय बिंदु सख्त वैश्विक अनुमति को सरल बना सकता है लेकिन नेटवर्क लेटेंसी और एक अतिरिक्त निर्भरता जोड़ता है। स्वतंत्र क्षेत्रीय अनुमतियाँ समन्वय को घटा सकती हैं जबकि वे एक परिभाषित आबंटन और ओवरशूट मॉडल की माँग करती हैं। यह स्पष्ट रूप से बताएँ कि डिज़ाइन वास्तव में कौन‑सी गारंटी देता है। अनुमानित वितरित नियंत्रण उपयोगी हो सकता है, लेकिन बिना सहायक साक्ष्य के उसे सटीक वैश्विक कैप के रूप में प्रस्तुत नहीं करना चाहिए।

समय हैंडलिंग को भी इसी तरह की स्पष्टता की ज़रूरत है। तय करें कि विंडो सीमाओं या रीफिल गणनाओं के लिए उपयोग होने वाला समय कौन‑सा घटक प्रदान करेगा, स्टेट कैसे एक्सपायर होगा, और जब कोई प्रोसेस फिर से शुरू होता है तो क्या होता है। परीक्षणों को केवल एक वर्कर द्वारा समान अंतराल पर कॉल करने के बजाय समवर्ती अपडेट और स्टेट स्टोर में बदलावों को कवर करना चाहिए। एक लिमिटर जो एक सिंगल‑प्रोसेस डेमोंस्ट्रेशन में सही प्रतीत होता है, वह पूरे फ़्लीट में अलग व्यवहार कर सकता है।

रेट, कंकरेन्सी, कोटा, और बजट अलग‑अलग होते हैं

रेट लिमिट समय के साथ गतिविधि को सीमित करता है, जबकि कंकरेन्सी लिमिट वर्तमान में प्रगति पर चल रहे ऑपरेशनों को सीमित करता है। कोटा लंबी अवधि के कुल को सीमित कर सकता है, और वित्तीय बजट खर्च को नियंत्रित कर सकता है। एक तंत्र अपने‑आप अन्य को लागू नहीं करता। धीमे महंगे ऑपरेशनों वाली कोई सेवा अपनी रिक्वेस्ट दर के भीतर रहकर भी मेमोरी ख़त्म कर सकती है या बहुत अधिक सक्रिय काम जमा कर सकती है।

रिक्वेस्ट गिनती भी काम का केवल एक माप है। एक बड़ा एक्सपोर्ट या जटिल क्वेरी एक छोटे लुकअप से अधिक लागत रख सकती है। OWASP resource-consumption controls पेayload आकार, ऑपरेशन आवृत्ति, रिकॉर्ड गिनती, और सेवा व्यय को कवर करती हैं। जहाँ संसाधन लागत को प्रति HTTP रिक्वेस्ट एक टोकन से पर्याप्त रूप से व्यक्त नहीं किया जा सकता, वहाँ उन नियंत्रणों का उपयोग करें।

HTTP सिमेंटिक्स एक और भेद जोड़ते हैं: स्वीकृत रिक्वेस्ट हमेशा पूर्ण व्यवसाय ऑपरेशन नहीं होती। HTTP response semantics संदेश परिणामों को अनुप्रयोग के प्रोसेसिंग कॉन्ट्रैक्ट से अलग करती है। एक असिंक्रोनस एक्सपोर्ट को स्वीकार किया जा सकता है और बाद में वैलिडेशन या प्रोसेसिंग में विफल हो सकता है। तय करें कि ऑपरेशन किस चरण पर प्रत्येक बजट का उपभोग करता है और अकाउंटिंग उस काम का वर्णन कैसे करती है जिसने कभी उपयोगी आउटपुट उत्पन्न नहीं किया।

क्षय और निर्भरता विफलता के लिए स्पष्ट नीतियाँ चाहिए

एक समाप्त हो चुका लिमिटर कॉलर और ऑपरेशन मालिक दोनों के लिए स्पष्ट परिणाम उत्पन्न करे। रिजेक्शन, सीमित क्यूइंग, और न भेजे गए काम को अस्वीकार करने के अलग‑अलग उत्पाद प्रभाव होते हैं। व्यवहार को कार्य के मूल्य और समयसीमा के आधार पर चुनें। एक अनबाउंडेड क्यू मेमोरी खा सकता है और उपयोगकर्ताओं को ऐसे काम के लिए प्रतीक्षा में छोड़ सकता है जो क्षमता उपलब्ध होने तक प्रासंगिक नहीं रहेगा।

एक लिमिटर जिसका स्टेट स्टोर अनुपलब्ध है, उसे परिभाषित निर्भरता नीति की आवश्यकता होती है। अकाउंटिंग के बिना काम की अनुमति देना उपलब्धता की रक्षा कर सकता है जबकि कैप को कमजोर करता है; काम को ब्लॉक करना बजट की रक्षा कर सकता है जबकि उपयोगी रिक्वेस्ट को अस्वीकार करता है। अलग‑अलग ऑपरेशनों के लिए अलग निर्णयों की ज़रूरत हो सकती है। इस ट्रेडऑफ़ को दस्तावेज़ित करें और नियंत्रित फ़ॉल्ट परिदृश्यों के माध्यम से परीक्षण करें, बजाय इसके कि स्टोरेज लाइब्रेरी का संयोगवश व्यवहार ही नीति बन जाए।

एरर रिपोर्टिंग को प्रभावित स्कोप की पहचान करनी चाहिए बिना क्रेडेंशियल या अन्य टेनेंट की गतिविधि उजागर किए। एक नीति पहचानकर्ता, ऑपरेशन श्रेणी, और ऐसा स्वच्छ कारण शामिल करें जिस पर कॉलर कार्रवाई कर सके। ऑपरेटरों को प्रवेश, रिजेक्शन, क्यू, और प्रोसेसिंग के समग्र मेट्रिक्स की ज़रूरत होती है। उच्च रिजेक्शन काउंट दुरुपयोग, कम आबंटन, या क्लाइंट दोष का संकेत दे सकता है, और इन कारणों के लिए अलग‑अलग प्रतिक्रियाएँ आवश्यक हैं।

निष्पक्षता और उपयोगी काम का अवलोकन करें

एक अच्छा लिमिटर अपने घोषित नीति को लागू करते हुए उपयोगी काम की रक्षा करता है। मापें कि कौन क्षमता प्राप्त करता है, स्वीकृत काम कितना समय प्रतीक्षा करता है, और क्या महंगे ऑपरेशन सामान्य ट्रैफ़िक को बाहर धकेल देते हैं। फर्स्ट‑कम आबंटन एक टेनेंट को साझा अनुमति को उपभोग करने दे सकता है, भले ही प्रत्येक व्यक्तिगत रिक्वेस्ट मान्य हो। यदि निष्पक्षता एक उत्पाद आवश्यकता है, तो उसे एक स्पष्ट आबंटन डिज़ाइन चाहिए।

टेस्ट वर्कलोड में बर्स्ट, असमान टेनेंट माँग, धीमे ऑपरेशन, बड़े इनपुट, और एक साथ वर्कर स्टार्ट शामिल होने चाहिए। इन परीक्षणों को सिंथेटिक डेटा और सीमित वॉल्यूम के साथ अधिकृत स्टेजिंग या लोकल वातावरण में रखें। लक्ष्य निर्णय मॉडल को मान्य करना है, न कि किसी प्रोडक्शन सेवा की सीमा को उसे अभिभूत करके खोज निकालना। देखी गई एडमिशन को अपेक्षित स्कोप और समय नीति के विरुद्ध तुलना करें।

एक उपयोगी ऑपरेशनल रिपोर्ट स्वीकृत रिक्वेस्ट, पूर्ण ऑपरेशन, संग्रहीत रिकॉर्ड, और वित्तीय खपत को अलग‑अलग दिखाती है। वैध कारणों से ये मान अलग हो सकते हैं। इन भेदों को बनाए रखना टीम को यह देखने देता है कि लिमिटर वास्तविक संसाधन की रक्षा करता है या नहीं और क्या आबंटन वांछित उत्पाद परिणाम उत्पन्न करता है या नहीं। एक मात्र सफलता प्रतिशत उन सभी सीमाओं को नहीं समझा सकता।

Scrapeless वर्कफ़्लो के चारों ओर लिमिटर रखें

एक क्लाइंट Scrapeless Web Unlockerको किए जाने वाले कॉल के चारों ओर एडमिशन कंट्रोल लगा सकता है, जबकि सेवा के अपने अकाउंट नियम स्वतंत्र रूप से लागू रहते हैं। Web Unlocker overview URL-आधारित सामग्री पुनर्प्राप्ति का वर्णन करता है। आपका अनुप्रयोग लक्षित स्कोप चुनता है, कार्य कतार में डालता है, और तय करता है कि लौटाई गई सामग्री उसके डेटासेट मानदंडों को संतुष्ट करती है या नहीं। एक स्थानीय लिमिटर लक्ष्य वेबसाइट की अनुमति नीति नहीं बदल सकता।

समीक्षा Scrapeless मूल्य निर्धारण सेवा लागत और संबंधित समानांतरता की अवधारणाएँ सक्रिय‑कार्य नियंत्रण के लिए। एक साझा आवंटन उन उपभोक्ताओं पर लागू करें जो एक ही खाता भत्ता खर्च करते हैं। स्रोत की अधिकृत संग्रह स्थितियों को सेवा बजट के साथ‑साथ दृश्यमान रखें, क्योंकि नेटवर्क क्षमता, वित्तीय क्षमता, और डेटा एकत्र करने की अनुमति अलग‑अलग बाधाएँ हैं।

एक काल्पनिक रिपोर्टिंग जॉब सीमित दैनिक आवंटन आरक्षित कर सकता है, सक्रिय अनुरोधों पर सीमा लगा सकता है, और उनकी रिपोर्टिंग विंडो के बाद न भेजे गए अवलोकनों की समय‑सीमा समाप्त कर सकता है। इसकी पूर्णता रिपोर्ट को स्वीकृत रिकॉर्ड और वह स्कोप पहचानना चाहिए जो एकत्र नहीं किया गया। यह डिज़ाइन लिमिटर को वास्तविक व्यावसायिक आवश्यकता से जोड़ता है और जब उपलब्ध क्षमता माँग से कम हो तो परिणामी डेटासेट का आकलन करना आसान बनाता है।

निष्कर्ष

रेट लिमिटर एक प्रवेश प्रणाली है जिसका व्यवहार स्कोप, समय मॉडल, एल्गोरिदम, और अकाउंटिंग स्थिरता पर निर्भर करता है। जिन संसाधनों की आपको रक्षा करनी है, उनसे ये गुण चुनें, फिर नियंत्रित ट्रैफ़िक के साथ उनकी सीमाओं का परीक्षण करें। रेट नियंत्रण को लागत और सक्रिय‑कार्य सीमाओं के साथ संयोजित करें जो अनुप्रयोग को आवश्यक हैं, और रिपोर्ट करें कि स्वीकृत अनुरोधों ने वास्तव में कितना उपयोगी कार्य उत्पन्न किया।