वितरित rate limiting
fixed-window, sliding-window और token-bucket algorithm के लिए Redis counter तथा atomic Lua script का उपयोग करके कई app instance में request limit का समन्वय करें।
वितरित rate limiting, CoddyKit पर Redis कैशिंग और संदेश-विनिमय (Pub/Sub, Streams) का एक निःशुल्क पाठ है। यह 4 में से 4वाँ पाठ है। इस अध्ययन पथ के 3 तक कोई भी पाठ पूरा पढ़ना निःशुल्क है — इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ व्यावहारिक अभ्यास भी उपलब्ध कराता है। यह Redis कैशिंग और संदेश-विनिमय (Pub/Sub, Streams) सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। Redis कैशिंग और संदेश-विनिमय (Pub/Sub, Streams) पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
स्थानीय सीमाएँ बड़े पैमाने पर काम नहीं करतीं
मेमोरी में बना दर सीमाकर्ता केवल एक सर्वर पर आए अनुरोधों की गिनती करता है। लोड बैलेंसर के पीछे कई ऐप इंस्टेंस होने पर, आपको उपयोग का साझा दृश्य चाहिए। Redis केंद्रीय और परमाणु होने के कारण समन्वय का स्वाभाविक केंद्र है।
निश्चित विंडो काउंटर
सबसे सरल एल्गोरिदम: प्रत्येक समय-विंडो के लिए एक काउंटर। कुंजी पर INCR चलाएँ; पहली वृद्धि पर विंडो के बराबर TTL सेट करें। संख्या सीमा से अधिक होने पर अनुरोध अस्वीकार करें।
INCR rl:user:42:1716900000
EXPIRE rl:user:42:1716900000 60रेस कंडीशन
INCR और फिर EXPIRE को दो कमांड के रूप में चलाने पर बीच में क्लाइंट बंद हो जाने की स्थिति में बिना TTL वाली कुंजी रह सकती है। एक परमाणु Lua स्क्रिप्ट दोनों को एक ही संचालन के रूप में चलाकर इसे ठीक करती है।
local c = redis.call('INCR', KEYS[1])
if c == 1 then redis.call('EXPIRE', KEYS[1], ARGV[1]) end
return cपरमाणुता क्यों महत्वपूर्ण है
कई इंस्टेंस में, अन्यथा समवर्ती अनुरोध काउंटर को आपस में गुँथे क्रम में पढ़ और लिख सकते हैं। Lua स्क्रिप्ट सर्वर पर परमाणु रूप से चलती हैं, इसलिए पूरी जाँच और वृद्धि बिना किसी अंतर्वेशन के होती है।
निश्चित विंडो में बर्स्ट की समस्या
निश्चित विंडो की सीमा पर अचानक अधिक अनुरोधों की अनुमति देती हैं: कोई क्लाइंट एक विंडो के अंत में पूरी विंडो के बराबर अनुरोध भेज सकता है और अगली विंडो की शुरुआत में फिर से उतने ही अनुरोध भेज सकता है, जिससे प्रभावी दर दोगुनी हो जाती है।
स्लाइडिंग विंडो लॉग
अनुरोधों के टाइमस्टैम्प का एक क्रमबद्ध सेट सटीक स्लाइडिंग विंडो देता है। पुरानी प्रविष्टियाँ हटाएँ, बची हुई प्रविष्टियों की गिनती करें और नया अनुरोध जोड़ें—यह सब एक ही स्क्रिप्ट में करें।
ZREMRANGEBYSCORE rl:user:42 0 (now-window)
ZCARD rl:user:42
ZADD rl:user:42 now nowटोकन बकेट
टोकन बकेट नियंत्रित बर्स्ट की अनुमति देता है। टोकन एक निश्चित दर से, अधिकतम सीमा तक, फिर से भरते हैं; प्रत्येक अनुरोध एक टोकन खर्च करता है। टोकन और पिछली बार फिर से भरने का समय हैश में रखें और Lua से परमाणु रूप से अपडेट करें।
HSET rl:tb:user:42 tokens 10 ts 1716900000फिर से भरने का तर्क
प्रत्येक अनुरोध पर बीता हुआ समय निकालें, elapsed * rate टोकन जोड़ें (बकेट के आकार तक सीमित रखते हुए), फिर कम-से-कम एक टोकन बचा हो तो अनुरोध की अनुमति दें। Lua स्क्रिप्ट इसे सभी इंस्टेंस में सुसंगत रखती है।
एल्गोरिदम चुनना
निश्चित विंडो: सबसे कम लागत, लेकिन सीमा पर बर्स्ट की अनुमति देती है। स्लाइडिंग लॉग: सटीक, लेकिन अधिक मेमोरी लेता है। टोकन बकेट: नियंत्रित बर्स्ट के साथ सहज प्रवाह, API के लिए शानदार।
उपयोगी हेडर लौटाना
क्लाइंट को उनकी सीमाओं के बारे में बताएँ: बचे हुए अनुरोधों की संख्या और रीसेट समय लौटाएँ, ताकि अच्छी तरह व्यवहार करने वाले क्लाइंट अपनी गति स्वयं सीमित कर सकें।
# X-RateLimit-Remaining: 7
# X-RateLimit-Reset: 1716900060लचीलेपन से जुड़ी बात
यदि Redis उपलब्ध न हो तो फ़ॉलबैक तय करें: उपलब्धता के लिए फ़ेल ओपन (ट्रैफ़िक की अनुमति दें) या सुरक्षा के लिए फ़ेल क्लोज़्ड (अस्वीकार करें)। सही विकल्प इस बात पर निर्भर करता है कि सीमा लागत की रक्षा करती है या शुद्धता की।
त्वरित जाँच
वितरित दर सीमांकन की अपनी समझ जाँचें।
पुनरावलोकन
आपने Redis पर वितरित दर सीमांकन बनाया: निश्चित-विंडो काउंटर, TTL लीक और रेस से बचने के लिए परमाणु Lua, क्रमबद्ध सेट के साथ स्लाइडिंग-विंडो लॉग और सहज बर्स्ट के लिए टोकन बकेट। काउंटरों को केंद्रीय बनाने से सभी ऐप इंस्टेंस में सीमाएँ एकसमान रहती हैं; फ़ेल-ओपन और फ़ेल-क्लोज़्ड फ़ॉलबैक के बीच सोच-समझकर चुनाव करें।
एआई शिक्षक के साथ Redis कैशिंग और संदेश-विनिमय (Pub/Sub, Streams) सीखें — निःशुल्क
अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।
- पाठ्यक्रम
- 12
- पाठ
- 48
अक्सर पूछे जाने वाले प्रश्न
क्या “वितरित rate limiting” पाठ निःशुल्क है?
हाँ — Redis कैशिंग और संदेश-विनिमय (Pub/Sub, Streams) अध्ययन पथ के 3 तक कोई भी पाठ, जिसमें “वितरित rate limiting” भी शामिल है, यहाँ वेब पर पूरा पढ़ना निःशुल्क है। इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ इंटरैक्टिव अभ्यास भी उपलब्ध कराता है। Redis कैशिंग और संदेश-विनिमय (Pub/Sub, Streams) पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
“वितरित rate limiting” में मैं क्या सीखूँगा?
fixed-window, sliding-window और token-bucket algorithm के लिए Redis counter तथा atomic Lua script का उपयोग करके कई app instance में request limit का समन्वय करें। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ Redis कैशिंग और संदेश-विनिमय (Pub/Sub, Streams) का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।
क्या Redis कैशिंग और संदेश-विनिमय (Pub/Sub, Streams) शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?
पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर Redis कैशिंग और संदेश-विनिमय (Pub/Sub, Streams) शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 4वाँ पाठ है।
“वितरित rate limiting” पाठ पूरा करने में कितना समय लगता है?
CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।
क्या मैं इस Redis कैशिंग और संदेश-विनिमय (Pub/Sub, Streams) पाठ में कोड लिख और चला सकता हूँ?
हाँ। हर Redis कैशिंग और संदेश-विनिमय (Pub/Sub, Streams) पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।
इस पाठ्यक्रम के सभी पाठ
- Redis के साथ वितरित लॉक
- लीडर चयन पैटर्न
- समन्वय सेवा के रूप में Redis
- वितरित rate limiting