मैं कहूंगा कि यह मुख्य समाप्ति से जुड़ा हुआ है।
Redis या memcached जैसे कुंजी/मूल्य स्टोर समाप्त होने के लिए प्रति ऑब्जेक्ट भौतिक टाइमर को परिभाषित करने का जोखिम नहीं उठा सकते हैं। उनमें से बहुत सारे होंगे। इसके बजाय वे समाप्त होने वाली वस्तुओं को आसानी से ट्रैक करने के लिए डेटा संरचना को परिभाषित करते हैं, और सभी समाप्ति घटनाओं को एक भौतिक टाइमर में मल्टीप्लेक्स करते हैं। वे इन घटनाओं से निपटने के लिए एक आलसी रणनीति भी लागू करते हैं।
रेडिस के साथ, जब कोई आइटम समाप्त हो जाता है, तो कुछ भी नहीं होता है। हालांकि, प्रत्येक आइटम तक पहुंचने से पहले, समय-सीमा समाप्त वस्तुओं को वापस करने से बचने के लिए व्यवस्थित रूप से एक जांच की जाती है, और संभावित रूप से आइटम को हटा दिया जाता है। इस आलसी रणनीति के शीर्ष पर, प्रत्येक 100 एमएस, एक मेहतर एल्गोरिथ्म को भौतिक रूप से कई वस्तुओं को समाप्त करने के लिए ट्रिगर किया जाता है (यानी उन्हें मुख्य शब्दकोश से हटा दें)। प्रत्येक पुनरावृत्ति पर विचार की गई कुंजियों की संख्या समाप्ति कार्यभार पर निर्भर करती है (एल्गोरिदम अनुकूली है)।
परिणाम यह है कि जब आपके पास समाप्ति की घटनाओं का एक स्थिर प्रवाह होता है, तो रेडिस के पास एक निश्चित समय पर समाप्त होने के लिए वस्तुओं का एक बैकलॉग हो सकता है।
अब प्रश्न पर वापस आते हैं, DBSIZE कमांड मुख्य शब्दकोश का आकार लौटाता है, इसलिए इसमें समाप्त हो चुके आइटम शामिल हैं जिन्हें अभी तक हटाया नहीं गया है। KEYS कमांड अलग-अलग कुंजियों तक पहुँचने के लिए पूरे शब्दकोश के माध्यम से चलता है, इसलिए यह सभी समाप्त हो चुकी वस्तुओं को बाहर कर देता है। इसलिए मदों की संख्या मेल नहीं खा सकती है।
