बड़ी वेबसाइटें जो पूरी तरह से स्टेटलेस नहीं हो सकती हैं, वेब स्तरीय पर अत्यधिक स्केलेबिलिटी प्राप्त करती हैं?लोड बैलेंसर बाधा को रोकने के लिए वेब स्तरीय शेर्डिंग (एसआईसी!)?
ईबे और अमेज़ॅन जैसी साइटें हैं, जो पूरी तरह से स्टेटलेस नहीं हो सकती हैं, क्योंकि उनके पास शॉपिंग कार्ट या ऐसा कुछ है। शॉपिंग कार्ट में प्रत्येक आइटम को यूआरएल में एन्कोड करना संभव नहीं है, न ही प्रत्येक आइटम को कुकी में एन्कोड करना और इसे हर कनेक्शन पर भेजना संभव है। तो अमेज़ॅन बस सत्र-आईडी को कुकी में संग्रहीत करता है जिसे भेजा जा रहा है। इसलिए मैं समझता हूं कि ईबे और अमेज़ॅन के वेब स्तर की स्केलेबिलिटी Google सर्च इंजन की स्केलेबिलिटी से कहीं अधिक कठिन होनी चाहिए, जहां सब कुछ यूआरएल में आराम से एन्कोड किया जा सकता है।
दूसरी ओर, ईबे के साथ-साथ अमेज़ॅन दोनों बड़े पैमाने पर स्केल किए गए। अफवाह यह है कि eBay पर कुछ 15000 जे 2 ईई एप्लीकेशन सर्वर हैं।
ये साइटें दोनों कैसे संभालती हैं: चरम मापनीयता और स्थिति? चूंकि साइट राज्यपूर्ण है, इसलिए एक सरल DNS-Balancing करना संभव नहीं है। तो कोई यह मान लेगा कि इन कंपनियों के पास हार्डवेयर आधारित लोड बैलेंसर है जैसे बिगिप, नेटस्केकर या ऐसा कुछ, जो उस साइट के एकल आईपी पते के पीछे एकमात्र डिवाइस है। यह लोड बैलेंसर एसएसएल (यदि एन्कोड किया गया है) को डिक्रिप्ट करेगा, कुकी का निरीक्षण करेगा और उस कुकी के सत्र आईडी के आधार पर निर्णय लेगा कि एप्लिकेशन सर्वर उस ग्राहक का सत्र रखता है।
लेकिन यह संभवतः काम नहीं कर सकता क्योंकि कोई भी लोड-बैलेंसर संभवतः हजारों एप्लिकेशन सर्वरों के भार को संभालने में सक्षम नहीं हो सकता है? मैं कल्पना करता हूं कि इन हार्डवेयर लोड बैलेंसर्स भी इस स्तर पर स्केल नहीं करते हैं।
इसके अलावा, लोड-बैलेंसिंग उपयोगकर्ता के लिए पारदर्शी रूप से किया जा रहा है, यानी उपयोगकर्ताओं को अलग-अलग पते पर अग्रेषित नहीं किया जाता है, लेकिन फिर भी सभी सामूहिक रूप से पूरे समय www.amazon.com पर रहते हैं।
तो मेरा सवाल यह है: क्या कोई विशेष चाल है जिसके साथ कोई वेब स्तरीय पारदर्शी शेरिंग (डेटाबेस स्तर सामान्य रूप से नहीं किया जाता) जैसे कुछ हासिल कर सकता है? जब तक कुकी का निरीक्षण नहीं किया जाता है तब तक यह जानने का कोई तरीका नहीं है कि कौन सा एप्लिकेशन सर्वर इस सत्र में है।
संपादित करें: मुझे एहसास हुआ कि साइट पर स्पाइडर और बुकमार्क किए जाने की आवश्यकता होने पर पारदर्शिता की केवल आवश्यकता है। जैसे यदि साइट एक मात्र वेब ऐप है, तो विमान या ट्रेन टिकट आरक्षण प्रणाली की तरह कुछ, उपयोगकर्ताओं को विभिन्न यूआरएल के पीछे वेब सर्वर के विशिष्ट क्लस्टर को रीडायरेक्ट करने में कोई समस्या नहीं होनी चाहिए, उदा। a17.ticketreservation.com। इस विशिष्ट मामले में, एप्लिकेशन सर्वर के एकाधिक क्लस्टर का उपयोग करना संभव होगा, प्रत्येक अपने लोड बैलेंसर के पीछे। दिलचस्प बात यह है कि मुझे ऐसी साइट नहीं मिली जो इस तरह की अवधारणा का उपयोग करती है। संपादित करें: मैं इस अवधारणा discussedhighscalability.com पर जहां चर्चा लेई झू ने एक लेख को संदर्भित करता पाया, "Client Side Load Balancing for Web 2.0 Applications" नाम दिया है। लेई झू पारदर्शी रूप से इस क्लाइंट साइड लोड संतुलन को करने के लिए क्रॉस स्क्रिप्टिंग का उपयोग करता है।
यहां तक कि अगर बुकमार्किंग, xss, आदि जैसे दोष हैं, तो मुझे लगता है कि यह कुछ विशेष स्थितियों, अर्थात् लगभग सामग्री मुक्त वेब अनुप्रयोगों के लिए बेहद अच्छा विचार है, जिन्हें स्पाइडर या बुकमार्क करने की आवश्यकता नहीं है (जैसे टिकट आरक्षण प्रणाली या ऐसा कुछ)। फिर लोड संतुलन पारदर्शी रूप से करने की कोई आवश्यकता नहीं है।
मुख्य साइट से सर्वर पर एक साधारण रीडायरेक्ट हो सकता है, उदा। www.ticketreservation.com से एक17.ticketreservation.com पर एक रीडायरेक्ट। वहां से उपयोगकर्ता सर्वर पर रहता है a17। a17 एक सर्वर नहीं है, लेकिन एक क्लस्टर स्वयं है, जिसके द्वारा अनावश्यकता प्राप्त की जा सकती है।
प्रारंभिक रीडायरेक्ट सर्वर लोड लोडर के पीछे स्वयं क्लस्टर हो सकता है। इस तरह, वास्तव में उच्च स्केलेबिलिटी हासिल की जा सकती है, क्योंकि www के पीछे प्राथमिक लोड बैलेंसर केवल प्रत्येक सत्र की शुरुआत में ही मारा जाता है।
बेशक, अलग URL पर ले जाते बेहद बुरा है, लेकिन मात्र वेब अनुप्रयोगों के साथ (जो की जरूरत नहीं है spidered जा करने के लिए, गहरे जुड़ा हुआ या गहरे बुकमार्क किए गए वैसे भी), यह उपयोगकर्ता के लिए केवल एक ऑप्टिकल समस्या नहीं होनी चाहिए ?
रीडायरेक्ट-क्लस्टर एप्लिकेशन क्लस्टर के भार को मतदान कर सकता है और तदनुसार रीडायरेक्ट को अनुकूलित कर सकता है, इस प्रकार संतुलन प्राप्त कर रहा है और न केवल लोड वितरण।
स्टेटलेस वेब सर्वर सही ऐप सर्वर कैसे ढूंढते हैं? क्या हर वेब सर्वर को प्रत्येक सत्र के बारे में किसी भी ऐप सर्वर के बारे में पता होना चाहिए? यह भयानक संचार ओवरहेड नहीं होगा? – SAL9000
भार बैलेंसर्स आपके सत्र आईडी का उपयोग करते हैं या ऐप सर्वर चुनने के लिए इनपुट के रूप में आपके आईपी पते को संभव बनाते हैं। यदि प्रत्येक लोड बैलेंसर में ऐप सर्वर चुनने के लिए एक ही एल्गोरिदम होता है तो इससे कोई फर्क नहीं पड़ता कि आप किस लोडबैंसर पर जाते हैं, आपको हमेशा एक ही ऐप सर्वर पर भेजा जाएगा। ऐप सर्वर और लोड बैलेंसर के बीच कोई संचार शामिल नहीं है। –