प्रॉम्प्ट और संदर्भ
यह प्रश्न बैकएंड APIs, ऑब्जेक्ट स्टोरेज और कन्करेंसी कंट्रोल का परीक्षण करता है। AWS कंडीशनल रिक्वेस्ट्स PutObject, CompleteMultipartUpload, और CopyObject में पूर्व-शर्तें (preconditions) जोड़ते हैं: निर्माण के लिए आवश्यक हो सकता है कि कोई की (key) मौजूद न हो, जबकि अपडेट के लिए आवश्यक हो सकता है कि ETag अपरिवर्तित रहे। मुख्य मुद्दा यह है कि स्टोरेज से राइट ऑपरेशन के साथ ही इस जांच का मूल्यांकन कराया जाए, न कि क्लाइंट्स को एक रेसी HEAD के बाद PUT करने दिया जाए।
इंटरव्यूअर क्या टेस्ट कर रहा है
एक मजबूत उत्तर निर्माण को अपडेट से अलग करता है, वर्तमान etag-value के साथ If-None-Match: * या If-Match चुनता है, और विफल शर्त को पुनः प्रयास या मर्ज व्यवहार से मैप करता है। यह मल्टीपार्ट पूर्णता, कमजोर ETags, अनिश्चित नेटवर्क परिणामों और ऑडिट सिग्नल्स को भी कवर करता है। केवल "एक लॉक जोड़ें" कहना कई प्रक्रियाओं या विफलता रिकवरी की व्याख्या नहीं करता है।
पहले पूछे जाने वाले स्पष्टीकरण प्रश्न
राइट सेमेंटिक्स (Write semantics)
क्या यह एक राइट-वन्स इम्यूटेबल ऑब्जेक्ट है, या पढ़े गए संस्करण पर आधारित कोई अपडेट है? पहला अस्तित्व की पूर्व-शर्त का उपयोग करता है; दूसरे को संस्करण ETag की आवश्यकता होती है।
कॉन्फ्लिक्ट पॉलिसी (Conflict policy)
क्या किसी कॉन्फ्लिक्ट पर 412 वापस आना चाहिए ताकि क्लाइंट फिर से पढ़े और मर्ज करे, या प्रयास को छोड़ दिया जाना चाहिए? एक मैनिफ़ेस्ट या रजिस्ट्री को आमतौर पर चुपचाप ओवरराइट नहीं किया जाना चाहिए।
अपलोड पाथ (Upload path)
क्या छोटे ऑब्जेक्ट PutObject का उपयोग करेंगे और बड़े ऑब्जेक्ट मल्टीपार्ट का? अंतिम पूर्णता अनुरोध पर शर्त लगाएं और रुकावट, पुनः प्रयास और क्लीनअप व्यवहार को परिभाषित करें।
30-सेकंड का उत्तर ढांचा
"मैं पहले यह निर्धारित करता हूँ कि यह निर्माण है या वर्जन्ड अपडेट। निर्माण If-None-Match: * का उपयोग करता है, जिससे S3 स्वचालित रूप से किसी मौजूदा की को अस्वीकार कर देता है। एक अपडेट वर्तमान ETag को पढ़ता है और If-Match भेजता है; यदि ETag बदल गया है, तो S3 412 लौटाता है और क्लाइंट फिर से पढ़ता है या मर्ज करता है। मल्टीपार्ट अपलोड CompleteMultipartUpload पर शर्त लागू करते हैं। टाइमआउट विफलता का प्रमाण नहीं है, इसलिए मैं पुनः प्रयास करने से पहले ऑब्जेक्ट को क्वेरी करता हूँ या आइडम्पोटेंसी रिकॉर्ड का उपयोग करता हूँ, और 412s, अनाथ (orphaned) पार्ट्स और पुनः प्रयास गणनाओं की निगरानी करता हूँ।"
चरण-दर-चरण विस्तृत उत्तर
चरण 1: चेक-देन-एक्ट को हटाएं
HEAD के बाद PUT रेस करता है: दो क्लाइंट अनुपस्थिति देख सकते हैं और फिर लिख सकते हैं। पूर्व-शर्त को राइट रिक्वेस्ट में रखें ताकि स्टोरेज सेवा वर्तमान ऑब्जेक्ट स्थिति के विरुद्ध इसका मूल्यांकन करे।
चरण 2: शर्त चुनें
एक इम्यूटेबल निर्माण के लिए If-None-Match: * का उपयोग करें; यह केवल तभी सफल होता है जब कोई वर्तमान प्रतिनिधित्व मौजूद न हो। मौजूदा ऑब्जेक्ट के लिए मजबूत If-Match का उपयोग करें, जो केवल तभी लिखने की अनुमति देता है जब ETag पढ़े गए संस्करण के बराबर हो। बेमेल होने पर 412 लौटता है और नई सामग्री सुरक्षित रहती है।
चरण 3: कॉन्फ्लिक्ट प्रोटोकॉल को परिभाषित करें
412 पर आंख मूंदकर पुनः प्रयास न करें। वर्तमान ऑब्जेक्ट का GET करें और निर्धारित करें कि क्या क्लाइंट परिवर्तन मर्ज हो सकता है; अन्यथा एक कॉन्फ्लिक्ट रिकॉर्ड या एक नई की बनाएं। बैकऑफ और पुनः प्रयास सीमा जोड़ें ताकि कोई हॉट की पुनः प्रयास का तूफान (retry storm) न पैदा करे।
चरण 4: मल्टीपार्ट और कॉपी को कवर करें
पार्ट्स अपलोड होने के दौरान कोई अन्य क्लाइंट वही की बना सकता है, इसलिए अंतिम CompleteMultipartUpload को भी शर्त की आवश्यकता होती है। कॉपी या रिप्लेस वर्कफ़्लो में ETag शर्त होनी चाहिए, जबकि लाइफसाइकिल नियम छोड़े गए मल्टीपार्ट अपलोड को साफ़ करते हैं।
चरण 5: टाइमआउट संभालें और निरीक्षण करें
एक टाइमआउट यह नहीं बताता कि राइट कमिट हुआ या नहीं। पुनः प्रयास करने से पहले ऑब्जेक्ट और ETag को क्वेरी करें, और निर्माण के इरादे के लिए एक क्लाइंट कमांड ID रिकॉर्ड करें। यह सत्यापित करने के लिए कि कॉन्फ्लिक्ट्स ओवरराइट होने के बजाय अस्वीकार किए जा रहे हैं, 412 दर, सफल पुनः प्रयास दर, अनाथ पार्ट्स और संस्करण ड्रिफ्ट की निगरानी करें।
उच्च गुणवत्ता वाला नमूना उत्तर
मैं इम्यूटेबल डेटा फ़ाइलों को अपडेट करने योग्य रजिस्ट्री से अलग रखूंगा। डेटा-फ़ाइल निर्माण If-None-Match: * का उपयोग करता है, इसलिए केवल एक ही सेम-की राइटर सफल होता है। रजिस्ट्री को ETag के साथ पढ़ा जाता है और If-Match के साथ अपडेट किया जाता है; 412 किसी अन्य संस्करण को ओवरराइट करने के बजाय फिर से पढ़ने और मर्ज करने को ट्रिगर करता है। एक बड़ा अपलोड CompleteMultipartUpload पर शर्त लागू करता है, और एक क्लीनअप जॉब विफल अपलोड को पुनः प्राप्त करता है। नेटवर्क टाइमआउट के बाद, मैं पुनः प्रयास करने से पहले ऑब्जेक्ट और ETag को क्वेरी करता हूँ। S3 एटॉमिक कॉन्फ्लिक्ट चेक प्रदान करता है; क्लाइंट मर्ज पॉलिसी और आइडम्पोटेंसी रिकॉर्ड का मालिक होता है। मैं इसे 412, पुनः प्रयास और अनाथ-पार्ट मेट्रिक्स के साथ मान्य करूंगा।
सामान्य गलतियाँ
- गलती: अनुपस्थिति की जांच के लिए HEAD, फिर PUT। → यह क्यों विफल होता है: दो क्लाइंट एक साथ जांच पास कर सकते हैं। → सुधार: PUT पर
If-None-Match: *का उपयोग करें। - गलती: अपडेट के लिए
If-None-Matchका उपयोग करना। → यह क्यों विफल होता है: इसका अर्थ है "मौजूद नहीं होना चाहिए", न कि "मेरे द्वारा पढ़े गए संस्करण के बराबर होना चाहिए।" → सुधार: एक मजबूत ETag पढ़ें औरIf-Matchका उपयोग करें। - गलती: 412 के बाद मूल अनुरोध को बिना शर्त पुनः प्रयास करना। → यह क्यों विफल होता है: यह बार-बार ओवरराइट कर सकता है या पुनः प्रयास का तूफान ला सकता है। → सुधार: सीमित बैकऑफ के साथ फिर से पढ़ें, मर्ज करें या छोड़ दें।
- गलती: केवल पहले मल्टीपार्ट अनुरोध पर शर्त लागू करना। → यह क्यों विफल होता है: पूरा होने से पहले ऑब्जेक्ट की स्थिति बदल सकती है। → सुधार: इसे
CompleteMultipartUploadपर फिर से लागू करें।
फॉलो-अप और प्रतिक्रियाएं
फॉलो-अप 1: क्या ETag को कंटेंट हैश माना जा सकता है?
सार्वभौमिक रूप से नहीं। आवश्यकता एक संस्करण सत्यापनकर्ता (version validator) की है; मल्टीपार्ट और एन्क्रिप्शन परिदृश्य ETag सेमेंटिक्स को बदल सकते हैं, इसलिए उस ऑपरेशन के लिए सेवा-दस्तावेज़ित चेकसम या सत्यापनकर्ता का उपयोग करें।
फॉलो-अप 2: 412 और 409 में क्या अंतर है?
API अनुबंध का पालन करें: 412 का अर्थ है कि एक अनुरोध पूर्व-शर्त विफल रही और आमतौर पर क्लाइंट को फिर से पढ़ने के लिए कहती है; कोई अन्य कॉन्फ्लिक्ट स्थिति संसाधन या ऑपरेशन स्थिति का वर्णन कर सकती है। केवल संख्या से अर्थ का अनुमान न लगाएं।
फॉलो-अप 3: क्या होगा यदि क्लाइंट मर्ज नहीं कर सकता?
वर्तमान संस्करण को सुरक्षित रखें और डोमेन ओनर द्वारा हल करने के लिए एक कॉन्फ्लिक्ट रिकॉर्ड या नई की बनाएं। साइलेंट ओवरराइट सफलता का मानदंड नहीं है।
फॉलो-अप 4: आप कन्करेंसी की शुद्धता का परीक्षण कैसे करते हैं?
एक ही की पर समवर्ती निर्माण और अपडेट चलाएं, टाइमआउट, डुप्लिकेट मल्टीपार्ट पूर्णता, और क्लीनअप विफलताओं को इंजेक्ट करें, फिर सत्यापित करें कि अधिकतम एक निर्माण सफल होता है, पुरानी सामग्री कभी भी नई सामग्री को ओवरराइट नहीं करती है, और ऑडिट रिकॉर्ड परिणामों से मेल खाते हैं।