रेट लिमिटर क्या है?

रेट लिमिटर परिभाषा

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

लिमिटर एक प्रवेश पथ पर बैठता है। यह एक कुंजी पढ़ता है, स्थिति की जांच करता है, उस स्थिति को परमाणु रूप से अपडेट करता है, और एक निर्णय लौटाता है। परिणाम एक दुर्लभ संसाधन या निष्पक्षता नियम की रक्षा करता है इससे पहले कि अनियंत्रित मांग उस घटक तक पहुँच सके जो अन्यथा विफल हो जाता है या बहुत महंगा हो जाता है। यहाँ उपयोग की जाने वाली प्राथमिक शब्दावली RFC 6585 की HTTP 429 परिभाषाहै, जो विचार को एक ठोस तकनीकी सीमा देती है बजाय इसे एक विपणन लेबल के रूप में मानने के।

एक उपयोगी परिभाषा यह भी बताती है कि विचार क्या नहीं करता। एक रेट लिमिटर समवर्ती सेमाफोर, कतार क्षमता, बिलिंग कोटा, या नेटवर्क भीड़ नियंत्रण के समान नहीं है। ये तंत्र एक साथ काम कर सकते हैं, लेकिन प्रत्येक एक अलग अवस्था को मापता है और एक अलग प्रतिक्रिया उत्पन्न करता है। उस सीमा को स्पष्ट रखना आर्किटेक्चर आरेखों को उस घटक को गारंटी देने से रोकता है जो दूसरे परत का हिस्सा है।

रेट-सीमित निर्णय कैसे किए जाते हैं

हर निर्णय एक विषय, एक नियम, संग्रहीत स्थिति, और एक क्रिया को मिलाता है। एक वितरित लिमिटर को भी संगतता नियमों की आवश्यकता होती है ताकि कई गेटवे स्वतंत्र रूप से पूरी अनुमति का खर्च न करें।

1. अधिकृत खाते, मार्ग, होस्ट, किरायेदार, या अन्य स्वीकृत सीमा से सीमा कुंजी निकालें।
2. चुनते हुए एल्गोरिदम द्वारा आवश्यक काउंटर, टाइमस्टैम्प, बकेट बैलेंस, या कतारबद्ध प्रस्थान समय लोड करें।
3. नीति को परमाणु रूप से लागू करें ताकि समानांतर अनुरोध एक ही क्षमता को दो बार खर्च न कर सकें।
4. ऑपरेशन की अनुमति, देरी, या अस्वीकार करें और अवलोकनता और ग्राहक व्यवहार के लिए पर्याप्त मेटाडेटा प्रस्तुत करें।
5. लिमिटर स्थिति को समाप्त या संकुचन करें ताकि निष्क्रिय कुंजी बिना सीमा के संग्रहण वृद्धि न करें।

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

रेट-सीमित एल्गोरिदम की तुलना

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

जहाँ दर सीमा नियंत्रण सिस्टम की रक्षा करते हैं

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

कुंजी, कोटे, और निष्पक्षता

एक उपयोगी नीति यह बताती है कि कौन क्षमता साझा करता है, कौन सी प्रक्रिया इसे उपभोग करती है, कितनी तेजी से क्षमता वापस आती है, क्या बर्स्ट की अनुमति है, और जब सीमा पहुंची जाती है तो कॉलर क्या देखता है।

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

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

दर-सीमक डिज़ाइन गलतियाँ

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

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

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

वेब डेटा संग्रह में दर नियंत्रण

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

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

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

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

रेट-लिमिटर समीक्षा चेकलिस्ट

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

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

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

निष्कर्ष

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

संदर्भ

• स्क्रेपलेस वेब अनलॉकर परिचय
• स्क्रेपलेस वेब अनलॉकर उत्पाद अवलोकन
• स्क्रेपलेस नियंत्रित लाइव-वेब संग्रह की गाइड
• स्क्रेपलेस ओपन-सोर्स प्रोजेक्ट्स गिटहब पर