Go-cache: फ़ीचर अनुरोध: अधिकतम आकार और/या अधिकतम ऑब्जेक्ट

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

सबसे अच्छा समाधान शायद एक नया कैश प्रकार बनाना होगा जो उन वस्तुओं को संग्रहीत करता है जो एक आकार योग्य इंटरफ़ेस को संतुष्ट करते हैं जहां foo.Size() एक पूर्णांक के रूप में अपने सापेक्ष आकार का प्रतिनिधित्व करता है। इस तरह से विटेस का एलआरयू कैश करता है: https://code.google.com/p/vitess/source/browse/go/cache/lru_cache.go यह उस जिम्मेदारी को उपयोगकर्ता को हस्तांतरित कर देगा। मुझे पूरी तरह से यकीन नहीं है कि उपयोगकर्ता इसे कई मामलों में आसानी से निर्धारित कर सकते हैं, यानी जब वे कुछ अधिक जटिल संग्रहित कर रहे हैं जैसे [] बाइट फ़ील्ड या कुछ के साथ एक संरचना, जैसे स्ट्रक्चर या स्लाइस का नक्शा।

एक अन्य समाधान किसी भी समय कैश में आइटम्स की संख्या को सीमित करना होगा, लेकिन यह मानता है कि प्रत्येक कैश आइटम लगभग एक ही आकार का होता है। इसके साथ सबसे बड़ी समस्या जरूरत पड़ने पर निकालने के लिए सही वस्तुओं का चयन करना है। ऐसा कैश संभवतः एलआरयू का क्लोन बन जाएगा (अर्थात यह ट्रैक करता है कि आइटम को अंतिम बार कब एक्सेस किया गया था, और स्टोरेज के लिए मानचित्र के अलावा/के अलावा कुछ और उपयोग करता है) जहां प्रत्येक आइटम का आकार समान होता है, उदाहरण के लिए 1.

मैं गो-कैश में इस तक पहुंचने के सर्वोत्तम तरीके के बारे में सोचता रहूंगा, लेकिन मेरी आंत अभी महसूस कर रही है:

• यदि आप स्मृति को समाप्त कर रहे हैं, तो शायद समाप्ति अवधि कम होनी चाहिए?
• यदि समाप्ति अवधि पहले से ही कम है, और स्मृति उपयोग अभी भी विस्फोट हो रहा है, तो क्या यह मान लेना सुरक्षित है कि इस प्रणाली के लिए कई फ्रंटएंड/एप्लिकेशन फ़्रंटएंड हैं? उस स्थिति में, शायद समर्पित memcached बक्से का उपयोग करना बेहतर होगा? यहां एक बड़ा लाभ यह है कि आप लंबे समय तक आइटम कैश कर सकते हैं, लेकिन फिर भी बड़े कैश क्लस्टर से आइटम को मैन्युअल रूप से समाप्त कर सकते हैं, भले ही कई फ्रंटएंड कैश का उपयोग कर रहे हों।

विस्तृत उत्तर और विटेस कैश के लिंक के लिए धन्यवाद।

मुझे लगता है कि आप सही हैं कि वस्तुओं के आकार को करने के लिए उपयोगकर्ता को मदद की आवश्यकता होगी। मैं भोलेपन से सोच रहा था कि इसका आत्मनिरीक्षण किया जा सकता है लेकिन आप सही हैं, वस्तुएं मनमाने ढंग से जटिल संरचनाओं की ओर इशारा कर सकती हैं, जिन्हें कैश में रखने की आवश्यकता हो सकती है या नहीं। जैसा कि आपने सुझाव दिया था, उपयोगकर्ता Sizeable इंटरफ़ेस के साथ आकार का अनुमान लगा सकता है।

मुझे अभी भी लगता है कि कुल वस्तुओं की सीमा उपयोगी होगी। मान लें कि आप 24 घंटे के लिए उपयोगकर्ता सत्र संग्रहीत कर रहे हैं। हालाँकि आप एक बॉट-नेट के गलत छोर पर पहुँच जाते हैं जो बहुत कम समय में बहुत सारे सत्र करता है। इस तरह का परिदृश्य है कि स्मृति उपयोग में विस्फोट हो जाता है। इस मामले में फ्लशिंग उपयोगकर्ता सत्र आदर्श नहीं होंगे लेकिन यह स्मृति से बाहर जाने के बजाय सर्वर को चालू रखेगा।

Memcached निश्चित रूप से इस मामले में काम कर सकता है, लेकिन मुझे go-cache साथ इसे वास्तव में कुशलतापूर्वक करने का विचार पसंद है।

मैं यह नोट करना चाहूंगा कि मेरा भी मानना ​​है कि कुल वस्तुओं की सीमा उपयोगी होगी।

विलंब के लिए क्षमा चाहते हैं। मैं अभी भी इस बारे में सोच रहा हूं कि इसे अच्छी तरह से कैसे किया जाए, अर्थात् विटेस की एक प्रति को लागू किए बिना वस्तुओं को सर्वोत्तम तरीके से कैसे बेदखल किया जाए (और वस्तुओं की एक अतिरिक्त सूची बनाए रखने/गेट पर रीफ्रेशिंग आइटम बनाए रखने का ऊपरी भाग।) मैं मानता हूं कि यह परेशानी है अगर कोई आपके आइटम की संख्या में विस्फोट करता है।

क्या रेडिस कैश से चीजों को बेतरतीब ढंग से बेदखल नहीं करता है? मुझे लगता है कि मुझे "गलत" तत्व को बेदखल करने के बाद मेरे कैश की स्मृति को सीमित करने के बारे में अधिक परवाह है। हो सकता है कि हम प्लग करने योग्य बेदखल करने के लिए वास्तविक अहंकार बना सकते हैं और यादृच्छिक निष्कासन के साथ शुरू कर सकते हैं, फैंसी बुक कीपिंग की आवश्यकता नहीं थी।

मुझे एलआरयू दृष्टिकोण सबसे अच्छा लगता है लेकिन इसके साथ ही रीड-हैवी लोड के लिए चिंता का विषय है, और प्रत्येक कैश्ड आइटम के लिए Ctime/Atime का मेमोरी उपयोग।

यादृच्छिक निष्कासन काम कर सकता है, लेकिन मुझे नहीं पता कि इसे लागू करने का कोई विश्वसनीय तरीका है, यह देखते हुए कि अंतर्निहित भंडारण नक्शा है। नक्शा ट्रैवर्सल अप्रत्याशित है लेकिन वास्तव में यादृच्छिक नहीं है, इसलिए आप केवल ट्रैवर्स नहीं कर सकते हैं, पहली कुंजी चुन सकते हैं और इसे हटा सकते हैं: https://play.golang.org/p/lUw_1oPTLB लेकिन शायद यह बड़े मानचित्रों के लिए चिंता का विषय नहीं है ...

आलसी कैश के लिए रैंडम बेदखली ठीक है, लेकिन जब आपका कैश रीड-इंटेंस होता है, तो वस्तुएं उत्पन्न करने के लिए महंगी होती हैं, और आप कुछ गर्म वस्तुओं को बेदखल कर देते हैं (और इस तरह तुरंत कैश-मिस), यह दर्द होता है।

दिलचस्प समय; यह सिर्फ एचएन मारा: https://danluu.com/2choices-eviction/

हमारे पास दोनों विकल्प हो सकते हैं, लेकिन LRU अभी भी सबसे अच्छा लगता है क्योंकि हमारे पास कुछ समानांतर डेटा संरचना को बनाए रखे बिना कैश से यादृच्छिक वस्तुओं का चयन करने का एक अच्छा तरीका नहीं है।

मैं भी इस सुविधा के लिए वोट करने जा रहा हूं। मैं अब भी इसका उपयोग करूँगा, लेकिन बहुत सावधानी के साथ। एक बॉट-हमला ऊपरी सीमा के बिना मेरी सेवा को मार देगा।

मैं सत्र कुंजियों के संबंध में उपयोगकर्ता वस्तुओं को कैशिंग करने के लिए इसका उपयोग करने जा रहा था, इसलिए मुझे हर अनुरोध पर अपने डीबी को हिट करने की आवश्यकता नहीं है। इसलिए एक्सपायरी टाइम इसके लिए बहुत अच्छा है। मैं आकार से अधिक होने पर बेतरतीब ढंग से छोड़ने वाली प्रविष्टियों के साथ ठीक रहूंगा। यह और भी बेहतर होगा अगर यह सबसे पुरानी वस्तु को छोड़ दे, लेकिन मुझे लगता है कि उस पर एक प्रदर्शन हिट होगा।

अच्छा विचार, बग मुझे लगता है कि डिज़ाइन सीमा अधिकतम मेमोरी बेहतर है।

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