सिस्टम डिज़ाइन इंटरव्यू: आप एक सेफ़ लीडर इलेक्शन सर्विस कैसे डिज़ाइन करेंगे?

प्रॉम्प्ट और संदर्भ

कई स्टेटलेस वर्कर्स में से एक समय में केवल एक ही इंस्टेंस को शेड्यूल किया गया सेटलमेंट जॉब चलाना चाहिए। वर्कर्स क्रैश हो सकते हैं, रीस्टार्ट हो सकते हैं, पॉज़ हो सकते हैं या पार्टीशन में फंस सकते हैं, और सिस्टम को दो वर्कर्स को लंबे समय तक राइट (write) करने की अनुमति नहीं देनी चाहिए। कोऑर्डिनेटर, लीज़, रिन्यूअल, फ़ेंसिंग, फ़ेलओवर और ऑपरेशनल सीमाओं के साथ लीडर इलेक्शन डिज़ाइन करें। इसका मूल उद्देश्य केवल एक म्यूटेक्स (mutex) नहीं, बल्कि सुरक्षित सिंगल-राइटर कोऑर्डिनेशन है।

इंटरव्यूअर क्या टेस्ट कर रहा है

सेफ़्टी (safety) और लाइवनेस (liveness) को परिभाषित करना

सेफ़्टी का अर्थ है कि किसी टर्म (term) के लिए रिसोर्स द्वारा अधिकतम एक ही लीडर स्वीकार किया जाए; लाइवनेस का अर्थ है कि पुरानी लीज़ की समाप्ति की पुष्टि होने के बाद कोई स्वस्थ कैंडिडेट अंततः कार्यभार संभाल ले। केवल उपलब्धता (availability) बनाए रखने के लिए कोई माइनॉरिटी पार्टीशन नए लीडर की घोषणा नहीं कर सकता।

सर्वसम्मति (consensus) सेमेंटिक्स वाले कोऑर्डिनेटर का चयन करना

लीडर रिकॉर्ड के लिए लीनियरिज़ेबल कम्पेयर-एंड-सेट (CAS), लीज़ और वॉच सेमेंटिक्स की आवश्यकता होती है, जैसे कि etcd। केवल Redis TTL या लोकल क्लॉक यह साबित नहीं कर सकते कि कोई पुराना लीडर लिखने में असमर्थ है।

पुराने राइट्स (stale writes) को रोकना

लीज़ समाप्त होने के बाद, पुरानी प्रोसेस रिकवर होकर काम जारी रख सकती है। डाउनस्ट्रीम के प्रत्येक राइट में एक मोनोटोनिकली बढ़ता हुआ फ़ेंसिंग टोकन होना चाहिए, और स्प्लिट-ब्रेन क्षति को रोकने के लिए रिसोर्स को पुराने टोकन्स को अस्वीकार करना चाहिए।

पहले स्पष्ट करने योग्य प्रश्न

• क्या जॉब दो बार चल सकता है, या डाउनस्ट्रीम को सख्ती से केवल एक सीरियलाइज़्ड निष्पादन स्वीकार करना चाहिए?
• क्या इलेक्शन ग्लोबल है, प्रति टेनेंट है, प्रति शार्ड है या प्रति जॉब है?
• कितना फ़ेलओवर समय और पॉज़ विंडो स्वीकार्य है?
• कोऑर्डिनेटर के कितने फ़ेलियर डोमेन और कौन सा कोरम/बैकअप उपलब्ध हैं?
• क्या डाउनस्ट्रीम रिसोर्सेज फ़ेंसिंग टोकन को वैलिडेट कर सकते हैं और इडेम्पोटेंटली (idempotently) रिकवर हो सकते हैं?
• क्या वॉच इवेंट्स, ऑडिट हिस्ट्री, अलर्ट्स और मैन्युअल ट्रांसफ़र आवश्यक हैं?

30-सेकंड का उत्तर

“मैं पहले इलेक्शन का दायरा और फ़ेलियर बजट परिभाषित करूँगा, फिर सर्वसम्मति-समर्थित, लीनियरिज़ेबल कोऑर्डिनेटर में एक लीज़्ड लीडर रिकॉर्ड स्टोर करूँगा। कैंडिडेट्स ट्रांज़ैक्शनल क्रिएट-या-कम्पेयर अपडेट के साथ प्रतिस्पर्धा करते हैं; विजेता को एक उच्च फ़ेंसिंग टर्म मिलता है और वह TTL के भीतर इसे रिन्यू करता है। रिन्यूअल विफल होने पर नया काम और राइट्स रुक जाते हैं। डाउनस्ट्रीम का प्रत्येक राइट टर्म को वैलिडेट करता है, इसलिए रिकवर हुआ पुराना लीडर राइट नहीं कर सकता। वॉच केवल एक नए CAS प्रयास को तेज़ करते हैं। मैं टर्म, रिन्यूअल लेटेंसी, फ़ेलओवर समय, फ़ेंसिंग रिजेक्ट्स, डुप्लिकेट्स और कोरम हेल्थ की निगरानी करूँगा।”

चरण-दर-चरण विस्तृत उत्तर

टर्म रिकॉर्ड को परिभाषित करें

election_name, leader_id, lease_id, term, कैंडिडेट मेटाडेटा और टाइमस्टैम्प स्टोर करें। टर्म या फ़ेंसिंग टोकन मोनोटोनिकली बढ़ना चाहिए और कोऑर्डिनेटर द्वारा एटॉमिक रूप से असाइन किया जाना चाहिए, न कि क्लाइंट क्लॉक से जनरेट किया जाना चाहिए।

कोऑर्डिनेटर और राइट की स्थिति चुनें

एक कैंडिडेट एक एफ़ेमरल (ephemeral) लीज़-समर्थित रिकॉर्ड बनाता है; एक लीनियरिज़ेबल ट्रांज़ैक्शन केवल तभी राइट कर सकता है जब की (key) अनुपस्थित हो। यदि कोई लीडर मौजूद है, तो कैंडिडेट्स की (key) को वॉच करते हैं और पुनः प्रयास करते हैं। etcd इलेक्शन API प्रतिभागियों को एक समय में केवल एक सफल लीडर के साथ एक इलेक्शन नाम पर प्रतिस्पर्धा करने की अनुमति देता है।

रिन्यू करना और सुरक्षित रूप से विफल (fail closed) होना

लीडर एक स्वतंत्र कीपअलाइव (keepalive) लूप के माध्यम से रिन्यू करता है। रिन्यूअल टाइमआउट, कनेक्शन टूटना, प्रोसेस पॉज़ होना या लोकल-क्लॉक की विसंगति इसे suspect में ले जाती है, जहाँ यह नया काम और डाउनस्ट्रीम राइट्स स्वीकार करना बंद कर देता है। कोऑर्डिनेटर से डिस्कनेक्ट होने पर इसे विश्वास के साथ काम जारी नहीं रखना चाहिए।

फ़ेलओवर को संभालना

कोई कैंडिडेट अपने लोकल TTL से यह तय नहीं कर सकता कि पुराना लीडर समाप्त (dead) हो चुका है। उसे कोऑर्डिनेटर द्वारा पुष्टि की गई लीज़ समाप्ति या डिलीशन को देखना चाहिए, और फिर CAS के साथ प्रतिस्पर्धा करनी चाहिए। फ़ेलओवर समय TTL, डिटेक्शन और शेड्यूलिंग देरी का योग होता है, इसलिए जिटर (jitter) मार्जिन के साथ एक सीमा निर्धारित करें।

फ़ेंसिंग टोकन जोड़ना

नया लीडर एक उच्च टर्म प्राप्त करता है और इसे डेटाबेस अपडेट, मैसेज या बाहरी API रिक्वेस्ट्स के साथ जोड़ता है। एक रिसोर्स उच्चतम स्वीकृत टोकन को स्टोर करता है और निचले टोकन को अस्वीकार कर देता है। यह खतरनाक राइट्स को रोकता है, भले ही कोई पुरानी प्रोसेस रुकी न हो।

पार्टीशन और स्प्लिट ब्रेन को संभालना

माइनॉरिटी पार्टीशन नए टर्म जारी नहीं कर सकता। कोऑर्डिनेटर कोरम तक पहुँचने में असमर्थ कैंडिडेट को रुक जाना चाहिए या केवल रीड-ओनली रहना चाहिए। पुनः कनेक्ट होने के बाद, पुराने लीडर को कैश्ड स्थिति पर भरोसा करने के बजाय वर्तमान टर्म को फिर से पढ़ना चाहिए और दोबारा प्रतिस्पर्धा करनी चाहिए।

स्यूडोकोड

~~~text campaign(): lease = coordinator.grant(ttl) result = coordinator.txn(key absent -> put(candidate, lease, next_term)) if result.succeeded: token = result.term keepalive(lease) runwithfencing(token) else: watch(key)

onkeepalivefailureorexpiry: stopnewwork() stopdownstreamwrites() ~~~

जटिलता, रिकवरी और ऑब्ज़र्वेबिलिटी

प्रत्येक इलेक्शन और रिन्यूअल में कोऑर्डिनेटर राउंड ट्रिप्स शामिल होते हैं; अधिक कैंडिडेट्स वॉच और रिट्राइ का भार बढ़ाते हैं, इसलिए जिटर के साथ एक्सपोनेंशियल बैकऑफ़ का उपयोग करें। टर्म ट्रांज़िशन को रीकंस्ट्रक्ट करने के लिए वर्तमान लीडर, टर्म, रिन्यूअल RTT, लीज़ समाप्ति, इलेक्शन अवधि, फ़ेंसिंग रिजेक्ट्स, डुप्लिकेट जॉब्स और कोरम हेल्थ को रिकॉर्ड करें।

मॉडल उत्तर

“मैं लीनियरिज़ेबल ट्रांज़ैक्शन्स वाले सर्वसम्मति-समर्थित कोऑर्डिनेटर में एक लीज़्ड लीडर रिकॉर्ड स्टोर करूँगा। कैंडिडेट्स केवल अनुपस्थित होने पर रिकॉर्ड बनाकर प्रतिस्पर्धा करते हैं; विजेता को मोनोटोनिकली बढ़ता हुआ टर्म मिलता है और वह इसे TTL के भीतर रिन्यू करता है। यदि रिन्यूअल विफल हो जाता है, तो यह तुरंत नए जॉब्स और डाउनस्ट्रीम राइट्स को रोक देता है। प्रत्येक डेटाबेस राइट, मैसेज या बाहरी कॉल में फ़ेंसिंग टोकन होता है, और रिसोर्स अपने उच्चतम स्वीकृत मान से कम टोकन को अस्वीकार कर देता है, ताकि पॉज़ या पार्टीशन में फंसा पुराना लीडर लिखना जारी न रख सके। कोई माइनॉरिटी नया टर्म जारी नहीं कर सकती, जबकि वॉच केवल इलेक्शन में लगने वाले समय को कम करता है। मैं एक मैन्युअल किल स्विच के साथ रिन्यूअल RTT, टर्म्स, फ़ेलओवर अवधि, फ़ेंसिंग रिजेक्ट्स, डुप्लिकेट जॉब्स और कोरम की निगरानी करूँगा।”

सामान्य गलतियाँ

केवल Redis TTL का उपयोग करना

लीज़ की समाप्ति और क्लाइंट द्वारा समाप्ति का अवलोकन एक समान नहीं हैं। नेटवर्क देरी और पॉज़ दो क्लाइंट्स को यह विश्वास दिला सकते हैं कि वे काम कर सकते हैं। लीनियरिज़ेबल कोऑर्डिनेशन के साथ डाउनस्ट्रीम फ़ेंसिंग का उपयोग करें।

लीज़ को राइट प्रोटेक्शन मानना

लीज़ विफलता का पता लगाने में मदद करती है लेकिन पुरानी प्रोसेस को तुरंत नहीं रोक सकती। टोकन वैलिडेशन के बिना, पुराना लीडर नए लीडर के परिणाम को ओवरराइट कर सकता है।

लोकल समय से टर्म्स जनरेट करना

क्लॉक्स ड्रिफ़्ट हो सकती हैं, जंप कर सकती हैं या पॉज़ हो सकती हैं। कोऑर्डिनेटर को टर्म्स को एटॉमिक रूप से आवंटित और स्टोर करना चाहिए।

पार्टीशन के दौरान जबरन टेकओवर करना

माइनॉरिटी पुराने लीडर की स्थिति की पुष्टि नहीं कर सकती। जबरन टेकओवर करने से स्प्लिट-ब्रेन की स्थिति पैदा होती है; एक सुरक्षित डिज़ाइन थोड़े समय के लिए उपलब्धता के नुकसान को स्वीकार करता है।

वॉच इवेंट्स को सुरक्षा तय करने देना

वॉच में देरी हो सकती है, वे खो सकते हैं या पुनः कनेक्ट हो सकते हैं। उन्हें री-रीड और CAS को ट्रिगर करना चाहिए, न कि लीनियरिज़ेबल रीड्स और राइट्स की जगह लेनी चाहिए।

जॉब इडेम्पोटेन्सी को छोड़ देना

सही इलेक्शन क्रैश या मैसेज के पुनः वितरण के बाद डुप्लिकेट्स को नहीं रोकता है। जॉब्स को इडेम्पोटेन्सी कीज़, प्रोग्रेस रिकॉर्ड्स या पुनः निष्पादित किए जा सकने वाले ट्रांज़ैक्शन्स की आवश्यकता होती है।

फॉलो-अप प्रश्न और उत्तर

लीडर इलेक्शन एक डिस्ट्रीब्यूटेड लॉक से किस प्रकार भिन्न है?

एक लॉक क्रिटिकल सेक्शन की सुरक्षा करता है; इलेक्शन टर्म्स, रिन्यूअल, वॉचेस, फ़ेंसिंग और फ़ेलओवर के साथ एक दीर्घकालिक कोऑर्डिनेटर भूमिका बनाए रखता है। वे एक कोऑर्डिनेटर साझा कर सकते हैं, लेकिन उनका सेफ़्टी सरफेस अधिक व्यापक होता है।

आपको TTL कैसे चुनना चाहिए?

सामान्य रिन्यूअल RTT, GC या शेड्यूलर पॉज़, नेटवर्क जिटर और फ़ेलओवर SLO को कवर करें। एक छोटा TTL अस्थिरता (churn) पैदा करता है; एक लंबा TTL टेकओवर में देरी करता है। फ़ॉल्ट इंजेक्शन के साथ कैलिब्रेट करें।

रिसोर्स द्वारा फ़ेंसिंग टोकन की जाँच क्यों की जानी चाहिए?

कोऑर्डिनेटर प्रत्येक पुरानी प्रोसेस को तुरंत नहीं रोक सकता। रिसोर्स-साइड रिजेक्शन खतरनाक राइट्स को रोकता है, जबकि वह प्रोसेस अभी भी जीवित होती है।

क्या होता है जब कोई etcd क्लस्टर कोरम खो देता है?

यह नया टर्म या लीज़ स्थिति कमिट नहीं कर सकता; वर्तमान लीडर को रिन्यू न कर पाने के बाद राइट्स रोकने होंगे। कोरम लौटने के बाद कैंडिडेट्स फिर से प्रतिस्पर्धा करते हैं।

आप लंबे लीडर पॉज़ को कैसे संभालते हैं?

पॉज़ के दौरान रिन्यूअल विफल हो जाता है और एक नया कैंडिडेट कार्यभार संभाल सकता है। जब पुरानी प्रोसेस फिर से शुरू होती है, तो उसका पुराना टोकन अस्वीकार कर दिया जाता है और उसे फिर से इलेक्शन में शामिल होना पड़ता है।

आप स्प्लिट-ब्रेन का परीक्षण कैसे करते हैं?

प्रोसेस पॉज़, पार्टीशन्स, क्लॉक जंप्स और कोऑर्डिनेटर विफलताओं को इंजेक्ट करें। सत्यापित करें कि राइट्स के लिए प्रति टर्म केवल एक टोकन स्वीकार किया जाता है, और फ़ेलओवर अवधि तथा रिजेक्शन रिकॉर्ड्स का निरीक्षण करें।