प्रॉम्प्ट और संदर्भ
एक सिस्टम में कई नोड्स हैं जो समान व्यावसायिक डेटा संग्रहीत करते हैं, और वे नोड्स विभाजित (partitioned) हो सकते हैं। कंसिस्टेंसी (Consistency), उपलब्धता (Availability), और पार्टीशन टॉलरेंस (Partition tolerance) को समझाएं, फिर उन्हें ऑर्डर, इन्वेंट्री या सोशल फीड पर लागू करें। केवल "दो चुनें" तक ही सीमित न रहें; बताएं कि उपयोगकर्ता क्या देखते हैं, कौन से राइट्स (writes) स्वीकार किए जाते हैं, और रिकवरी के बाद सिस्टम कैसे कन्वर्ज होता है।
इंटरव्यूअर क्या जांचता है
इंटरव्यूअर यह देखना चाहता है कि आप पार्टीशन के दौरान ट्रेड-ऑफ को कैसे रखते हैं, कंसिस्टेंसी को रीड गारंटी के रूप में और उपलब्धता को समय पर रिस्पॉन्स गारंटी के रूप में परिभाषित करते हैं, और पार्टीशन टॉलरेंस को एक वास्तविक वितरित-नेटवर्क बाधा मानते हैं। मजबूत उत्तर केवल डेटाबेस लेबल का उपयोग करने के बजाय व्यावसायिक जोखिम, डिग्रेडेशन, कन्फ्लिक्ट हैंडलिंग, ऑब्जर्वेबिलिटी और रिकवरी को जोड़ते हैं।
स्पष्ट करने योग्य प्रश्न
- क्या कंसिस्टेंसी लिनियराइजेबल है, सेशन-लेवल है, या थोड़े समय के लिए स्टेल (stale) है?
- क्या उपलब्धता एक स्पष्ट पुनः प्रयास करने योग्य (retryable) त्रुटि की अनुमति देती है?
- पार्टीशन के दौरान किन ऑपरेशन्स को रुकना चाहिए, जैसे कि भुगतान, इन्वेंट्री, या रद्दीकरण?
- क्या लोकल क्यू, आइडम्पोटेंट पुनः प्रयास, कन्फ्लिक्ट मर्ज, या मानवीय समीक्षा की अनुमति है?
- क्या रिकवरी का लक्ष्य शून्य नुकसान, मोनोटोनिक कन्वर्जेंस, या एक सीमित कंपन्सेशन विंडो है?
30-सेकंड का उत्तर
CAP कहता है कि नेटवर्क पार्टीशन के दौरान एक सिस्टम हर अनुरोध के लिए मजबूत कंसिस्टेंसी और एक उपलब्ध रिस्पॉन्स दोनों की गारंटी नहीं दे सकता है; P पार्टीशन के बावजूद जारी रहने की बाधा है। मैं सबसे पहले अस्वीकार्य व्यावसायिक त्रुटियों को वर्गीकृत करूँगा: भुगतान और इन्वेंट्री एक पुनः प्रयास करने योग्य त्रुटि लौटा सकते हैं, जबकि एक सोशल फीड पुराना डेटा दिखा सकता है। फिर मैं डेटाबेस को स्थायी रूप से "CP और AP दोनों" का दावा करने के बजाय आइडम्पोटेंसी, कन्फ्लिक्ट लॉग, रीप्ले, रिकवरी और मैट्रिक्स की व्याख्या करूँगा।
चरण-दर-चरण विस्तृत उत्तर
चरण 1: तीनों शब्दों को परिभाषित करें
कंसिस्टेंसी एक रीड गारंटी है; मजबूत कंसिस्टेंसी को आमतौर पर नवीनतम पूर्ण किए गए राइट को पढ़ने के रूप में वर्णित किया जाता है। उपलब्धता का अर्थ है कि प्रत्येक अनुरोध को सिस्टम के अनुबंध के भीतर एक रिस्पॉन्स प्राप्त होता है। पार्टीशन टॉलरेंस का अर्थ है कि सिस्टम खोए हुए या असीमित रूप से विलंबित नोड संचार को संभाल सकता है। CAP का निर्णायक मामला यह है कि P घटित हो चुका है।
चरण 2: एक पार्टीशन टाइमलाइन बनाएं
मान लें कि टोक्यो और सिंगापुर संचार नहीं कर सकते हैं। यदि दोनों एक ही खाते के लिए विपरीत राइट्स स्वीकार करते हैं और तुरंत प्रतिक्रिया देते हैं, तो एक कन्फ्लिक्ट उत्पन्न हो सकता है और मजबूत कंसिस्टेंसी खो जाती है। यदि केवल एक पक्ष लिखता है या दोनों अनिश्चित ऑपरेशन्स को अस्वीकार करते हैं, तो कुछ उपलब्धता का त्याग किया जाता है। डेटास्टोर का नाम देने से पहले टाइमलाइन बनाएं।
चरण 3: व्यावसायिक जोखिम के आधार पर व्यवहार चुनें
इन्वेंट्री, भुगतान प्राधिकरण और अद्वितीय नामों को दोहरे राइट्स से बचना चाहिए; पार्टीशन के दौरान वे पुनः प्रयास करने योग्य स्थिति लौटा सकते हैं या कार्य को कतारबद्ध (queue) कर सकते हैं। लाइक्स, व्यू काउंट और सिफारिशें अक्सर स्टेल रीड्स और एसिंक्रोनस मर्ज को सहन कर सकती हैं। यह विकल्प किसी AP/CP नारे के अनुसार नहीं, बल्कि किसी त्रुटि की लागत के अनुसार चुना जाता है।
partitioned:
if operation == payment_or_inventory:
reject_or_queue_with_idempotency_key()
else:
serve_stale_read_and_record_reconciliation()चरण 4: राइट्स और कन्फ्लिक्ट्स को परिभाषित करें
पुनः प्रयास करने योग्य राइट्स में एक आइडम्पोटेंसी कुंजी और संस्करण होता है। मल्टी-रीजन राइट्स मूल, लॉजिकल समय और साक्ष्य रिकॉर्ड करते हैं; रिकवरी व्यावसायिक नियमों के अनुसार कन्फ्लिक्ट्स को मर्ज करती है, क्षतिपूर्ति (compensate) करती है, या समीक्षा के लिए भेजती है। लास्ट-राइट-विन्स (Last-write-wins) को अपरिवर्तनीय भुगतान या इन्वेंट्री कन्फ्लिक्ट्स को नहीं छिपाना चाहिए।
चरण 5: रिकवरी की व्याख्या करें
संचार वापस आने के बाद, लॉग और संस्करणों का आदान-प्रदान करें, अंतराल और डुप्लिकेट का पता लगाएं, और पुनः प्रयास करने योग्य घटनाओं को क्रम से रीप्ले करें। अनसुलझे ऑर्डर को एक स्पष्ट स्थिति दें ताकि उपयोगकर्ता दो बार भुगतान न करें। रिकवरी को रेट-लिमिट करें और असाधारण रिकॉर्ड के लिए डेड-लेटर और मैनुअल क्यू का उपयोग करें।
चरण 6: वैलिडेशन से जोड़ें
पार्टीशन अवधि, अस्वीकृति दर, स्टेल-रीड आयु, कन्फ्लिक्ट गणना, कंपन्सेशन सफलता और डुप्लिकेट अनुरोधों को ट्रैक करें। रीड्स, राइट्स, पुनः प्रयासों, रिकवरी और क्रॉस-रीजन लेटेंसी में विफलताएं इंजेक्ट करें, फिर सत्यापित करें कि उपयोगकर्ता संदेश वास्तविक स्थिति से मेल खाते हैं।
ट्रेड-ऑफ और सीमाएं
CAP कोई स्थायी दो-अक्षर वाला डेटाबेस लेबल नहीं है
यह विकल्प पार्टीशन के दौरान का व्यवहार है; इसके बाहर, लेटेंसी, लागत, ड्यूरेबिलिटी और ऑपरेशन्स अभी भी मायने रखते हैं। अनुरोध-स्तरीय गारंटी के बिना किसी सिस्टम को "AP" या "CP" कहना डिज़ाइन को छुपाता है।
कंसिस्टेंसी की मजबूती बताएं
"कंसिस्टेंट" का अर्थ लिनियराइजेबल, कॉज़ल, सेशन, या इवेंचुअल कन्वर्जेंस हो सकता है। नोड्स और प्रोटोकॉल पर चर्चा करने से पहले रीड और राइट अनुबंध को परिभाषित करें।
रोलआउट योजना और साक्ष्य
आवश्यकताओं को नीति से मैप करें
भुगतान, इन्वेंट्री, ऑर्डर स्थिति, खोज और सोशल काउंटर्स के लिए, पार्टीशन व्यवहार, उपयोगकर्ता टेक्स्ट, पुनः प्रयास सीमा और रिकवरी कार्रवाई लिखें। प्रत्येक वादे को एक API और डेटा मॉडल से मैप करें।
विफलता अभ्यास (failure drills) चलाएं
एकतरफा नुकसान, विलंब, डुप्लिकेट संदेशों और आंशिक रिकवरी का अभ्यास करें। अंतिम रिस्पॉन्स, आइडम्पोटेंसी रिकॉर्ड, कन्फ्लिक्ट क्यू, कंपन्सेशन अकाउंटिंग और अलर्ट की जांच करें; बाद में परीक्षण डेटा को साफ़ करें और ऑडिट लॉग की समीक्षा करें।
सामान्य गलतियाँ और फॉलो-अप
गलती: दावा करना कि CA पार्टीशन में भी बना रहता है
CA कंसिस्टेंसी और उपलब्धता का वर्णन तब करता है जब पार्टीशन को बाहर रखा गया हो; वास्तविक क्रॉस-नोड सिस्टम को संचार विफलता को संभालना ही होगा।
गलती: उपलब्धता को हमेशा के लिए सफलता के बराबर मानना
उपलब्धता समय पर रिस्पॉन्स की गारंटी है। जब अनुबंध स्पष्ट हो, तो एक त्रुटि, कतार, या स्पष्ट पुनः प्रयास सही व्यावसायिक व्यवहार हो सकता है।
गलती: हर कन्फ्लिक्ट को लास्ट-राइट-विन्स से अधिलेखित (overwrite) करना
भुगतान और इन्वेंट्री कन्फ्लिक्ट्स के लिए आइडम्पोटेंसी, संस्करण, कंपन्सेशन या समीक्षा की आवश्यकता होती है; अंधाधुंध अधिलेखन व्यावसायिक तथ्यों को नष्ट कर देता है।
फॉलो-अप: P आमतौर पर अपरिहार्य क्यों है?
क्रॉस-रीजन नेटवर्क विभाजित हो सकते हैं या अस्वीकार्य रूप से विलंबित हो सकते हैं; P को छोड़ने का अर्थ संचार विफल होने पर वितरित सेवा को रोकना है।
फॉलो-अप: आप इस चयन को कैसे साबित करते हैं?
पार्टीशन अभ्यास, उपयोगकर्ता-दृश्यमान स्थितियां, कन्फ्लिक्ट और कंपन्सेशन मैट्रिक्स, और नीति के लिए एक रोलबैक शर्त दिखाएं।