कई मशीनों में बड़ी वेबसाइटें "लोड संतुलित" हो सकती हैं। कई लोड संतुलित सेटअपों में, उपयोगकर्ता सत्र के दौरान किसी भी बैकेंड मशीन को हिट कर सकता है। इसके कारण, कई मशीनें उपयोगकर्ता सत्रों को साझा करने की अनुमति देने के लिए मौजूद हैं।
चुना गया तरीका नियोजित लोड संतुलन की शैली पर निर्भर करेगा, साथ ही बैकएंड भंडारण की उपलब्धता / क्षमता:
केवल कुकीज़ में संग्रहीत सत्र जानकारी : सत्र जानकारी (न केवल एक सत्र पहचानकर्ता) उपयोगकर्ता की कुकी में संग्रहीत होती है। उदाहरण के लिए, उपयोगकर्ता की कुकी में उनकी खरीदारी टोकरी की सामग्री हो सकती है। सत्र डेटा के साथ छेड़छाड़ करने वाले उपयोगकर्ताओं को रोकने के लिए, कुकी के साथ एक HMAC प्रदान किया जा सकता है। यह विधि संभवतः अधिकांश अनुप्रयोगों के लिए कम से कम उपयुक्त है:
- बैकएंड स्टोरेज की आवश्यकता नहीं है
- उपयोगकर्ता को हर बार एक ही मशीन को हिट करने की आवश्यकता नहीं होती है, इसलिए DNS लोड संतुलन को नियोजित किया जा सकता है
- डेटाबेस मशीन से सत्र की जानकारी प्राप्त करने से जुड़ी कोई विलंबता नहीं है (क्योंकि यह HTTP अनुरोध के साथ प्रदान की गई है)। उपयोगी यदि आपकी साइट विभिन्न महाद्वीपों पर मशीनों द्वारा संतुलित लोड है।
- सत्र में संग्रहीत किए जा सकने वाले डेटा की मात्रा सीमित है (4K कुकी आकार सीमा द्वारा)
- यदि उपयोगकर्ता को अपने सत्र की सामग्री को देखने में सक्षम नहीं होना चाहिए, तो एन्क्रिप्शन को नियोजित करना होगा
- सत्र डेटा की उपयोगकर्ता छेड़छाड़ को रोकने के लिए HMAC (या समान) को नियोजित किया जाना है
- चूंकि सत्र डेटा सर्वर साइड संग्रहीत नहीं है, इसलिए डेवलपर्स के लिए डीबग करना अधिक कठिन है
लोड बैलेंसर हमेशा उपयोगकर्ता को एक ही मशीन के लिए निर्देशित करता है : कई लोड बैलेंसर्स अपना स्वयं का सत्र कुकी सेट कर सकते हैं, यह दर्शाता है कि उपयोगकर्ता किस बैकेंड मशीन से अनुरोध कर रहा है और भविष्य में उन्हें उस मशीन पर निर्देशित कर सकता है। क्योंकि उपयोगकर्ता को हमेशा एक ही मशीन के लिए निर्देशित किया जाता है, कई मशीनों के बीच सत्र साझा करने की आवश्यकता नहीं होती है। यह कुछ स्थितियों में अच्छा हो सकता है:
- एक मौजूदा एप्लिकेशन के सेशन हैंडलिंग को मल्टीपल मशीन अवेयर होने के लिए बदलने की आवश्यकता नहीं हो सकती है
- किसी भी साझा डेटाबेस सिस्टम (या समान) को सत्रों के भंडारण के लिए आवश्यक नहीं है, संभवतः बढ़ती विश्वसनीयता, लेकिन जटिलता की कीमत पर
- एक बैकएंड मशीन नीचे जा रही है, इसके साथ शुरू किए गए किसी भी उपयोगकर्ता सत्र को नीचे ले जाएगी।
- मशीनों को सेवा से बाहर ले जाना अधिक कठिन है। मशीन बंद होने से पहले रखरखाव के लिए ले जाने के लिए मशीन पर सत्र वाले उपयोगकर्ताओं को अपने कार्यों को पूरा करने की अनुमति दी जानी चाहिए। इसका समर्थन करने के लिए, वेब लोड बैलेंसरों में एक निश्चित बैकएंड मशीन के लिए "नाली" अनुरोध करने की सुविधा हो सकती है।
साझा बैकएंड डेटाबेस या की / वैल्यू स्टोर : सत्र की जानकारी एक बैकएंड डेटाबेस में संग्रहीत होती है, जिसमें सभी वेबसर्वर्स के पास क्वेरी और अपडेट की पहुंच होती है। उपयोगकर्ता का ब्राउज़र सत्र जानकारी की ओर इशारा करते हुए एक पहचानकर्ता (जैसे सत्र आईडी) के साथ एक कुकी संग्रहीत करता है। यह शायद तीन में से सबसे साफ विधि है:
- उपयोगकर्ता को संग्रहीत सत्र जानकारी के लिए कभी भी उजागर नहीं होना चाहिए।
- उपयोगकर्ता को हर बार एक ही मशीन को हिट करने की आवश्यकता नहीं होती है, इसलिए DNS लोड संतुलन को नियोजित किया जा सकता है
- एक नुकसान वह अड़चन है जिसे बैकएंड स्टोरेज सिस्टम पर रखा जा सकता है।
- सत्र जानकारी की समय-सीमा समाप्त हो सकती है और लगातार बैकअप ली जा सकती है।
कुल मिलाकर, अधिकांश डायनेमिक वेब एप्लिकेशन कई डेटाबेस क्वेरी या की / वैल्यू स्टोर रिक्वेस्ट करते हैं, इसलिए डेटाबेस या की / वैल्यू स्टोर सेशन डेटा का लॉजिकल स्टोरेज लोकेशन है।