पाठ 31 / 32
एक वितरित कैश डिज़ाइन करें
Consistent hashing, replication और LRU eviction वाला distributed cache design करें जो node failures झेल सके।
आवश्यकताएँ
उप-मिलीसेकंड लेटेंसी के साथ की से GET/SET/DELETE, एक मशीन के RAM से कहीं अधिक क्षमता, और व्यक्तिगत नोड विफलता पर सब कुछ खोए बिना जीवित रहना।
कंसिस्टेंट हैशिंग से शार्डिंग
कंसिस्टेंट हैशिंग से नोड्स में की वितरित करें ताकि क्लस्टर बिना बड़े रीहैश के बढ़ सके। क्लाइंट (या एक प्रॉक्सी परत) एक हॉप में यह जानने के लिए की को स्थानीय रूप से हैश करते हैं कि किस नोड से सीधे बात करनी है।
एविक्शन एक बाउंसर की तरह
मेमोरी सीमित है, इसलिए हर नोड एक एविक्शन नीति चलाता है (आमतौर पर LRU) — एक बाउंसर जो नए मेहमानों को अंदर आने देने के लिए उसे बाहर निकालता है जो सबसे लंबे समय से बिना छुए खड़ा है। इसके ऊपर प्रति-की TTL सेट करें ताकि कुछ भी हमेशा के लिए न रुके।
त्वरित जाँच: नोड विफलता पर ओरिजिन डेटाबेस पर निर्भर रहने के बजाय हर कैश शार्ड को रेप्लिकेट क्यों करें?
- रेप्लिकेशन कानून द्वारा आवश्यक है
- इसके बिना, एक शार्ड खोने पर मिस की बाढ़ सीधे डेटाबेस पर जाती है
- रेप्लिकेशन राइट को तेज़ बनाता है
- Replicas से eviction की जरूरत खत्म हो जाती है
Answer
इसके बिना, एक शार्ड खोने पर मिस की बाढ़ सीधे डेटाबेस पर जाती है — एक ठंडा शार्ड का मतलब है उसकी हर की की रिक्वेस्ट मिस बन जाती है, जब तक वह फिर गर्म न हो तब तक डेटाबेस पर बोझ पड़ता है — रेप्लिका इस गिरावट से बचाते हैं।