डिजाइन दर सीमाएँ

1) दर सीमित क्यों

दर सीमित करना एपीआई की उपलब्धता और अर्थशास्त्र की रक्षा करता है: बाढ़, रिट्रे के फटने, क्रेडेंशियल स्टफिंग, महंगे संचालन (मनी लेनदेन, रिपोर्ट जनरेशन) की रक्षा करता है, आश्रित सिस्टम (डेटाबेस/प्स) पर लोड। अच्छा डिजाइन निष्पक्षता, विलंबता की भविष्यवाणी और स्पष्ट एसएलओ देता है।

मुख्य उद्देश्य

आरपीएस स्थिरता और बैकएंड ओवरलोड सुरक्षा।

नियंत्रित "लोच" (फट भत्ता)।

ग्राहक भेदभाव (प्रति-उपयोगकर्ता/प्रति-संगठन/प्रति-कुंजी/प्रति-आईपी/प्रति-क्षेत्र)।

मूल्य मॉडल: विभिन्न लेनदेन के लिए अलग-अलग "कीमतें"।

2) सीमा प्रकार

आरपीएस सीमा: अनुरोध प्रति सेकंड/मिनट।

कोटा: प्रति अवधि (दिन/माह) कुल बजट।

प्रतिस्पर्धा: एक साथ संचालन (चेकआउट, भारी नौकरी)।

दर/पट्टी बाइट्स/सेक (लोड/अनलोड)।

भारित सीमाएं: जटिलता द्वारा अनुरोध की "लागत" (उदाहरण के लिए, ग्राफक्यूएल जटिलता, बैच आकार)।

अनुकूली: विसंगतियों (संदिग्ध गतिविधि/त्रुटियों 401/403/5xx) के मामले में कड़ा।

3) एल्गोरिदम और उन्हें कब लागू करना है

3. 1 फिक्स्ड विंडो काउंटर

सरल: प्रति अंतराल काउंटर (उदा। 100 r/min)।

पेशेवरों: न्यूनतम लागत। विपक्ष: खिड़की की सीमाओं पर "किनारा फटता है"।

कब: व्यवस्थापक पैनल, कम सटीकता, कम लागत।

3. 2 स्लाइडिंग विंडो (लॉग/काउंटर)

हाल के अनुरोधों के टाइमस्टैम्प को लॉग - स्टोर करें, सटीक, स्मृति में महंगा।

काउंटर: दो आसन्न खिड़कियों (रोलिंग) का औसत, सटीकता और मूल्य का एक समझौता।

कब: मध्यम यातायात के सार्वजनिक एपीआई, आपको जटिल गणित के बिना चिकनाई की आवश्यकता है।

3. 3 टोकन बाल्टी

पैरामीटर: दर 'आर' (टोकन/सेकंड) और क्षमता 'बी' (फट)। प्रत्येक अनुरोध "बर्न" टोकन।

पेशेवरों: प्राकृतिक फट भत्ता, सरल कार्यान्वयन। विपक्ष: कोई सख्त सावधानी नहीं है।

कब: लगभग हमेशा आरपीएस के लिए, अगर 'बी' के भीतर "वॉलीज़" की आवश्यकता होती है।

3. 4 लीकी बाल्टी (ड्रिप)

कतार जिससे एक निश्चित गति से "लीक" होता है।

पेशेवरों: यहां तक कि आउटपुट प्रवाह। विपक्ष: अधिक देरी।

कब: बाहरी "नाजुक" प्रदाताओं को चिकना।

3. 5 जीसीआरए (सामान्यीकृत सेल दर एल्गोरिथ्म)

• 'TAT _ next = max (, अब) + 1/r', अनुरोध स्वीकार किया जाता है यदि 'अब <= + burstt/r'।
• पेशेवरों: सख्त, सटीक, थोड़ी मेमोरी (कुंजी द्वारा TAT रखें)। विपक्ष: समझने के लिए कठिन।

कब: सख्त नियंत्रण और चिकनाई की आवश्यकता है, वितरित सीमा।

3. 6 प्रतिस्पर्धी सेमाफोर

सक्रिय ऑपरेशन काउंटर; प्रवेश - यदि "टिकट" हैं; बाहर निकलें - रिलीज़।

कब: लंबे समय से चल रहे संचालन, थ्रेड्स, वेबसॉकेट, डाउनलोड।

4) कुंजी मॉडल को सीमित करें

• 'client _ id '/' api _ key '/' user _ id '/' org _ id'
• 'आईपी/एएसएन/जियो' (किसी न किसी सुरक्षा)
• 'समापन बिंदु/विधि' (गर्म मार्ग)
• 'स्कोप/प्लान/टियर' (मुद्रीकरण)
• 'idempotency _ key' (संचालन लिखें)
• एक पदानुक्रम का उपयोग करें: पहले सख्त प्रति-कुंजी, फिर प्रति-संगठन, फिर वैश्विक।

5) लागत मॉडल

• ग्राफक्यूएल: क्षेत्र जटिलता × गहराई।
• REST: प्रतिक्रिया/अनुरोध आकार, संचालन प्रकार (पढ़ें = 1, लिखें = 3, रिपोर्ट = 10)।
• बैच: 'लागत = मिनट (n, टोपी)'।
• हम टोकन को सीमित करते हैं, न कि "अनुरोध": 'बजट - = लागत (क्यू)'।

6) वितरित कार्यान्वयन

6. 1 वाल्ट्स

इन-प्रक्रिया: अल्ट्रा-फास्ट, लेकिन एक सामान्य सीमा नहीं (स्थानीय "नरम" सीमा के लिए उपयुक्त)।

रेडिस: वास्तविक मानक। INCR/EXPIRE, Lua स्क्रिप्ट (परमाणु), स्लाइडिंग विंडो के लिए ZSET, TTL के साथ कुंजियाँ।

दूत/NGINX/Cong/Traefik: बिल्ट-इन फिल्टर; परिधि के लिए सुविधाजनक।

सेवा मेष: साइडकार + वैश्विक तुल्यकालन पर स्थानीय सीमाएं।

6. 2 परमाणु और रेसिंग

रेडिस में लुआ: एक चरण में जाँच और वृद्धिशील।

GCRA: CAS/स्क्रिप्ट के साथ एक TAT संग्रहीत करें।

घड़ी की स्थिरता: एनटीपी, मोनोटोन टाइमर।

शार्डिंग: कुंजी द्वारा लगातार हैश; "गर्म" शार्क से बचें।

6. 3 भू-वितरण

क्षेत्रीय समूहों + ऊपरी वैश्विक (मोटे) पर स्थानीय सीमाएं।

सीआरडीटी/प्रतिकृति - सावधान (देरी, दोहरी खपत)। मार्जिन के साथ क्षेत्रीय सीमाएं बेहतर हैं।

7) नीतियां और प्राथमिकता

योजनाएं: विभिन्न 'आर', 'बी', कोटा के साथ मुफ्त/प्रो/एंटरप्राइज।

प्राथमिकताएं: "महंगे" मार्गों को कम सीमा या अधिक लागत मिलती है।

सूची: एकीकरण के लिए अनुमति-सूची, ASN/प्रॉक्सी/TOP द्वारा इनकार करें।

वृद्धि: यदि आप इसे फिर से पार करते हैं, तो सीमा को कम करें, प्रूफ-ऑफ-वर्क/कैप्चा/चुनौतियां दर्ज करें।

8) कॉन्फ़िग के उदाहरण

8. 1 दूत (HTTP दर सीमा फ़िल्टर, छद्म)

yaml rate_limit:
domain: public-api descriptors:
- key: api_key rate_limit:
unit: second requests_per_unit: 50 burst: 100
- key: api_key value: payments. write rate_limit:
unit: second requests_per_unit: 5 burst: 10

8. 2 NGINX (lua + Redis, छद्म)

nginx lua_shared_dict limits 10m;

location /api/ {
access_by_lua_block {
local key = ngx. var. arg_apikey.. ":".. ngx. var. request_method.. ":".. ngx. var. uri
-- token bucket in Redis (evalsha)
local allowed, retry_after = ratelimit_allow(key, 50, 100) -- r=50/s, b=100 if not allowed then ngx. header["Retry-After"] = retry_after return ngx. exit(429)
end
}
proxy_pass http://backend;
}

8. 3 प्रतिस्पर्धी सीमा (छद्म कोड)

pseudo on_request_start(key):
if redis. incr_with_ttl("sem:" + key, ttl=60) > MAX_CONCURRENCY:
redis. decr("sem:" + key); reject(429)
on_request_finish(key):
redis. decr("sem:" + key)

8. 4 जीसीआरए (स्यूडोकोड)

pseudo params: r tokens/sec, burst b tat = redis. get(key) or now allowed_time = tat - (b / r)
if now < allowed_time: reject(429, retry_after = allowed_time - now)
tat_next = max(tat, now) + 1/r redis. set(key, tat_next, ttl = ceil(b/r) + safety)

9) रिट्रेज़, टाइमआउट और सर्किट ब्रेकर के साथ एकीकरण

पुन: बजट: मुख्य यातायात के एक्स% तक रिट्रे के हिस्से को सीमित करें।

जिटर: जब बैकऑफ़होता है, तो हमेशा जोड़ें - तुल्यकालिक फटने को कम करता है।

सर्किट ब्रेकर: यदि कोई उच्च त्रुटि ('5xx', टाइमआउट) है, तो सीमा को कम करें या कुछ मार्गों को "रीड-ओनली" में स्थानांतरित करें।

हेजिंग: साफ; अपने बजट को दोगुना करने से बचने के लिए लागत पर विचा

10) अवलोकन और प्रबंधन

Метрики: 'आरपीएस _ अनुमोदित', 'आरपीएस _ अवरुद्ध', '429 _ रेट', 'रिट्री _ आफ्टर _ एवीजी', 'बर्स्ट _ यूज्ड', 'कोटा _ शेष', 'सक्रिय _ कॉन्सर्सी'।

लेबल: सीमित कुंजी, क्षेत्र, समापन बिंदु, योजना द्वारा।

निर्णय लॉग (नमूना): विफलता का कारण, वर्तमान काउंटर, कुंजी टीटीएल।

डैशबोर्ड: कीज ़/एंडपॉइंट द्वारा हीट कार्ड, "हॉट" क्लाइंट।

अलर्ट: महत्वपूर्ण मार्गों पर 429> 2-5% की वृद्धि, कोटा की लगातार "थकावट", शार्क का असंतुलन।

11) परीक्षण और सत्यापन

नीतियों के अनुबंध परीक्षण (यदि-तब तालिकाएं)।

लोडिंग: फटने (आर से x10), लंबे पठार, "गंदे" पैटर्न (धीमी गति से पोस्ट, लंबे कनेक्शन)।

अराजकता यातायात: असमान धाराएँ, घड़ी बहाव, रेडिस/मेष बूंद।

A/B-समावेश: समावेश से पहले कैनरी रोलआउट सीमा, छाया-समाधान (लॉग, लेकिन ब्लॉक न करें)।

12) किनारे के मामले और सूक्ष्मताएँ

घड़ी तिरछा: 'अब ()' का उपयोग एकल स्रोत (सर्वर) से करें, क्लाइंट हेडर से नहीं।

Idempotency-Key: लिखने के लिए - रेट्रास में प्रवर्धन को कम करता है।

बैच संचालन: बैच के आकार और कुल लागत को सीमित करें।

लॉन्ग-पोल/वेबसॉकेट: चैनलों/सदस्यता और अवधि की संख्या को सीमित करें।

ठंडी शुरुआत: काउंटरों/प्रीलोड की "गर्म" शुरुआत; अन्यथा झूठे 429 के फटने।

कम्प्यूटेशनल रूप से महंगे अनुरोध: व्यावसायिक तर्क के निष्पादन की सीमा।

टीटीएल: कुंजियों की टीटीएल सीमाएँ विंडो + सुरक्षा मार्जिन को कवर करेंगी।

13) एंटीबॉट वृद्धि

चरण: चेतावनी → 429 + 'रीट्री-आफ्टर' → चुनौती (कैप्चा/पहेली) → अस्थायी ब्लॉक।

सिग्नल: डिवाइस-फिंगरप्रिंट, कर्सर/टाइमिंग व्यवहार, TOR/प्रॉक्सी/होस्टिंग।

नीतियां फोरेंसिक के लिए नियतात्मक और प्रजनन योग्य होनी चाहिए।

14) सुरक्षा और अनुपालन

महत्वपूर्ण मार्गों पर इनकार-दर-डिफ़ॉल्ट (लिखें/वित्त)।

लेखा परीक्षा: नियामक मामलों और घटना समीक्षा के लिए सीमाओं पर निर्णय रखें।

PII: सीमा कुंजियों को लॉग में व्यक्तिगत डेटा का खुलासा नहीं करना चाहिए।

15) प्रोड रेडीनेस चेकलिस्ट

• सीमा कुंजी और लागत मॉडल परिभाषित हैं।
• चयनित एल्गोरिथ्म (टोकन बाल्टी/जीसीआरए) और भंडारण (रेडिस/गेटवे)।
• टियर क्लाइंट + वैश्विक फ्यूज के लिए नीतियां।
• दीर्घकालिक लेनदेन के लिए प्रतिस्पर्धी सीमा
• रीट्री-बजट, जिटर के साथ बैकऑफ, सर्किट ब्रेकर के साथ एकीकरण।
• डैशबोर्ड/अलर्ट, नमूना निर्णय लॉग।
• कैनरी ऑन और शैडो मोड।
• फटने के परीक्षण, लंबे पठार, रेडिस विफलताएं, घड़ी तिरछा।
• ग्राहक प्रलेखन: 429, 'रीट्री-आफ्टर' कोड, घातीय बैकऑफ उदाहरण।

16) टीएल; डीआर

रेडिस/गेटवे के साथ टोकन बाल्टी या जीसीआरए का उपयोग करें, डिजाइन सीमा कुंजी और अनुरोध लागत, लंबे संचालन के लिए प्रतिस्पर्धी सेमाफोर जोड़ें, रीट्री-बजट और सर्किट ब्रेकर के साथ एकीकृत करें, 429 और "फट क्षमता है", कैनरी/छाया