संपादित करें:अब अद्यतन कोड के साथ मेरा मानना है कि आपकी कार्यप्रणाली मौलिक रूप से त्रुटिपूर्ण है जो आप रिपोर्ट कर रहे हैं।
जिस तरह से आपने इसे लागू किया है, आपको KEYSचलाने की आवश्यकता है उत्पादन में - यह बुरा है। जैसे-जैसे आप बड़े होते जाएंगे आप सर्वर पर बढ़ते, और अनावश्यक, सिस्टम ब्लॉकिंग लोड का कारण बनेंगे। जैसा कि इस पर मौजूद हर दस्तावेज कहता है, नहीं करें keys का उपयोग करें उत्पादन में। ध्यान दें कि कुंजी नाम में समाप्ति समय को एन्कोड करने से आपको कोई लाभ नहीं मिलता है। यदि आपने कुंजी नाम के उस हिस्से को निर्माण टाइमस्टैम्प बना दिया है, या यहां तक कि एक यादृच्छिक संख्या भी कुछ भी नहीं बदलेगी। वास्तव में, यदि आप उस बिट को हटा देते हैं, तो कुछ भी नहीं बदलेगा।
इसके बजाय एक अधिक समझदार मार्ग एक कुंजीनाम का उपयोग करना होगा जो समय-निर्भर नहीं है। समाप्ति का उपयोग आपके लिए उस कार्य को संभालता है। आइए हम आपकी दर-सीमित चीज़ को "सत्र" कहते हैं। टाइमस्टैम्प के बिना आपका मुख्य नाम "सत्र आईडी" है। इस पर 60 के दशक की समाप्ति निर्धारित करने से, यह अब 61 के निशान पर उपलब्ध नहीं होगा। तो आप वर्तमान समय या समाप्ति समय जानने की आवश्यकता के बिना परिणाम को सुरक्षित रूप से बढ़ा सकते हैं और अपनी सीमा से तुलना कर सकते हैं। आपको बस एक स्थिर कुंजी नाम और उस पर एक उपयुक्त समाप्ति सेट की आवश्यकता है।
अगर आप INCR एक गैर-मौजूदा कुंजी, रेडिस "1" लौटाएगा जिसका अर्थ है कि उसने कुंजी बनाई और इसे एक चरण/कॉल में बढ़ाया। तो मूल रूप से तर्क इस प्रकार है:
- "सत्र" आईडी बनाएं
- आईडी का उपयोग कर वृद्धि काउंटर
- परिणाम की तुलना सीमा से करें
- अगर गिनती ==1 है, तो समाप्ति को 60 के दशक पर सेट करें
- आईडी गणना> सीमा, अस्वीकार
चरण 3.1 महत्वपूर्ण है। 1 की गिनती का मतलब है कि यह रेडिस में एक नई कुंजी है, और आप इस पर अपनी समाप्ति सेट करना चाहते हैं। किसी और चीज का मतलब है कि समाप्ति पहले ही निर्धारित की जानी चाहिए थी। यदि आप इसे 3.2 में सेट करते हैं तो आप प्रक्रिया को तोड़ देंगे क्योंकि यह काउंटर को 60 से अधिक के लिए सुरक्षित रखेगा।
इसके साथ आपको समाप्ति समय के आधार पर गतिशील कुंजी नाम रखने की आवश्यकता नहीं है, और इस प्रकार keys का उपयोग करने की आवश्यकता नहीं है यह पता लगाने के लिए कि क्या दर-सीमित वस्तु के लिए कोई मौजूदा "सत्र" है। यह आपके कोड को बहुत सरल और अनुमानित बनाता है, साथ ही रेडिस के लिए राउंड ट्रिप को कम करता है - जिसका अर्थ है कि यह रेडिस पर कम लोड होगा और बेहतर प्रदर्शन करेगा। आप जिस क्लाइंट लाइब्रेरी का उपयोग कर रहे हैं उसे कैसे करें, मैं नहीं कह सकता क्योंकि मैं इससे परिचित नहीं हूं। लेकिन मूल अनुक्रम इसके लिए अनुवाद योग्य होना चाहिए क्योंकि यह काफी बुनियादी और सरल है।
हालाँकि, आपने जो नहीं दिखाया है, वह इस दावे का समर्थन करने के लिए कुछ भी है कि समाप्ति नहीं हो रही है। आपने केवल यह दिखाया है कि रेडिस को वास्तव में कहा जा रहा है और एक समाप्ति निर्धारित कर रहा है। अपने दावे का समर्थन करने के लिए आपको यह दिखाना होगा कि कुंजी समाप्त नहीं होती है। जिसका अर्थ है कि आपको समाप्ति समय के बाद कुंजी की पुनर्प्राप्ति दिखाने की आवश्यकता है, और यह कि समाप्ति के बाद काउंटर को "रीसेट" नहीं किया गया था। एक तरीका है कि आप देख सकते हैं कि समाप्ति हो रही है, कीस्पेस नोटिफिकेशन का उपयोग करना है। इसके साथ आप रेडिस को यह कहते हुए देख पाएंगे कि एक कुंजी की समय सीमा समाप्त हो गई है।
जहां यह प्रक्रिया थोड़ी विफल हो जाएगी, यदि आप दर-सीमित करने के लिए कई विंडो करते हैं, या यदि आपके पास बहुत बड़ी विंडो (यानी 10 मिनट) है, तो इस स्थिति में सॉर्ट किए गए सेट अनुरोधों के फ्रंट-लोडिंग को रोकने के लिए अधिक समझदार विकल्प हो सकते हैं। - अगर चाहा। लेकिन जैसा कि आपका उदाहरण लिखा गया है, उपरोक्त ठीक काम करेगा।
