टॉमकैट उदाहरणों के बीच शेयर सत्र (चिपचिपा सत्रों का उपयोग किए बिना)

Question

मेरे पास 3 टोमकैट सर्वर और लोड बैलेंसर होगा जो 'sticky sessions' का उपयोग किए बिना अनुरोध भेजता है।

मैं सर्वर के बीच सत्र का डेटा साझा करना चाहता हूं और मैं उन्हें डीबी में रखने में सोच रहा हूं। अनुरोधों को तेजी से और don't put my db under heavy load पर सेवा देने के लिए मैं अपने डीबी के सामने एक परत के रूप में memcached का उपयोग करना चाहता हूं।

मैं अपना कस्टमाइज्ड टॉमकैट प्रबंधक प्रदान करने में सोच रहा हूं जो डीबी को सत्र डेटा प्राप्त करने/जारी रखने से पहले memcached का उपयोग करता है, इस समय मुझे इसे करने का पारदर्शी तरीका नहीं दिखता है (इसका मतलब है कि मुझे इसे प्रबंधित करना होगा फिर मामले में मैं एक और ऐप सर्वर पर स्विच)।

क्या यह एक अच्छा समाधान है या आप बेहतर दृष्टिकोण देखते हैं?

Answer 1

हम अपने आवेदन में एक समान काम करते हैं (वेबलॉगिक, लेकिन इससे कोई फर्क नहीं पड़ता), जहां हमारे पास ब्राउज़र में एक कुकी के रूप में संग्रहीत एक अद्वितीय सत्र कुंजी है। तब उस कुंजी का उपयोग प्रत्येक अनुरोध पर डेटाबेस से प्रासंगिक सत्र डेटा को पुनर्स्थापित करने के लिए किया जाएगा।

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

Answer 2

मुझे लगता है कि Terracotta Web Sessions वह है जो आप चाहते हैं।

Answer 3

ऐप सर्वर (आपके मामले में टॉमकैट) के बाहर अपना सत्र स्थिति संग्रहीत करना, बड़े पैमाने पर वेबसाइटों के लिए एक बहुत ही आम और अनुशंसित कॉन्फ़िगरेशन है। यह आमतौर पर Shared Nothing नामक आर्किटेक्चर शैली की खोज में किया जाता है।

आप अपने राज्य को कई अलग-अलग स्थानों में स्टोर कर सकते हैं: डीबी, memcached, वाणिज्यिक प्रतिकृति कैश, आदि वे सभी व्यापार बंद के विभिन्न मिश्रणों के साथ काम करते हैं। व्यक्तिगत रूप से, मुझे memcached के साथ बड़ी सफलता मिली है। Memcached बेहद तेज़ और स्थिर है।

आम तौर पर, मैं सादगी का चयन करता हूं और एन memcache सर्वर का उपयोग करता हूं जहां एन> 1, कहते हैं 2. जैसे उपयोगकर्ता लॉग इन करते हैं, ऐप सर्वर यह तय करने के लिए एक सिक्का फ़्लिप करते हैं कि कौन सा सर्वर उपयोगकर्ता को संग्रहीत करता है। ब्राउजर को भेजी गई कुकी में यह जानने के लिए जानकारी शामिल है कि कौन से मेमकेचे सर्वर से आगे बढ़ने के लिए। ब्राउजर के बाद के अनुरोध प्रत्येक अनुरोध पर उपयुक्त memcache सर्वर से राज्य लाने के लिए। एक memcache सर्वर विफल होना चाहिए, उपयोगकर्ता को फिर से लॉगिन करना होगा क्योंकि ऐप सर्वर एक नए सर्वर को संशोधित करते हैं, लेकिन यह बेहद दुर्लभ है।

Answer 4

डेटाबेस में स्थायी सत्र आपकी स्केलेबिलिटी को सीमित करते हैं। यदि स्केलेबिलिटी आपके लिए यह महत्वपूर्ण नहीं है (डीबी + memcached) एक मान्य दृष्टिकोण है।

गैर-स्टिकी-सेशन का उपयोग करते समय आपको ध्यान में रखना एक बात है समवर्ती अनुरोध: जब आपके पास उदा। AJAX अनुरोध (समानांतर/समवर्ती रूप से निष्पादित) वे विभिन्न tomcats (गैर चिपचिपापन के कारण) द्वारा परोसा जाएगा और इसलिए समवर्ती सत्र का उपयोग करें। जब तक आपके समवर्ती अनुरोध हों, जो उस सत्र को संशोधित कर सकता है जिसे आपको किसी प्रकार के सिंक्रनाइज़ेशन/सत्र लॉकिंग को लागू करने की आवश्यकता है।

शायद यह आपके लिए रूचि है: मैंने memcached-session-manager दोनों इष्टतम प्रदर्शन और असीमित स्केलेबिलिटी के लक्ष्य के साथ बनाया है। यह किसी भी memcached- संगत बैकएंड (उदाहरण के लिए memcachedb, membase आदि या बस memcached) के साथ काम कर सकते हैं। हालांकि मूल रूप से चिपचिपा सत्र दृष्टिकोण के लिए बनाया गया था, लेकिन पहले से ही branch for nonsticky-sessions मौजूदा और sample app दिखा रहा है कि यह कैसे काम करता है। अभी thread on the mailing list on further improvements for nonsticky-sessions है (समवर्ती अनुरोधों को संभालने और एकल-बिंदु-विफलता को रोकने)।