प्रॉम्प्ट और यह प्रश्न कब लागू होता है
एक चेकआउट API सिंक्रोनस रूप से एक थर्ड-पार्टी टैक्स सर्विस को कॉल करता है। डिपेंडेंसी का सामान्य रूप से p50 80 ms और p99 180 ms होता है, लेकिन कभी-कभी इसमें कनेक्शन फेलियर्स, धीमी प्रतिक्रियाएं, HTTP 429s, 503s और ऐसे मामले आते हैं जहाँ अनुरोध सर्वर तक पहुँच गया हो सकता है लेकिन प्रतिक्रिया खो गई थी। चेकआउट API का एंड-टू-एंड टारगेट 800 ms है। सर्विस कॉल चेन पाँच लेयर्स गहरी हो सकती है, और कई SDKs डिफ़ॉल्ट रूप से पहले से ही रीट्राई कर सकते हैं।
कॉलिंग पॉलिसी डिज़ाइन करें। बताएं कि डेडलाइन को प्रति-प्रयास टाइमआउट में कैसे विभाजित किया जाए, कौन से फेलियर्स रीट्राई करने योग्य हैं, अधिकतम प्रयास, एक्सपोनेंशियल बैकऑफ और जिटर कैसे सेट करें, सर्किट ब्रेकर कैसे खुलता है और रिकवर होता है, और आइसोलेशन, डिग्रेडेशन, मेट्रिक्स और फॉल्ट इंजेक्शन यह कैसे साबित करते हैं कि एक स्थानीय विफलता कैस्केडिंग विफलता नहीं बनेगी।
लेटेंसी और गहराई इंटरव्यू के अनुमान हैं। मुख्य कौशल सिंक्रोनस सर्विस-टू-सर्विस कॉल्स के लिए फेलियर सिमेंटिक्स, रिसोर्स प्रोटेक्शन और रिकवरी कंट्रोल है, इसलिए श्रेणी बैकएंड है। मौजूदा idempotent-order प्रश्न एक राइट ऑपरेशन के लिए डेटाबेस कॉन्ट्रैक्ट पर केंद्रित है। यह प्रश्न केवल यह तय करने के लिए आइडेम्पोटेंसी का उपयोग करता है कि टाइमआउट के बाद रीट्राई करना सुरक्षित है या नहीं; इसका केंद्र कॉल चेन में समय और लोड बजट है।
इंटरव्यूअर क्या मूल्यांकन कर रहा है
पहला संकेत यह है कि क्या उम्मीदवार एक टाइम लेज़र बनाता है। 800 ms की एंड-टू-एंड डेडलाइन का मतलब 800 ms का डिपेंडेंसी टाइमआउट नहीं है। स्थानीय वैलिडेशन, क्यूइंग, सीरियलाइज़ेशन और रिस्पॉन्स से जुड़े काम सभी के लिए बजट की आवश्यकता होती है। प्रत्येक प्रयास में कनेक्शन, TLS और रिस्पॉन्स चरणों का भी हिसाब होना चाहिए, और दूसरा रीट्राई तभी शुरू होना चाहिए जब पर्याप्त समय बचा हो।
दूसरा संकेत फेलियर सिमेंटिक्स द्वारा रीट्राई करना है। कनेक्शन स्थापित होने से पहले की विफलता, एक अस्थायी 503, या रीट्राई मार्गदर्शन वाला 429 रीट्राई करने योग्य हो सकता है। गलत पैरामीटर, प्रमाणीकरण (authentication), और प्राधिकरण (authorization) समय के साथ ठीक नहीं होते हैं। जब कोई राइट भेजे जाने के बाद टाइमआउट हो जाता है, तो परिणाम "कमिटेड लेकिन प्रतिक्रिया अज्ञात" हो सकता है। रीट्राई सुरक्षित होने से पहले एक स्थिर idempotency key, स्टेटस लुकअप, या समाधान (reconciliation) प्रक्रिया की आवश्यकता होती है।
तीसरा संकेत रीट्राई प्रवर्धन (retry amplification) है। यदि पाँच-गहरी चेन में प्रत्येक सर्विस तीन प्रयासों तक करती है, तो सबसे निचली डिपेंडेंसी 3^5 = 243 कॉल्स प्राप्त कर सकती है। रीट्राई एक ऐसी लेयर पर होने चाहिए जो बिज़नेस डेडलाइन को समझती हो, जिसमें प्रयासों, कुल बीते समय और टोकन-आधारित रीट्राई बजट पर सीमाएं हों।
अंत में, इंटरव्यूअर एक रिकवरी लूप चाहता है। एक टाइमआउट एक प्रतीक्षा को सीमित करता है, एक रीट्राई एक संक्षिप्त विफलता को संभालता है, एक सर्किट ब्रेकर निरंतर विफलता के दौरान कॉल्स को अस्वीकार करता है, और एक बल्कहेड समवर्तीता (concurrency) और कतार अधिभोग (queue occupancy) को सीमित करता है। एक मजबूत उत्तर हाफ-ओपन प्रोब्स को भी सीमित करता है, बेईमान फ़ॉलबैक से इनकार करता है, और लॉजिकल कॉल्स को भौतिक प्रयासों से अलग देखता है।
उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न
- क्या डिपेंडेंसी कॉल एक रीड है या साइड इफेक्ट्स वाला राइट? रीड्स आमतौर पर दोहराए जाने योग्य होते हैं। टाइम-आउट राइट का परिणाम अज्ञात हो सकता है और इसके लिए एक idempotency key, स्टेटस लुकअप, या समाधान की आवश्यकता होती है।
- क्या 800 ms एक हार्ड डेडलाइन है या एक ऑब्जर्वेशनल टारगेट? यहाँ यह वह बिंदु है जिसके बाद कॉलर अब प्रतीक्षा नहीं करता है। रद्दीकरण (cancellation) को डाउनस्ट्रीम में प्रसारित किया जाना चाहिए ताकि अनुपस्थित कॉलर के लिए काम पूरा न हो।
- डिपेंडेंसी किन त्रुटियों को रीट्राई करने योग्य घोषित करती है? वर्गीकरण प्रोटोकॉल और वेंडर कॉन्ट्रैक्ट का पालन करना चाहिए, विशेष रूप से 429, 503, कनेक्शन विफलताओं और व्यावसायिक त्रुटियों पर
Retry-After। "200 के अलावा कुछ भी" कोई नीति नहीं है। - क्या SDK, प्रॉक्सी या सर्विस मेश पहले से ही रीट्राई करते हैं? प्रत्येक लेयर के डिफ़ॉल्ट और प्रयास सीमाओं की सूची बनाएं। एक दृश्यमान एप्लिकेशन रीट्राई अन्यथा रीट्राई स्टॉर्म में बदल सकता है।
- डिपेंडेंसी का लेटेंसी वितरण और क्षमता क्या है? पर्सेंटाइल, सहन किए गए गलत-टाइमआउट दर (false-timeout rate), और नेटवर्क भत्ते से टाइमआउट प्राप्त करें, फिर नए कनेक्शन, क्रॉस-रीजन ट्रैफ़िक और पीक लोड को सत्यापित करें।
- कौन सा डिग्रेडेशन स्वीकार्य है? यदि कर गणना में अनुपालन (compliance) आवश्यकताएं हैं, तो एक गढ़ा हुआ "सफल" डिफ़ॉल्ट कर असुरक्षित है। स्पष्ट विफलता, मैन्युअल समीक्षा, या आस्थगित (deferred) चेकआउट को एक व्यावसायिक अनुबंध का पालन करना चाहिए।
- सर्किट ब्रेकर की आइसोलेशन सीमा क्या है? एक स्वतंत्र वेंडर, क्षेत्र, एंडपॉइंट या ऑपरेशन का उपयोग करें। एक विफल शार्ड को स्वस्थ संसाधनों को डिस्कनेक्ट नहीं करना चाहिए।
30-सेकंड उत्तर रूपरेखा
"मैं 800 ms की एंड-टू-एंड डेडलाइन को एक टाइम बजट में विभाजित करूँगा और डाउनस्ट्रीम में एक पूर्ण डेडलाइन प्रसारित करूँगा। प्रत्येक कॉल में कनेक्शन और अनुरोध टाइमआउट होते हैं, और दूसरा प्रयास तभी शुरू होता है जब यह शेष बजट में फिट बैठता है। मैं विफलताओं को पुनर्प्राप्ति योग्यता (recoverability) और क्या साइड इफेक्ट्स ज्ञात हैं, इसके आधार पर वर्गीकृत करता हूँ: 429 के लिए सर्वर मार्गदर्शन का सम्मान करें, केवल संक्षिप्त कनेक्शन विफलताओं और चयनित 5xx प्रतिक्रियाओं का पुनः प्रयास करें, और जब किसी राइट का परिणाम अज्ञात हो तो idempotency या स्थिति समाधान की आवश्यकता होती है। रीट्राई एक लेयर पर रहते हैं, कैप्ड एक्सपोनेंशियल बैकऑफ और जिटर के साथ अधिकतम दो प्रयासों का उपयोग करते हैं, और एक टोकन बजट का उपभोग करते हैं जो विफलताओं के दौरान अतिरिक्त ट्रैफ़िक को सीमित करता है। निरंतर विफलताएं एक सर्किट को खोलती हैं और तेज़ी से विफल (fail fast) होती हैं; कूलडाउन के बाद, केवल कुछ हाफ-ओपन प्रोब्स ही पास होते हैं। एक अलग समवर्तीता सीमा और बाउंडेड कतार स्थानीय संसाधनों की रक्षा करती है। फॉल्ट इंजेक्शन तब डेडलाइन, प्रयास गणना, डुप्लिकेट प्रभाव और रिकवरी पथ को सत्यापित करता है।"
चरण-दर-चरण गहन विश्लेषण
समय को एक स्पष्ट बजट में बदलकर शुरुआत करें। इस अभ्यास में, डिपेंडेंसी कॉल से पहले स्थानीय कार्य के लिए 800 ms में से 120 ms और परिणाम को संसाधित करने के लिए 100 ms आरक्षित करें। यह 580 ms का डिपेंडेंसी बजट छोड़ता है। एक परीक्षण योग्य शुरुआती कॉन्फ़िगरेशन 220 ms पर सीमित पहला प्रयास, [0, 80) ms में यादृच्छिक बैकऑफ, और 220 ms पर सीमित दूसरा प्रयास है। सबसे खराब स्थिति 520 ms की खपत करती है और डिपेंडेंसी बजट में 60 ms छोड़ती है। ये सार्वभौमिक स्थिरांक नहीं हैं; उत्पादन मूल्यों को डाउनस्ट्रीम पर्सेंटाइल, सहन किए गए गलत टाइमआउट, नेटवर्क विलंब और लोड परीक्षणों से कैलिब्रेट किया जाना चाहिए।
कॉल चेन के माध्यम से एक पूर्ण डेडलाइन या मोनोटोनिक रूप से घटते शेष बजट का प्रचार करें। पुनः प्रयास करने से पहले, remaining की पुनर्गणना करें। यदि यह "अगला प्रयास कैप + न्यूनतम पूर्णता समय" से छोटा है, तो ऐसा कॉल शुरू करने के बजाय वापस लौटें जो समाप्त नहीं हो सकता। कनेक्शन और अनुरोध टाइमआउट सिमेंटिक्स को सटीक रूप से परिभाषित करें, जिसमें यह भी शामिल है कि क्या DNS, TLS, और कनेक्शन-पूल प्रतीक्षा कवर की गई है। एक नया इंस्टेंस ट्रैफ़िक स्वीकार करने से पहले कनेक्शन को वार्म कर सकता है ताकि हैंडशेक समय को धीमी डिपेंडेंसी के रूप में गलत न समझा जाए। रद्दीकरण का प्रचार करें, फिर भी यह मानते हुए कि यह रिमोट साइड द्वारा काम कमिट करने के बाद आ सकता है।
इसके बाद, एक विफलता-सिमेंटिक्स मैट्रिक्स बनाएं:
| परिणाम | रीट्राई? | पूर्व शर्तें और कार्रवाई |
|---|---|---|
| कनेक्शन स्थापित होने से पहले विफलता | हाँ | पर्याप्त बजट शेष है; बैकऑफ और जिटर का उपयोग करें |
| HTTP 429 | सशर्त | Retry-After का सम्मान करें; प्रतीक्षा और अगले प्रयास को समय सीमा में फिट होना चाहिए |
| HTTP 503 या चयनित 5xx | सशर्त | वेंडर इसे क्षणिक घोषित करता है और रीट्राई बजट शेष है |
| HTTP 400, 401, या 403 | आमतौर पर नहीं | पैरामीटर, क्रेडेंशियल या अनुमतियाँ ठीक करें; प्रतीक्षा करने से अनुरोध ठीक नहीं होगा |
| एक राइट भेजे जाने के बाद टाइमआउट | आँख बंद करके कभी नहीं | Idempotency key का पुन: उपयोग करें या ऑपरेशन की स्थिति को क्वेरी और समाधान करें |
| कॉलर रद्दीकरण या समय सीमा समाप्त | नहीं | काम जोड़ना बंद करें और एक स्पष्ट विफलता लौटाएं |
तीन द्वार प्रत्येक रीट्राई को नियंत्रित करते हैं: त्रुटि रीट्राई करने योग्य है, पर्याप्त समय शेष है, और रीट्राई बजट में एक टोकन है। एक साथ विफल होने वाले क्लाइंट्स को डीकोरिलेट करने के लिए कैप्ड एक्सपोनेंशियल बैकऑफ और रैंडमाइज्ड जिटर का उपयोग करें। जब यह मौजूद हो तो उपयोग करने योग्य सर्वर-निर्देशित रीट्राई टाइमिंग को प्राथमिकता दें। अधिकतम-प्रयास गणना में प्रारंभिक कॉल शामिल है; यह डिज़ाइन कुल दो प्रयासों से शुरू होता है। SDK के शब्दों को ध्यान से पढ़ें क्योंकि maxAttempts = 2 और "दो रीट्राई" का अर्थ क्रमशः दो कुल कॉल और तीन कुल कॉल हो सकता है।
उस एक लेयर पर पुनः प्रयास करें जो व्यावसायिक समय सीमा को सबसे अच्छी तरह समझती है। यदि सभी पाँच लेयर्स तीन प्रयास करती हैं, तो सैद्धांतिक बॉटम-लेयर लोड 243 गुना बढ़ जाता है। रीट्राई प्रवर्धन कारक (retry amplification factor) के रूप में downstream_attempts / logical_requests को ट्रैक करें। यह स्वस्थ परिस्थितियों में 1 के करीब होना चाहिए और दोषों के दौरान स्पष्ट रूप से सीमित होना चाहिए। एक टोकन बकेट या समकक्ष रीट्राई कोटा विफलताओं के बढ़ने पर खाली हो जाता है, फिर रीट्राई को रोक देता है या उन्हें कम दर पर अनुमति देता है, ताकि जब डिपेंडेंसी सबसे कमजोर हो तो क्लाइंट लोड जोड़ना बंद कर दें।
विशिष्ट डिपेंडेंसी ऑपरेशन को सर्किट ब्रेकर में लपेटें। बंद (closed) स्थिति कॉल्स की अनुमति देती है और न्यूनतम नमूना आकार के साथ एक स्लाइडिंग विंडो पर जिम्मेदार विफलताओं और धीमी कॉल्स को मापती है। सीमा पार करने पर सर्किट खुल जाता है। खुली (open) स्थिति डिपेंडेंसी को कॉल नहीं करती है और तुरंत एक पहचानने योग्य विफलता या व्यावसायिक रूप से स्वीकृत गिरावट लौटाती है। कूलडाउन के बाद, हाफ-ओपन स्थिति केवल कम संख्या में समवर्ती प्रोब्स की अनुमति देती है। पर्याप्त जांच सफलता सर्किट को बंद कर देती है; एक गंभीर विफलता इसे फिर से खोल देती है। थ्रेशोल्ड ट्रैफ़िक और रिकवरी विशेषताओं से आते हैं। "20 कॉल और 50% विफलताएं" एक उदाहरण है, कोई सार्वभौमिक स्थिरांक नहीं।
सर्किट ब्रेकर की लागत होती है। मोडल स्थिति परीक्षण और रिकवरी को अधिक जटिल बनाती है, एक लंबा कूलडाउन रिकवरी में देरी करता है, और एक मोटी सीमा स्वस्थ शार्ड्स को अवरुद्ध कर सकती है। प्रत्येक स्थिति संक्रमण को रिकॉर्ड करें, हाफ-ओपन प्रोब समवर्तीता को सीमित करें, और ब्रेकर को एक वास्तविक विफलता डोमेन तक सीमित करें। संक्षिप्त, कम जोखिम वाले दोषों के लिए, सख्त टाइमआउट, सिंगल-लेयर रीट्राई और एक रीट्राई कोटा पहले से ही पर्याप्त हो सकता है। केवल एक अन्य पैटर्न का नाम देने के लिए ब्रेकर न जोड़ें।
स्थानीय संसाधनों को अभी भी अलगाव (isolation) की आवश्यकता है। टैक्स डिपेंडेंसी को अपनी समवर्तीता सीमा, कनेक्शन पूल और बाउंडेड कतार दें ताकि धीमी कॉल हर चेकआउट थ्रेड या कनेक्शन का उपभोग न कर सकें। कतारबद्ध कॉल भी समय सीमा बजट खर्च करते हैं; उस काम को त्याग दें जो कतार से बाहर निकलने पर समाप्त नहीं हो सकता। एक फ़ॉलबैक सच्चा और समझाने योग्य होना चाहिए। "टैक्स अस्थायी रूप से अनुपलब्ध है" या एक मैन्युअल वर्कफ़्लो मान्य हो सकता है; किसी अज्ञात कर को शून्य मानना और चेकआउट को सफल घोषित करना मान्य नहीं है।
विफलता के तहत इनवेरिएंट्स का परीक्षण करें। कनेक्शन अस्वीकृति, एक 250 ms धीमी प्रतिक्रिया, विभिन्न Retry-After मानों के साथ 429s, 503, एक गैर-पुनः प्रयास करने योग्य 400, और "राइट कमिटेड, प्रतिक्रिया खो गई" को इंजेक्ट करें। दावा करें कि एक लॉजिकल अनुरोध अधिकतम दो डाउनस्ट्रीम प्रयास करता है, कुल विलंबता 800 ms से अधिक नहीं होती है, स्थायी त्रुटियों का पुनः प्रयास नहीं किया जाता है, और अज्ञात राइट्स डुप्लिकेट नहीं होते हैं। फिर सर्किट खुलने तक विफलताओं को बनाए रखें। तेज़ अस्वीकृति, बाउंडेड हाफ-ओपन प्रोब्स, रिकवरी के बाद सफल समापन, और एक असंतृप्त (unsaturated) बल्कहेड को सत्यापित करें।
उत्पादन मेट्रिक्स को कॉल्स को प्रयासों से अलग करना चाहिए: एंड-टू-एंड सफलता और p95/p99, प्रति-प्रयास परिणाम और लेटेंसी, कनेक्शन- बनाम अनुरोध-चरण टाइमआउट, रीट्राई प्रवर्धन, रीट्राई रिकवरी दर और अतिरिक्त लेटेंसी, रीट्राई-बजट संतुलन, ब्रेकर स्थिति और अस्वीकृति गणना, हाफ-ओपन जांच परिणाम, पूल समवर्तीता और कतार गहराई, साथ ही idempotency संघर्ष और समाधान परिणाम। केवल अंतिम सफलता एक ऐसे सिस्टम को छिपा सकती है जो डाउनस्ट्रीम ट्रैफ़िक के तीन गुना के साथ उपलब्धता खरीद रहा है।
उच्च-गुणवत्ता वाला नमूना उत्तर
"पहले मैं पुष्टि करूँगा कि यह एक सिंक्रोनस टैक्स लुकअप है और कॉलर 800 ms के बाद प्रतीक्षा करना बंद कर देता है। यदि मैं कॉल से पहले काम के लिए 120 ms और प्रतिक्रिया प्रबंधन के लिए 100 ms आरक्षित करता हूँ, तो डिपेंडेंसी को 580 ms मिलते हैं। मेरी शुरुआती नीति कुल दो प्रयासों का उपयोग करती है: प्रत्येक में अधिकतम 220 ms लग सकते हैं, उनके बीच [0, 80) ms का जिटरेड बैकऑफ होता है। प्रत्येक प्रयास से पहले, मैं प्रचारित शेष समय सीमा की जांच करता हूँ, ताकि एक लंबी कतार यांत्रिक रूप से दूसरी कॉल को ट्रिगर न करे।
विफलताओं को वर्गीकरण की आवश्यकता होती है। कनेक्शन स्थापित होने से पहले एक विफलता और एक वेंडर-परिभाषित क्षणिक 503 को बजट के भीतर पुनः प्रयास किया जा सकता है। एक 429 Retry-After का अनुसरण करता है, लेकिन यदि प्रतीक्षा समय सीमा से अधिक हो जाती है, तो मैं तुरंत विफल हो जाता हूँ। मैं 400, 401, या 403 का पुनः प्रयास नहीं करता। यदि ऑपरेशन स्थिति लिखता है, तो भेजने के बाद टाइमआउट का अर्थ अज्ञात परिणाम होता है। मुझे एक नया अंधा अनुरोध जारी करने के बजाय एक idempotency key का पुन: उपयोग करना चाहिए या स्थिति को क्वेरी और समाधान करना चाहिए।
मैं SDK, गेटवे और सर्विस मेश में रीट्राई की सूची बनाता हूँ, फिर रीट्राई को एक ऐसी लेयर पर रखता हूँ जो व्यावसायिक समय सीमा को देख सकती है और टोकन रीट्राई बजट लागू कर सकती है। पाँच लेयर्स में से प्रत्येक पर तीन प्रयास निचली कॉल को 243 गुना बढ़ा सकते हैं, इसलिए मैं लॉजिकल अनुरोधों से विभाजित भौतिक प्रयासों की निगरानी करता हूँ।
निरंतर विफलता के लिए, मैं टैक्स वेंडर और ऑपरेशन द्वारा एक सर्किट ब्रेकर का दायरा तय करता हूँ। बंद स्थिति न्यूनतम नमूने के साथ विफलता दर को मापती है, खुली स्थिति तेजी से विफल होती है, और हाफ-ओपन रिकवरी से पहले केवल कुछ प्रोब्स की अनुमति देती है। डिपेंडेंसी को एक अलग समवर्तीता पूल और बाउंडेड कतार भी मिलती है। डिग्रेडेशन केवल एक व्यावसायिक रूप से स्वीकृत, स्पष्ट स्थिति लौटाता है; यह कभी भी शून्य कर का निर्माण नहीं करता है।
अंत में, मैं दो-प्रयास अधिकतम, 800 ms सीमा, स्थायी त्रुटियों का कोई पुनः प्रयास नहीं, कोई डुप्लिकेट राइट्स नहीं, और बाउंडेड प्रोब्स के माध्यम से सर्किट रिकवरी को सत्यापित करने के लिए विफलताओं को इंजेक्ट करता हूँ। उत्पादन में मैं लॉजिकल सफलता, प्रयास परिणाम, रीट्राई प्रवर्धन, बजट संतुलन, ब्रेकर स्थिति और बल्कहेड संतृप्ति को एक साथ देखता हूँ।"
सामान्य गलतियाँ
- डिपेंडेंसी टाइमआउट को पूरे 800 ms पर सेट करना → स्थानीय पूर्णता के लिए कोई समय नहीं बचता है, और कॉलर द्वारा छोड़ दिए जाने के बाद भी डिपेंडेंसी संसाधन रखती है → समय सीमा से स्थानीय और नेटवर्क बजट घटाएं और शेष का प्रचार करें।
- प्रत्येक असफल प्रतिक्रिया का पुनः प्रयास करना → पैरामीटर और अनुमति त्रुटियां स्वयं ठीक नहीं होती हैं, इसलिए रीट्राई केवल लोड और विलंबता जोड़ते हैं → प्रोटोकॉल, त्रुटि कोड और साइड-इफेक्ट परिणाम द्वारा वर्गीकृत करें।
- प्रत्येक लेयर पर तीन प्रयासों को सक्षम करना → पाँच लेयर्स एक कॉल को 243 निचली-लेयर प्रयासों में बढ़ा सकती हैं → एक उपयुक्त लेयर पर पुनः प्रयास करें और प्रवर्धन को मापें।
- एक नई ID के साथ टाइम-आउट राइट को फिर से भेजना → पहला प्रयास कमिट हो सकता था, जिससे डुप्लिकेट शुल्क या संसाधन हो सकते हैं → एक idempotency key का पुन: उपयोग करें या स्थिति को क्वेरी और समाधान करें।
- जिटर या कैप के बिना एक्सपोनेंशियल बैकऑफ का उपयोग करना → क्लाइंट अभी भी सिंक्रनाइज़ तरंगों में पुनः प्रयास कर सकते हैं → प्रयासों और बीते समय को कैप करें, और देरी को यादृच्छिक बनाएं।
- सर्किट ब्रेकर को टाइमआउट प्रतिस्थापन के रूप में मानना → पहले से ही इन-फ़्लाइट कॉल्स अभी भी थ्रेड्स, कनेक्शन और कतारों पर कब्जा करती हैं → प्रति-प्रयास टाइमआउट रखें और समवर्तीता को अलग करें।
- हाफ-ओपन शुरू होते ही सभी ट्रैफ़िक को पुनर्स्थापित करना → एक नई रिकवर हो रही डिपेंडेंसी फिर से अभिभूत हो जाती है → बाउंडेड प्रोब्स की अनुमति दें और स्पष्ट रिकवरी सफलता की आवश्यकता हो।
- प्रत्येक वेंडर और एंडपॉइंट के लिए एक ग्लोबल ब्रेकर का उपयोग करना → एक स्थानीय खराबी स्वस्थ संसाधनों को अवरुद्ध करती है → स्वतंत्र विफलता डोमेन के लिए ब्रेकर स्थिति का दायरा तय करें।
- फ़ॉलबैक से हमेशा सफलता लौटाना → अज्ञात डेटा को सही के रूप में प्रस्तुत किया जाता है और व्यावसायिक सिमेंटिक्स को तोड़ता है → केवल स्पष्ट सीमाओं के साथ अनुमोदित डिग्रेडेशन का उपयोग करें।
- केवल अंतिम सफलता दर का निरीक्षण करना → एक रीट्राई स्टॉर्म अस्थायी रूप से डाउनस्ट्रीम गिरावट को छिपा सकता है → लॉजिकल कॉल्स, भौतिक प्रयासों, जोड़ी गई लेटेंसी और संतृप्ति का निरीक्षण करें।
फॉलो-अप प्रश्न और उत्तर
फॉलो-अप 1: टाइमआउट डाउनस्ट्रीम p99 का कितना गुणक होना चाहिए?
कोई निश्चित गुणक नहीं है। एक स्वीकार्य गलत-टाइमआउट दर चुनें, मिलान लेटेंसी पर्सेंटाइल से शुरू करें, और नेटवर्क विलंब, क्रॉस-रीजन कॉल, कनेक्शन स्थापना और छोटे बदलावों के लिए भत्ता जोड़ें। परिणाम अभी भी अपस्ट्रीम समय सीमा में फिट होना चाहिए। जब p99 p50 के करीब होता है, तो एक छोटा लेटेंसी बदलाव कई टाइमआउट का कारण बन सकता है, इसलिए अतिरिक्त पैडिंग उपयुक्त हो सकती है। सत्यापित करें कि क्या DNS, TLS, और कनेक्शन-पूल प्रतीक्षा टाइमर में शामिल हैं।
फॉलो-अप 2: क्या 429 और 503 दोनों रीट्राई करने योग्य हैं?
केवल सशर्त रूप से। 429 के लिए Retry-After को प्राथमिकता दें, लेकिन प्रतीक्षा और अन्य प्रयास को शेष बजट में फिट होना चाहिए। अन्यथा, एक पहचानने योग्य विफलता लौटाएं। 503 का पुनः प्रयास केवल तभी करें जब वेंडर अनुबंध इसे क्षणिक चिह्नित करता है। दोनों रीट्राई बजट का उपभोग करते हैं; किसी को भी ओवरलोड सर्वर के सिग्नल को अधिक तत्काल ट्रैफ़िक में नहीं बदलना चाहिए।
फॉलो-अप 3: उच्च रीट्राई रिकवरी दर अभी भी एक अस्वस्थ प्रणाली का संकेत क्यों दे सकती है?
अंतिम सफलता अतिरिक्त लोड और लेटेंसी के साथ खरीदी जा सकती है। यदि 100 लॉजिकल कॉल्स 180 डाउनस्ट्रीम प्रयास उत्पन्न करते हैं, तो प्रवर्धन 1.8 है। जब डिपेंडेंसी क्षमता के करीब होती है, तो अतिरिक्त 80% रिकवरी में देरी कर सकता है। प्रवर्धन, प्रयास लेटेंसी, बजट की थकावट और डाउनस्ट्रीम संतृप्ति के साथ रिकवरी दर का मूल्यांकन करें।
फॉलो-अप 4: क्या सर्किट खुला होने पर भी आपको दर सीमित करने (rate limiting) या बल्कहेड्स की आवश्यकता है?
हाँ। ब्रेकर एक डिपेंडेंसी के लिए नई कॉल्स को ब्लॉक करता है, लेकिन स्थानीय अनुरोध पहले से ही इन-फ़्लाइट या कतारबद्ध हो सकते हैं, और अन्य डिपेंडेंसी अभी भी संसाधनों का उपभोग कर सकती हैं। समवर्तीता सीमाएं, अलग-अलग पूल और बाउंडेड कतारें स्थानीय क्षमता की मालिक हैं; प्रवेश दर सीमित करना नए लोड को नियंत्रित करता है। हाफ-ओपन प्रोब्स को असीमित साझा क्षमता के बजाय एक छोटे स्वतंत्र भत्ते की भी आवश्यकता होती है।
फॉलो-अप 5: क्या यह कोई समस्या है यदि प्रत्येक इंस्टेंस अपनी स्वयं की ब्रेकर स्थिति बनाए रखता है?
स्थितियां भिन्न हो सकती हैं, लेकिन दृढ़ता से साझा की गई स्थिति एक और सिंक्रोनस डिपेंडेंसी और अधिक लेटेंसी जोड़ती है। एक सामान्य डिज़ाइन प्रत्येक इंस्टेंस को समान कॉन्फ़िगरेशन और स्थानीय स्थिति देता है; उच्च ट्रैफ़िक पर, प्रत्येक पर्याप्त नमूने देखता है और विफलता संकेत स्वाभाविक रूप से फैलता है। कम मात्रा वाले इंस्टेंस या विश्व स्तर पर समन्वित विफलता डोमेन एक सर्विस मेश या केंद्रीकृत लेयर को सही ठहरा सकते हैं। किसी भी स्थिति में, विफलता के दौरान दायरा, नमूना आकार और अधिकतम अतिरिक्त ट्रैफ़िक बताएं।
फॉलो-अप 6: इसे एक एसिंक्रोनस कतार कब बनना चाहिए?
यदि HTTP प्रतिक्रिया के लिए टैक्स परिणाम की आवश्यकता नहीं है, या रिकवरी में उपयोगकर्ता की समय सीमा से अधिक समय लग सकता है, तो एसिंक्रोनस प्रसंस्करण एक बेहतर फिट है। एक कार्य को बनाए रखें, क्वेरी योग्य स्थिति लौटाएं, और एक उपभोक्ता को अपनी रीट्राई और डेड-लेटर नीति का उपयोग करने दें। एक कतार idempotency, समाप्ति या डिग्रेडेशन चिंताओं को दूर नहीं करती है, लेकिन यह लंबी रिकवरी को सिंक्रोनस कनेक्शन और 800 ms बजट से बाहर ले जाती है।
फॉलो-अप 7: आप कॉन्फ़िगरेशन घटना के बिना इसे कैसे रोल आउट करेंगे?
रीट्राई जोड़े बिना या ट्रैफ़िक को अस्वीकार किए बिना टाइमआउट, रीट्राई और सर्किट निर्णयों को रिकॉर्ड करके शुरुआत करें जो लिए गए होते। पुष्टि करें कि SDKs अतिरिक्त प्रयासों को नहीं छिपाते हैं। फिर वेंडर या कुछ इंस्टेंसेस द्वारा कैनरी करें, वैश्विक रीट्राई बजट को कैप करें, और एक त्वरित अक्षम स्विच रखें। विस्तार करने से पहले प्रयास की मात्रा, एंड-टू-एंड टेल लेटेंसी, खुली अवधि, हाफ-ओपन विफलताओं और डिपेंडेंसी क्षमता को देखें।