AFAIK, पहले पुराने डेटा को लगातार बेदखल करने के लिए रेडिस को कॉन्फ़िगर करना संभव नहीं है।
जब मैक्समेमोरी-पॉलिसी में *-ttl या *-lru विकल्प चुने जाते हैं, तो Redis हटाए जाने वाली कुंजियों को चुनने के लिए सटीक एल्गोरिथम का उपयोग नहीं करता है। एक सटीक एल्गोरिदम को स्मृति में एक अतिरिक्त सूची (* -lru के लिए) या एक अतिरिक्त ढेर (* -ttl के लिए) की आवश्यकता होगी, और इसे सामान्य रेडिस शब्दकोश डेटा संरचना के साथ क्रॉस-रेफरेंस की आवश्यकता होगी। स्मृति खपत के मामले में यह महंगा होगा।
वर्तमान तंत्र के साथ, मुख्य घटना लूप में निष्कासन होता है (अर्थात प्रत्येक आदेश के निष्पादित होने से पहले प्रत्येक लूप पुनरावृत्ति पर संभावित निष्कासन की जाँच की जाती है)। जब तक मेमोरी अधिकतम मेमोरी सीमा के तहत वापस नहीं आती है, रेडिस बेतरतीब ढंग से n कुंजियों का एक नमूना चुनता है, और समाप्ति के लिए सबसे निष्क्रिय (* -lru के लिए) या जो इसकी समाप्ति सीमा (* -ttl के लिए) के सबसे करीब है, का चयन करता है। डिफ़ॉल्ट रूप से केवल 3 नमूनों पर विचार किया जाता है। परिणाम गैर नियतात्मक है।
इस एल्गोरिथ्म की सटीकता बढ़ाने और समस्या को कम करने का एक तरीका माना नमूनों की संख्या में वृद्धि करना है (कॉन्फ़िगरेशन फ़ाइल में अधिकतम मेमोरी-नमूने पैरामीटर)। इसे बहुत अधिक सेट न करें, क्योंकि यह कुछ सीपीयू का उपभोग करेगा। यह बेदखली सटीकता और CPU खपत के बीच एक समझौता है।
अब यदि आपको वास्तव में एक सुसंगत व्यवहार की आवश्यकता है, तो एक समाधान रेडिस के शीर्ष पर अपने स्वयं के निष्कासन तंत्र को लागू करना है। उदाहरण के लिए, आप उन चाबियों को ट्रैक करने के लिए एक सूची (गैर अद्यतन योग्य कुंजियों के लिए) या एक क्रमबद्ध सेट (अद्यतन करने योग्य कुंजियों के लिए) जोड़ सकते हैं जिन्हें पहले बेदखल किया जाना चाहिए। फिर, आप एक डेमॉन जोड़ते हैं जिसका उद्देश्य समय-समय पर (INFO का उपयोग करके) मेमोरी खपत की जांच करना है और संबंधित कुंजियों को हटाने के लिए सूची/सॉर्ट किए गए सेट के आइटम को क्वेरी करना है।
कृपया ध्यान दें कि इस समस्या से निपटने के लिए अन्य कैशिंग सिस्टम का अपना तरीका है। उदाहरण के लिए memcached के साथ, प्रति स्लैब में एक LRU संरचना होती है (जो वस्तु के आकार पर निर्भर करती है), इसलिए निष्कासन आदेश भी सटीक नहीं है (हालांकि व्यवहार में Redis की तुलना में अधिक नियतात्मक)।
