वेब सर्विसेज के संदर्भ में, मैंने "टीसीपी कनेक्शन मंथन" शब्द का उपयोग किया है। विशेष रूप से Twitter finagle में ऐसा होने से बचने के तरीके हैं। यह कैसे होता है? इसका क्या मतलब है?टीसीपी कनेक्शन मंथन के लिए इसका क्या अर्थ है?
इस शब्द के लिए कई उपयोग हो सकते हैं, लेकिन मैंने हमेशा उन मामलों में उपयोग किया है जहां बहुत कम समय में कई टीसीपी कनेक्शन किए जा रहे हैं, जिससे क्लाइंट पर प्रदर्शन समस्याएं और संभावित रूप से सर्वर भी ।
यह तब होता है जब क्लाइंट कोड लिखा जाता है जो स्वचालित रूप से किसी भी प्रकार की टीसीपी विफलता पर कनेक्ट होता है। यदि कनेक्शन विफल होने से पहले कनेक्शन विफलता होती है (या प्रोटोकॉल एक्सचेंज में बहुत जल्दी) तो क्लाइंट लगातार व्यस्त लूप में कनेक्शन बना सकता है। इससे क्लाइंट साइड पर प्रदर्शन समस्याएं हो सकती हैं - सबसे पहले कि बहुत व्यस्त लूप में सीपीयू चक्रों को चूसने की प्रक्रिया होती है, और दूसरी बात यह है कि प्रत्येक कनेक्शन प्रयास क्लाइंट-साइड पोर्ट नंबर का उपभोग करता है - यदि यह तेज़ी से चला जाता है तो सॉफ्टवेयर चारों ओर लपेट सकता है जब उन्होंने अधिकतम पोर्ट नंबर मारा (एक बंदरगाह केवल 16-बिट संख्या है यह निश्चित रूप से असंभव नहीं है)।
मजबूत कोड लिखते समय एक योग्य उद्देश्य है, यह सरल "स्वचालित पुनः प्रयास" दृष्टिकोण थोड़ा सा बेवकूफ है। आप अन्य संदर्भों में समान समस्याएं देख सकते हैं - उदा। एक मूल प्रक्रिया लगातार बच्चे की प्रक्रिया को पुनरारंभ करना जो तुरंत दुर्घटनाग्रस्त हो जाती है। इससे बचने के लिए एक आम तंत्र कुछ प्रकार की बढ़ती बैक-ऑफ है। इसलिए, जब पहला कनेक्शन विफल रहता है तो आप तुरंत पुनः कनेक्ट हो जाते हैं। यदि यह थोड़े समय के भीतर फिर से विफल रहता है (उदाहरण के लिए 30 सेकंड) तो आप फिर से कनेक्ट होने से 2 सेकंड पहले प्रतीक्षा करें। यदि यह 30 सेकंड के भीतर फिर से विफल हो जाता है, तो आप 4 सेकंड प्रतीक्षा करते हैं, और इसी तरह। इस तकनीक पर अधिक पृष्ठभूमि के लिए the Wikipedia article on exponential backoff (या this blog post इस एप्लिकेशन के लिए अधिक उपयुक्त हो सकता है) पढ़ें।
इस दृष्टिकोण का लाभ यह है कि यह क्लाइंट या सर्वर को जबरदस्त नहीं करता है, लेकिन इसका मतलब यह भी है कि क्लाइंट मैन्युअल हस्तक्षेप के बिना अभी भी ठीक हो सकता है (उदाहरण के लिए, एक अप्रत्याशित सर्वर पर सॉफ़्टवेयर के लिए विशेष रूप से महत्वपूर्ण है, उदाहरण के लिए, या बड़े में समूहों)।
ऐसे मामलों में जहां वसूली का समय महत्वपूर्ण है, टीसीपी कनेक्शन निर्माण की सरल दर-सीमा भी काफी संभव है - शायद 1 प्रति सेकंड या कुछ से अधिक नहीं। यदि प्रति सर्वर के कई ग्राहक हैं, हालांकि, यह अधिक सरल दृष्टिकोण अभी भी सर्वर को स्वीकार करने के भार से एक उच्च कनेक्शन दर बंद कर सकता है।
यदि आप घातीय बैकऑफ को नियोजित करने की योजना बना रहे हैं, तो मुझे नोट करना एक बात है - मैं अधिकतम प्रतीक्षा समय लगाने का सुझाव देता हूं, या आपको लगता है कि लंबे समय तक असफलताओं को एक बार फिर से सर्वर को कनेक्शन स्वीकार करने शुरू होने के बाद एक ग्राहक को पुनर्प्राप्त करने में बहुत लंबा समय लगता है। मैं ज्यादातर परिस्थितियों में उचित अधिकतम के रूप में 5 मिनट की तरह कुछ सुझाव दूंगा, लेकिन निश्चित रूप से यह एप्लिकेशन पर निर्भर करता है।
समझ में आता है - यह निश्चित रूप से किसी क्लाइंट-साइड के साथ एक सेवा के लिए एक मुद्दा हो सकता है जो अन्य सर्वर तक पहुंचने में विफल रहता है। आपके उत्तर के लिए धन्यवाद! – eman