स्टिकी और गैर-स्टिकी सत्र

Question

मैं चिपचिपा और गैर-चिपचिपा सत्रों के बीच अंतर जानना चाहता हूं। इंटरनेट से पढ़ने के बाद मुझे क्या समझ में आया:

स्टिकी : केवल एकल सत्र वस्तु होगी।

गैर-चिपचिपा सत्र : प्रत्येक सर्वर नोड के लिए सत्र ऑब्जेक्ट

Answer 1

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

हालाँकि, यदि आपकी वेबसाइट पर कई वेब सर्वर हैं, जो लोड बैलेंसर के पीछे बैठते हैं, तो लोड बैलेंसर तय करता है कि कौन सा वास्तविक (भौतिक) वेब-सर्वर प्रत्येक अनुरोध पर जाए। उदाहरण के लिए, यदि लोड बैलेंसर के पीछे 3 वेब सर्वर A, B और C हैं, तो यह संभव है कि www.mywebsite.com/index.jsp को सर्वर A, www.mywebsite.com/login.jsp से सेवा दी जाए। सर्वर B और www.mywebsite.com/accoutdetails.php को सर्वर C से सेवा दी जाती है।

अब, यदि अनुरोधों को (भौतिक रूप से) 3 अलग-अलग सर्वरों से परोसा जा रहा है, तो प्रत्येक सर्वर ने आपके लिए एक सत्र ऑब्जेक्ट बनाया है और क्योंकि ये सत्र ऑब्जेक्ट तीन स्वतंत्र बॉक्स पर बैठते हैं, सत्र वस्तु में कोई जानने का कोई सीधा तरीका नहीं है। दूसरे का। इन सर्वर सत्रों के बीच सिंक्रनाइज़ करने के लिए, आपको सत्र डेटा को एक परत में लिखना / पढ़ना पड़ सकता है, जो सभी के लिए सामान्य है - जैसे डीबी। अब इस उपयोग-मामले के लिए db से / को डेटा लिखना और पढ़ना एक अच्छा विचार नहीं हो सकता है। अब, यहाँ चिपचिपा-सत्र की भूमिका आती है ।

यदि लोड बैलेंसर को चिपचिपा सत्रों का उपयोग करने का निर्देश दिया जाता है, तो आपके सभी इंटरैक्शन एक ही भौतिक सर्वर के साथ होंगे, भले ही अन्य सर्वर मौजूद हों। इस प्रकार, इस वेबसाइट के साथ आपकी संपूर्ण बातचीत में आपकी सत्र वस्तु समान होगी।

संक्षेप में, स्टिकी सत्रों के मामले में, आपके सभी अनुरोधों को उसी भौतिक वेब सर्वर को निर्देशित किया जाएगा, जबकि गैर-स्टिकी लोडबलर के मामले में आपके अनुरोधों को पूरा करने के लिए कोई भी वेबसर्वर चुन सकता है।

एक उदाहरण के रूप में, आप अमेज़न के इलास्टिक लोड बैलेंसर और चिपचिपे सत्रों के बारे में यहाँ पढ़ सकते हैं: http://aws.typepad.com/aws/2010/04/new-elastic-load-balancing-feature-sticky-session.html

Comments

@ टीजे- अगर एक नोड अनुपलब्ध होगा तो क्या होगा?

— gstackoverflow

ज्यादातर मामलों में, सत्र खो जाएगा। एडब्ल्यूएस ईएसबी के मामले में यदि कोई उदाहरण विफल हो जाता है या अस्वस्थ हो जाता है, तो लोड बैलेंसर उस उदाहरण के लिए अनुरोध करना बंद कर देता है, इसके बजाय मौजूदा लोड बैलेंसिंग एल्गोरिदम के आधार पर एक नया स्वस्थ उदाहरण चुनता है। लोड बैलेंसर सत्र को अब नए स्वस्थ उदाहरण के लिए "अटका हुआ" मानता है, और असफल उदाहरण वापस आने पर भी उस उदाहरण के लिए अनुरोध जारी रखता है।

— टीजे-

क्या के अनुसार LoadBalancer HTTP सत्र को चिपचिपा बनाता है? HTTPS कनेक्शन पर विशिष्ट यह मुद्दा दिलचस्प हो जाता है। क्या आप वेब सर्वरों की निजी कुंजी के साथ एलबी फ़ीड करते हैं, ताकि यह एसएसएल कनेक्शन को तोड़ने और HTTP सत्र लाने में सक्षम हो? या क्या एलबी केवल क्लाइंट आईपी एड्रेस का उपयोग करता है? इस मामले में, प्रॉक्सी सर्वर के बारे में क्या है जहां कई क्लाइंट एक ही आईपी-एड्रेस का उपयोग करते हैं? या इससे भी बदतर, मोबाइल क्लाइंट, जहां आईपी-पता बार-बार बदलता है? या फिर उसके लिए एक बेहतर तकनीक भी है? धन्यवाद

— बजे

हां, आप बिल्कुल सही हैं। इस संदर्भ में "x- फ़ॉर्वर्ड-फॉर" हेडर या एक स्टिकी-कुकी का उपयोग करने के लिए , SSL समाप्ति का उपयोग करने की आवश्यकता है और इसलिए, अनुरोध को LB में डिक्रिप्ट करने की आवश्यकता है।

— TJ-

@ g000ze जब सीधे इंटरनेट पर काम नहीं किए जाने वाले अनुप्रयोगों से निपटते हैं, तो मेरा मानना ​​है कि टीएलएस को केवल बाहरी प्रॉक्सी सर्वर पर सक्षम करना सामान्य है। (एक लोड बैलेंसर पर विचार किया जा सकता है, शायद सरलीकृत रूप से, एक विशेष प्रकार के प्रॉक्सी सर्वर के रूप में, जो किसी भी एकाधिक सर्वर पर अनुरोध को पारित कर सकता है।) लोड बैलेंसर और अन्य सर्वरों के बीच आवागमन एक स्थानीय, सुरक्षित नेटवर्क पर होगा। , और इसलिए यह अक्सर इसे एन्क्रिप्ट करने के लिए आवश्यक नहीं है, या अगर इसे एन्क्रिप्ट करने की आवश्यकता है, तो एक स्व हस्ताक्षरित प्रमाण पत्र पर्याप्त हो सकता है (चूंकि प्रॉक्सी को इस पर भरोसा करने के लिए कॉन्फ़िगर किया जा सकता है)।

— jpmc26

Answer 2

मैंने यहां कुछ और विवरणों के साथ एक उत्तर दिया है: https://stackoverflow.com/a/11045462/592477

या आप इसे वहां पढ़ सकते हैं ==>

जब आप लोडबैलेंसिंग का उपयोग करते हैं तो इसका मतलब है कि आपके पास टॉमकैट के कई उदाहरण हैं और आपको लोड को विभाजित करने की आवश्यकता है।

• यदि आप चिपचिपे सत्र के बिना सत्र प्रतिकृति का उपयोग कर रहे हैं: कल्पना करें कि आपके पास अपने वेब ऐप का उपयोग करने वाला केवल एक उपयोगकर्ता है, और आपके पास 3 टोमैट इंस्टेंसेस हैं। यह उपयोगकर्ता आपके ऐप पर कई अनुरोध भेजता है, फिर लोडबेलर इनमें से कुछ अनुरोधों को पहले टॉमकैट उदाहरण के लिए भेज देगा, और इनमें से कुछ अन्य अनुरोधों को दूसरे उदाहरण के लिए, और दूसरे को तीसरे पर भेजेगा।
• यदि आप प्रतिकृति के बिना चिपचिपा सत्र का उपयोग कर रहे हैं:कल्पना करें कि आपके पास अपने वेब ऐप का उपयोग करने वाला केवल एक उपयोगकर्ता है, और आपके पास 3 टोमैट इंस्टेंसेस हैं। यह उपयोगकर्ता आपके ऐप पर कई अनुरोध भेजता है, फिर लोडबलर पहले उपयोगकर्ता के अनुरोध को तीन टॉमकैट इंस्टेंस में से एक को भेजेगा, और अन्य सभी अनुरोध जो इस उपयोगकर्ता द्वारा उसके सत्र के दौरान भेजे गए हैं, उसी टॉमकैट इंस्टेंस पर भेजे जाएंगे। इन अनुरोधों के दौरान, यदि आप इस टॉमकैट उदाहरण को बंद या फिर से चालू करते हैं (टॉमकैट इंस्टेंस जिसका उपयोग किया जाता है), लोडबेलर एक अन्य टॉमकैट इंस्टेंस के लिए शेष अनुरोध भेजता है जो अभी भी चल रहा है, लेकिन जब तक आप सत्र प्रतिकृति का उपयोग नहीं करते हैं, जो इंस्टेंस प्राप्त करता है शेष अनुरोधों में उपयोगकर्ता सत्र की एक प्रति नहीं है, तो इस टॉमकैट के लिए उपयोगकर्ता एक सत्र शुरू करता है: उपयोगकर्ता अपने सत्र को ढीला कर देता है और वेब ऐप से डिस्कनेक्ट हो जाता है, हालांकि वेब ऐप अभी भी चल रहा है।
• यदि आप सत्र प्रतिकृति के साथ चिपचिपा सत्र का उपयोग कर रहे हैं:कल्पना करें कि आपके पास अपने वेब ऐप का उपयोग करने वाला केवल एक उपयोगकर्ता है, और आपके पास 3 टॉमकैट इंस्टेंसेस हैं। यह उपयोगकर्ता आपके ऐप पर कई अनुरोध भेजता है, फिर लोडबलर पहले उपयोगकर्ता के अनुरोध को तीन टॉमकैट इंस्टेंस में से एक को भेजेगा, और अन्य सभी अनुरोध जो इस उपयोगकर्ता द्वारा उसके सत्र के दौरान भेजे गए हैं, उसी टॉमकैट इंस्टेंस पर भेजे जाएंगे। इन अनुरोधों के दौरान, यदि आप इस टॉमकैट उदाहरण को बंद या फिर से शुरू करते हैं (टॉमकैट इंस्टेंस जिसका उपयोग किया जाता है), लोडबेलर शेष अनुरोधों को एक दूसरे टॉमकैट उदाहरण के लिए भेजता है जो अभी भी चल रहा है, जैसा कि आप सत्र प्रतिकृति का उपयोग करते हैं, उदाहरण के लिए टॉमकैट शेष अनुरोधों को प्राप्त करता है। उपयोगकर्ता सत्र की एक प्रति तब उपयोगकर्ता अपने सत्र पर रखता है: उपयोगकर्ता डिस्कनेक्ट किए बिना आपके वेब ऐप को ब्राउज़ करना जारी रखता है, टॉमकैट उदाहरण का शटडाउन उपयोगकर्ता नेविगेशन को प्रभावित नहीं करता है।

Comments

हम्म .. इसे पढ़कर मुझे आश्चर्य होता है: क्या इसका कोई चौथा विकल्प नहीं होगा: सत्र प्रतिकृति के साथ गैर-स्टिकी? या अलग तरीके से रखें: अगर किसी को भी अलग-अलग उदाहरणों के लिए सत्र की प्रतिकृति मिलती है, तो एक चिपचिपा सत्र होने का क्या फायदा है? मेरा मतलब है, यदि आप उदाहरणों में सत्रों की नकल कर रहे हैं, तो आप किसी भी सर्वर से अनुरोध को आगे भेज सकते हैं, है ना? मैं क्या खो रहा हूँ?

— डिंगलपदम्

@dingalapadum आप सही कह रहे हैं, सैद्धांतिक रूप से आप चिपचिपे सत्र के बिना सत्र प्रतिकृति हो सकते हैं। लेकिन एक बड़े क्लस्टर के मामले में यह नेटवर्क के प्रदर्शन के लिए खराब है। फिर चिपचिपा सत्र के साथ सत्र प्रतिकृति का उपयोग करने में कुछ रणनीतियाँ हैं जैसे कि tomcat ( tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html ) में एक चिपचिपा सत्र और केवल एक प्रतिकृति (एक नोड यहाँ) डालना है। बैकअप प्रबंधक जिसे सभी नोड सत्र प्रतिकृति रखता है) कहा जाता है।

— निको

फिर चिपचिपा सत्र आपको केवल एक सत्र प्रतिकृति की अनुमति देता है, जो बड़े क्लस्टर में सबसे अच्छा है।

— निको

आह, मैं देख रहा हूँ - अगर मैं सही ढंग से समझूं, तो आपका मतलब है कि पूरे क्लस्टर में सभी सत्रों की नकल करने से आंतरिक रूप से क्लस्टर भर जाएगा - मुझे समस्या दिखाई देती है। ओह, और अब आपके उत्तर पर करीब से नज़र डालते हुए, मैंने अभी देखा, कि यह वास्तव में आपके द्वारा वर्णित पहला मामला है ... 'duh me' ..

— dingalapadum

@dingalapadum आपके प्रश्न का स्वागत है यह उत्तर में सुधार करने की अनुमति देता है

— निको