प्रॉम्प्ट और संदर्भ
कई रेप्लिकास समन्वय स्टोरेज (coordination storage) साझा करते हैं और उन्हें यह सुनिश्चित करना होगा कि एक समय में केवल एक ही इंस्टेंस शेड्यूल किए गए सेटलमेंट जॉब को चलाए। लीज रिकॉर्ड, कैंपेन (campaign), रिन्यूअल (renewal), हैंडऑफ और ऑब्ज़र्वेबिलिटी को डिज़ाइन करें। पार्टिशन्स, प्रोसेस पॉज़ (process pauses), क्लॉक ड्रिफ्ट और स्टोरेज विफलता को कवर करें। एक लीज यह नियंत्रित करती है कि कौन काम शुरू कर सकता है; व्यावसायिक राइट्स (business writes) के लिए अभी भी इडेम्पोटेंसी (idempotency) और सशर्त जांच (conditional checks) की आवश्यकता होती है।
इंटरव्यूअर क्या टेस्ट कर रहा है
- क्या आप लीज सुरक्षा को व्यावसायिक दुष्प्रभावों (business side effects) से अलग रखते हैं।
- क्या आप एटॉमिक कम्पेयर-एंड-सेट (atomic compare-and-set), टर्म फेंसिंग टोकन (term fencing tokens) और कोरम (quorums) को समझते हैं।
- क्या आप समझा सकते हैं कि प्रोसेस पॉज़, पार्टिशन्स और पुनर्जीवित पुराना लीडर वैध दोहरे राइटर्स (dual writers) क्यों नहीं बनाते हैं।
- क्या आप मापने योग्य सिग्नल्स, फॉल्ट इंजेक्शन और रिकवरी व्यवहार को परिभाषित करते हैं।
उत्तर देने से पहले स्पष्टीकरण हेतु प्रश्न
अनुमत पॉज़ विंडो, सहन की जाने वाली डुप्लिकेट निष्पादन सीमा, समन्वय स्टोर की स्थिरता (consistency), क्रॉस-रीजन लेटेंसी, रेप्लिका संख्या और क्लॉक-सिंक्रोनाइज़ेशन गुणवत्ता की पुष्टि करें। यदि क्रॉस-रीजन मजबूत स्थिरता की आवश्यकता है, तो उपलब्धता और चुनाव-लेटेंसी के बीच के ट्रेड-ऑफ को स्पष्ट करें।
30-सेकंड का उत्तर फ्रेमवर्क
ऐसे समन्वय स्टोरेज का उपयोग करें जो लीनियरिज़ेबल रीड्स (linearizable reads) और सशर्त राइट्स (conditional writes) प्रदान करता हो। प्रत्येक उम्मीदवार एक अद्वितीय पहचान (unique identity) और लगातार बढ़ते हुए टर्म (monotonically increasing term) के साथ प्रतिस्पर्धा करता है; केवल सफल एटॉमिक निर्माण या अपडेट ही लीडर बनता है। लीडर लीज समाप्त होने से पहले उसे रिन्यू करता है। प्रत्येक व्यावसायिक राइट में टर्म टोकन होता है, और डाउनस्ट्रीम सिस्टम पुराने टोकन को अस्वीकार कर देते हैं। एक उम्मीदवार नई स्थिति की पुष्टि करने के बाद ही कार्यभार संभालता है। किसी पार्टिशन या लंबे पॉज़ के दौरान, इंस्टेंस दुष्प्रभावों को रोक देता है; दोहरे राइटर्स की तुलना में एक संक्षिप्त आउटेज अधिक सुरक्षित है।
चरण-दर-चरण गहन विश्लेषण
1. डेटा मॉडल और एटॉमिक ऑपरेशन्स
लीज रिकॉर्ड में धारक की पहचान, समाप्ति समय, टर्म टोकन, संस्करण (version) और अंतिम रिन्यूअल समय शामिल होता है। प्रतिस्पर्धा compare-and-set का उपयोग करती है: अनुपस्थित होने पर बनाएं, या केवल तभी अपडेट करें जब संस्करण अपरिवर्तित हो और लीज समाप्त हो गई हो। Kubernetes लीज को समन्वय ऑब्जेक्ट्स के रूप में प्रस्तुत करता है जिसमें धारक और रिन्यूअल की जानकारी होती है; कार्यान्वयन को अंततः सुसंगत (eventually consistent) कैश पर भरोसा करने के बजाय स्टोरेज कंसिस्टेंसी मॉडल को सत्यापित करना चाहिए।
2. रिन्यूअल और सेल्फ-डिमॉशन (Self-demotion)
लीज अवधि के भीतर पर्याप्त समय रहते रिन्यू करें, जिससे नेटवर्क जिटर और शेड्यूलर पॉज़ के लिए गुंजाइश रहे। यदि रिन्यूअल विफल हो जाता है, पुष्टिकरण नहीं पढ़ा जा सकता है, या प्रक्रिया सुरक्षा विंडो से अधिक समय तक रुक जाती है, तो तुरंत दुष्प्रभावों को रोकें और रिकवरी के बाद फिर से कैंपेन करें। केवल स्थानीय वॉल क्लॉक (wall clock) के आधार पर किसी अन्य धारक की समाप्ति का निर्णय न लें।
3. फेंसिंग और व्यावसायिक इडेम्पोटेंसी
प्रत्येक सफल कैंपेन एक मोनोटोनिक टोकन उत्पन्न करता है। वर्कर्स, कंडीशनल डेटाबेस अपडेट, या डाउनस्ट्रीम सेवाएं पुराने टोकन वाले अनुरोधों को अस्वीकार कर देती हैं। इस प्रकार एक पुराना लीडर जो पॉज़ के बाद सक्रिय होता है, वह नए लीडर के राइट्स को अधिलेखित (overwrite) नहीं कर सकता है। सेटलमेंट के लिए अभी भी इडेम्पोटेंसी कीज़ (idempotency keys), ट्रांजेक्शन सीमाओं और पुनः प्रयास प्रबंधन (retry handling) की आवश्यकता होती है।
उच्च-गुणवत्ता वाला नमूना उत्तर
मैं सुरक्षा (safety) को एक ही समय में दो वैध लीडर्स को एक ही संसाधन पर लिखने से रोकने के रूप में परिभाषित करता हूँ; उपलब्धता लीज समाप्ति के बाद एक छोटे विराम की अनुमति देती है। समन्वय स्टोर लीनियरिज़ेबल CAS प्रदान करता है। एक उम्मीदवार अपनी पहचान और बढ़ते टर्म को रिकॉर्ड करता है, और लीडर हार्टबीट्स के साथ रिन्यू करता है। प्रत्येक दुष्प्रभाव में टर्म टोकन होता है, जिसकी तुलना डाउनस्ट्रीम सशर्त राइट्स द्वारा की जाती है। यदि कोई पार्टिशन, GC पॉज़, या खोया हुआ रिन्यूअल पुष्टिकरण होता है, तो इंस्टेंस रुक जाता है और केवल स्थिति की पुनः पुष्टि करने के बाद ही कैंपेन करता है; कुछ सेकंड के लिए सो जाना (sleeping) सुरक्षा का प्रमाण नहीं है। Raft लॉग लीडरशिप के लिए टर्म्स और बहुमत मतदान (majority voting) का उपयोग करता है, जबकि एक Kubernetes Lease एक हल्का समन्वय रिकॉर्ड है। दोनों को एक स्पष्ट कंसिस्टेंसी मॉडल, टाइमआउट बजट और रिकवरी योजना की आवश्यकता होती है। मैं लीडर क्रैश, पार्टिशन्स, क्लॉक ऑफसेट्स, लंबे पॉज़ और अनुपलब्ध स्टोरेज को इंजेक्ट करूँगा, फिर दोहरे राइट्स, पुराने-टोकन राइट्स और रिकवरी-टाइम उल्लंघनों की जांच करूँगा।
सामान्य गलतियां
- केवल प्रोसेस मेमोरी में लॉक रखना या अंततः सुसंगत Redis रीड्स पर भरोसा करते हुए यह दावा करना कि कोई दोहरा लीडर संभव नहीं है।
- मोनोटोनिक टर्म्स और फेंसिंग टोकन के बिना टाइमस्टैम्प की तुलना करना।
- रिन्यूअल विफलता के बाद भी वर्तमान बैच को जारी रखना, जिससे पुराने लीडर को राइट विंडो मिल जाती है।
- एक समय में एक लीडर होने को कभी भी डुप्लिकेट निष्पादन न होने के बराबर मान लेना।
- केवल सामान्य चुनावों का परीक्षण करना, पॉज़, पार्टिशन्स, स्टोरेज लेटेंसी या स्टोरेज विफलता का परीक्षण न करना।
फॉलो-अप प्रश्न और उत्तर
क्या लीज समाप्ति यह गारंटी देती है कि पुराना लीडर रुक गया है?
नहीं। कोई प्रक्रिया चलते रहने के दौरान भी रुक (pause) सकती है या अलग-थलग (isolated) रह सकती है। व्यावसायिक सीमा पर फेंसिंग टोकन को मान्य करें; समाप्ति का केवल यह अर्थ है कि समन्वय परत अब उस धारक को मान्यता नहीं देती है।
आप लीज और रिन्यूअल अंतराल कैसे चुनते हैं?
विफलता-पहचान लक्ष्य (failure-detection target), क्रॉस-रीजन p99 लेटेंसी, शेड्यूलर-पॉज़ बजट और स्टोरेज जिटर से कई रिन्यूअल चक्रों के मार्जिन के साथ इन्हें प्राप्त करें। एक निश्चित मिलीसेकंड मान की नकल करने के बजाय रिन्यूअल विफलताओं और चुनावी अस्थिरता (election churn) की निगरानी करें।
क्या होगा यदि समन्वय स्टोरेज अनुपलब्ध हो?
नए दुष्प्रभावों को रोकें और केवल रीड-ओनली या सुरक्षित रूप से कमिट किए गए परिणामों को बनाए रखें। रिकवरी के बाद, टर्म को फिर से पढ़ें और कैंपेन करें। यदि निरंतर संचालन अनिवार्य है, तो स्पष्ट रूप से शार्डिंग, मल्टी-एक्टिव स्वामित्व, या मानव हस्तक्षेप में डिग्रेड करें और सुरक्षा प्रमाण को फिर से बताएं।