मैं पिछले हफ्ते लिनक्स लोगों के साथ परिदृश्यों का परीक्षण करने और इस कार्यान्वयन के सी # पक्ष पर काम करने में सक्षम था और निम्नलिखित दृष्टिकोण का उपयोग कर रहा हूं:
- कॉन्फ़िगरेशन से प्रहरी पतों को पढ़ें और उनसे कनेक्ट करने के लिए एक कनेक्शन मल्टीप्लेक्सर बनाएं
- +स्विच-मास्टर चैनल की सदस्यता लें
- प्रत्येक प्रहरी सर्वर से बारी-बारी से पूछें कि वे क्या सोचते हैं कि मास्टर रेडिस और दास क्या हैं, उन सभी की तुलना करके सुनिश्चित करें कि वे सभी सहमत हैं
- सेंटीनेल से पढ़े गए रेडिस सर्वर पतों के साथ एक नया कनेक्शन मल्टीप्लेक्सर बनाएं और कनेक्ट करें, इवेंट हैंडलर को कनेक्शनफेल और कनेक्शन रीस्टोर में जोड़ें।
- जब मुझे +स्विच-मास्टर संदेश प्राप्त होता है तो मैं रेडिस कनेक्शन मल्टीप्लेक्सर पर कॉन्फ़िगर() को कॉल करता हूं
- एक बेल्ट और ब्रेसिज़ दृष्टिकोण के रूप में मैं हमेशा कनेक्शन प्राप्त करने के 12 सेकंड बाद रेडिस कनेक्शन मल्टीप्लेक्सर पर कॉन्फ़िगर () को कॉल करता हूं, कनेक्शन प्रकार कनेक्शन प्रकार होने पर कनेक्शन विफल या कनेक्शन पुनर्स्थापित घटना।
मुझे लगता है कि आम तौर पर मैं काम कर रहा हूं और रेडिस मास्टर को खोने के लगभग 5 सेकंड के बाद पुन:कॉन्फ़िगर किया गया है। इस दौरान मैं लिख नहीं सकता लेकिन मैं पढ़ सकता हूं (क्योंकि आप गुलाम को पढ़ सकते हैं)। 5 सेकंड हमारे लिए ठीक है क्योंकि हमारा डेटा बहुत तेज़ी से अपडेट होता है और कुछ सेकंड के बाद पुराना हो जाता है (और बाद में इसे अधिलेखित कर दिया जाता है)।
एक चीज जिसके बारे में मुझे यकीन नहीं था, वह यह थी कि जब कोई इंस्टेंस कम हो जाता है, तो मुझे रेडिस सर्वर को रेडिस कनेक्शन मल्टीप्लेक्सर से हटा देना चाहिए या नहीं, या इसे कनेक्शन को फिर से प्रयास करना जारी रखना चाहिए। मैंने इसे फिर से प्रयास करने के लिए छोड़ने का फैसला किया क्योंकि यह वापस आते ही एक दास के रूप में मिश्रण में वापस आ जाता है। मैंने कनेक्शन के साथ और उसके बिना कुछ प्रदर्शन परीक्षण किए और ऐसा लगता है कि इससे थोड़ा फर्क पड़ता है। शायद कोई स्पष्ट कर सके कि क्या यह सही तरीका है।
हर बार और फिर एक उदाहरण वापस लाना जो पहले एक मास्टर था, कुछ भ्रम पैदा करता था - इसके वापस आने के कुछ सेकंड बाद मुझे लेखन से एक अपवाद प्राप्त होगा - "रीडोनली" यह सुझाव देता है कि मैं एक दास को नहीं लिख सकता। यह दुर्लभ था लेकिन मैंने पाया कि कनेक्शन स्थिति परिवर्तन के 12 सेकंड बाद कॉन्फ़िगर() को कॉल करने के मेरे "कैच-ऑल" दृष्टिकोण ने इस समस्या को पकड़ा। कॉन्फिगर () को कॉल करना बहुत सस्ता लगता है और इसलिए इसे दो बार कॉल करना, भले ही यह आवश्यक हो या नहीं, ठीक लग रहा था।
अब जबकि मेरे पास दास हैं, मैंने अपना कुछ डेटा क्लीनअप कोड उतार दिया है जो दासों को कुंजी स्कैन करता है, जिससे मुझे खुशी मिलती है।
कुल मिलाकर मैं काफी संतुष्ट हूं, यह सही नहीं है, लेकिन कुछ ऐसा जो बहुत कम ही होना चाहिए, वह काफी अच्छा है।
