रेडिस क्लस्टर / लोड संतुलन

यदि आप

redis-trib.rb

फ़ंक्शन में def check_create_parameters . आप एक मास्टर और एक दास प्रतिकृति सेट कर सकते हैं।

इस कॉन्फ़िगरेशन का उद्देश्य दोष सहिष्णुता के लिए है। दासों को पढ़ने के लिए भी इस्तेमाल किया जा सकता है (रीडोनली)। तीन मास्टर्स में, हैशस्लॉट समान रूप से वितरित किए जाते हैं और लोड बैलेंसिंग एल्गोरिदम के साथ आप वास्तविक कुंजी को फिर से वितरित कर सकते हैं। नोड्स के बीच कुंजियों को विचलित करने वाले संभावित एल्गोरिदम के चरण हैं (मेरे द्वारा परीक्षण किया गया और यह अपेक्षा के अनुरूप काम करता है):

1. गुरुओं की भीड़ ढूंढें
2. उनके पास कुल चाबियां प्राप्त करें
3. प्रत्येक मास्टर नोड के लिए होस्टनाम, पोर्ट और कुंजियों की संख्या संग्रहीत करें
4. उन कुंजियों की गणना करें जिन्हें प्रत्येक मास्टर को रखना चाहिए ताकि कुंजियों का वितरण संतुलित हो (क्लस्टर की कुल कुंजियाँ / स्वामी की संख्या)
5. पता लगाएं कि कौन से मास्टर नोड्स को चाबियां लेनी चाहिए या देना चाहिए और कुल चाबियां जो उन्हें देनी चाहिए/लेनी चाहिए
6. मास्टर्स को स्रोत या लक्ष्य नोड्स के रूप में चिह्नित करें, इस पर निर्भर करते हुए कि वे क्रमशः कुंजी प्राप्त कर रहे हैं या दे रहे हैं
7. स्रोत नोड से लक्ष्य नोड्स में माइग्रेट करना प्रारंभ करें, पहले thehashslots और फिर संबंधित कुंजियाँ और तब तक पुनरावृति करें जब तक कि सभी मास्टर्स के पास समान मात्रा में कुंजियाँ न हों

यह एल्गोरिथम प्रतिक्रिया समय को कम करने में मदद करेगा। मेरा क्या मतलब है:

तीन मास्टर्स के साथ प्रतिक्रिया समय को कम किया जा सकता है। यदि आपके पास एक मास्टर के साथ एक कॉन्फ़िगरेशन है और इस मास्टर के पास उदाहरण के लिए 30000 #की हैं, तो एक बार में 1000 कुंजी प्राप्त करने का प्रतिक्रिया समय> 2 मास्टर्स वाले कॉन्फ़िगरेशन से है जिसमें प्रत्येक में 15000 हैं।

यदि आप मास्टर 1 में एक कुंजी बनाते हैं, तो यदि आप मास्टर 2 से उस कुंजी तक पहुंचने (पढ़ने) का प्रयास करते हैं तो आपको एक MOVED त्रुटि मिलेगी। तो, समाधान एक स्मार्ट क्लाइंट बनाना है जो हैशस्लॉट को संबंधित नोड में मैप करता है। इस प्रकार, आप मास्टर2 से केवल उस स्थिति में कुंजी को हटा सकते हैं जब मास्टर2 आपके अनुरोध को सही मास्टर को पुनर्निर्देशित करता है।

आशा है कि यह मदद करता है।