मेरा मानना है कि यह MMO की एक सामान्य आवश्यकता है कि लोड को कम करने के लिए एक ही शार्क या दायरे के लिए कई सर्वरों पर प्रसंस्करण किया जा सकता है। मैं उत्सुक हूं कि एक एकीकृत सुसंगत दुनिया को बनाए रखने के लिए यह कैसे किया जा सकता है जहां सभी खिलाड़ी, और सभी एनपीसी बातचीत कर सकते हैं।
मेरा सवाल यह है कि कैसे लोडिंग संतुलन MMOs में हासिल किया है?
इस विषय पर मेरे ज्ञान को बेहतर बनाने के बारे में कोई भी लिंक, किताबें या सामान्य जानकारी की भी सराहना की जाती है।
जवाबों:
इसे यथासंभव सरल रखने की कोशिश करें और अच्छी तरह से परिभाषित और प्रलेखित इंटरफेस। उत्पादन में एक जटिल प्रणाली को बनाए रखना और डिबग करना आसानी से नरक में बदल जाता है। इसलिए यदि एक सरल और एक जटिल दृष्टिकोण है, तो जटिल एक के साथ जाने से पहले दो बार सोचें।
मुझे लगता है कि सेवाओं और उनके आश्रितों की पहचान करने के लिए पहला कदम है : स्टेटिक कंटेंट, ऑथेंटिकेशन, लोकल चैट, ग्लोबल चैट चैनल्स, रीजनल चैट चैनल्स, फ्रेंड्स लिस्ट, गिल्ड्स, बैग / इन्वेंटरी, ऑक्शन हाउस, ग्लोबल मैप, वर्ल्ड, ...
फिर इन सेवाओं में से प्रत्येक के लिए अगर ग्राहक उनसे सीधे बात कर सकते हैं। उदाहरण के लिए क्लाइंट को ग्लोबल चैट चैनल के लिए जिम्मेदार सर्वर से सीधे बात करने देना बहुत आसान है। विश्व सर्वरों को चैट संदेशों में शामिल नहीं होना है। रीजनल चैट को उसी तरह से लागू किया जा सकता है, लेकिन खिलाड़ियों के रीजन बदलने पर दुनिया के सर्वर को चैट सर्वर को बताना होगा। फिर, उन्हें संदेशों की परवाह नहीं है।
तीसरा कदम एक सेवा के भीतर लोड संतुलन के बारे में सोचना है । उदाहरण के लिए वैश्विक और क्षेत्रीय चैट चैनलों को उनके नाम के आधार पर कई सर्वरों में विभाजित किया जा सकता है। यह शायद एक अच्छा विचार है कि इस कोड को क्लाइंट में विभाजित न करें, लेकिन एक लुकअप सेवा प्रदान करें।
सबसे कठिन हिस्सा आमतौर पर दुनिया के सर्वर हैं , इसलिए मैं एक सरल दृष्टिकोण के साथ शुरुआत कर रहा हूं। संभवतः यह एक अच्छा विचार है कि ग्राहक जिस क्षेत्र में है उसके लिए जिम्मेदार सर्वर से सीधे बात करें। इसलिए लॉगिन या रीजन पार करने पर क्लाइंट को यह बताना होगा कि किस सर्वर से कनेक्ट होना है।
सरल दृष्टिकोण दुनिया को स्वतंत्र क्षेत्रों में विभाजित करना है । स्वतंत्र क्षेत्रों के साथ मेरा मतलब है कि एक खिलाड़ी एक भाग से दूसरे भाग में नहीं देख सकता है और राक्षस भागों को पार नहीं कर सकते हैं। वे क्षेत्र उस क्षेत्र के खिलाड़ी से भिन्न होते हैं जो बाहरी दुनिया के परिदृश्य और कहानी के आधार पर देखते हैं। आमतौर पर अधिकांश राक्षस काल कोठरी में होते हैं और खिलाड़ी स्वीकार करते हैं कि उन्हें एक तहखाने में प्रवेश करने के लिए प्रवेश द्वार से गुजरना पड़ता है। खासतौर पर अगर उन डंगऑन का प्रति खिलाड़ी समूह के आधार पर त्वरित किया जाए। बाहर की दुनिया के अन्य उदाहरण विभिन्न महाद्वीप और घाटियाँ हैं जो ऊंचे पहाड़ों से घिरे हैं।
एक निरंतर विश्व दृष्टिकोण वास्तव में जल्दी से जटिल हो जाता है, इसलिए इसे अच्छी तरह से योजना बनाने के लिए समझ में आता है: ग्राहक को क्या जानकारी चाहिए? सर्वर को कौन सी जानकारी साझा करनी है? खिलाड़ी ज्यादातर वस्तुओं (राक्षसों और एनपीसी सहित) के साथ एक ही क्षेत्र में बातचीत करेगा। आप ज़ोन सीमा से ऑब्जेक्ट्स को क्लिक सीमा से बाहर रखकर धोखा दे सकते हैं। इसका मतलब यह है कि ग्राहक ज्यादातर पड़ोसी क्षेत्रों के लिए केवल जानकारी को पढ़ने में रुचि रखते हैं। इन मामलों के लिए ज़ोन सर्वर को अनुमति जाँच के अलावा कुछ भी समन्वय नहीं करना पड़ता है कि खिलाड़ी पड़ोसी क्षेत्र से जुड़ने के लिए पर्याप्त है।
यह केवल बहुत कम संख्या में कठिन मामले छोड़ता है जिसमें वस्तुओं या कार्यों को एक सर्वर सीमा को पार करना पड़ता है। जो एक अच्छी बात है क्योंकि उन मामलों जैसे कि तीर और मंत्र प्रदर्शन महत्वपूर्ण हैं। आक्रमण और बचाव में लड़ाई को विभाजित करने के लिए यह एक अच्छा विचार हो सकता है। तो एक स्पेल-कॉस्टर का सर्वर, कॉस्टर की स्थिति सहित हमले के मापदंडों को परिभाषित करेगा। डिफेंडर का सर्वर हमले के बारे में संदेश प्राप्त करेगा और प्रभाव की गणना करेगा। हमलावर के सर्वर को प्रभाव के बारे में जानने की आवश्यकता नहीं है; ग्राहक अपने रीड ओनली कनेक्शन का उपयोग करके इसके बारे में जानेंगे।
आपका खिलाड़ी मॉडल कितना जटिल है, इसके आधार पर इसे दूसरे सर्वर पर स्थानांतरित करने में कुछ सेकंड लग सकते हैं (सेकंड लाइफ में इसके साथ बहुत बड़ी समस्या है)। जब खिलाड़ी एक आभासी सीमा के करीब हो जाता है, तो स्थानांतरण को अग्रिम रूप से तैयार करके समस्या को कम किया जा सकता है । ताकि वास्तविक हैंडओवर होने पर अधिकांश खिलाड़ी डेटा गंतव्य सर्वर पर पहले से ही कैश हो जाए।
अलग-अलग सेवाओं को परिभाषित करके समस्या को विभाजित करें जो कि थोड़ा निर्भरता वाले सर्वरों में विभाजित हो सकते हैं। अगले चरण में देखें कि महत्वपूर्ण सेवाओं के भीतर भार संतुलन कैसे किया जाए। प्रतिनिधि को संबंधित सर्वर से सीधे कनेक्ट करने का निर्देश देकर काम को संतुलित करने का काम करें (जाहिर है कि सर्वर को अनुमतियों की जांच करनी होगी)। इसे यथासंभव सरल रखें, विभिन्न सेवाओं और सर्वरों की जिम्मेदारियों को अच्छी तरह से दस्तावेज करें, डिबग आउटपुट को सक्षम करने का विकल्प प्रदान करें।
पुनश्च: विश्वसनीयता को बेहतर बनाने के लिए इनमें से कुछ तकनीकों का उपयोग किया जा सकता है। और आपको इसे ध्यान में रखना चाहिए क्योंकि कई सर्वरों का उपयोग करने से चीजों के टूटने का बहुत अधिक खतरा होता है; न केवल सॉफ्टवेयर में, बल्कि हार्डवेयर स्तर पर भी।
आम तौर पर दुनिया को कई छोटे क्षेत्रों में विभाजित किया जाता है। इन क्षेत्रों में से प्रत्येक आमतौर पर एक स्वतंत्र सर्वर प्रक्रिया (वाह की दुनिया के सर्वर या ईव के सोल नोड्स) हैं और कई मशीनों में से किसी पर भी चल सकते हैं। कुछ खेलों में नक्शों (ईव, एसटीओ, गिल्ड वार्स) के बीच स्पष्ट दरवाजे होते हैं, जबकि अन्य इसे अधिक (WAR, Free Realms) मास्क करने की कोशिश करते हैं। जो लोग अधिक सहज दृष्टिकोण का विकल्प चुनते हैं, वे आम तौर पर यह पता लगाते हैं कि जब आप दो सर्वरों के बीच की सीमा के पास होते हैं और दो प्रक्रिया एक हैंडऑफ़ के लिए बातचीत करती है। संभवतः इस बात का वर्णन करने के लिए सबसे अच्छी जगह यह है कि सेल टावरों में घूमने वाले हैंडसेट का उपयोग कैसे किया जाता है। यदि एकल मानचित्र (Jita, Ironforge, Earth Space Dock) का भार वास्तव में बड़ा हो जाता है, तो आप कभी-कभी व्यक्तिगत कार्यों को अन्य सर्वर (AI,) में लोड कर सकते हैं। खिलाड़ी प्रबंधन के कुछ हिस्से) लेकिन इसे या तो शुरू से ही निर्मित किया जाना चाहिए या कुछ गंभीर रेट्रोफिटिंग करना होगा। यह सिर्फ उन मानचित्रों को समर्पित करने के लिए बेहतर हार्डवेयर खरीदने के लिए लगभग हमेशा अधिक लागत प्रभावी है।
मेरा मानना है कि यह MMO की एक सामान्य आवश्यकता है कि लोड को कम करने के लिए एक ही शार्क या दायरे के लिए कई सर्वरों पर प्रसंस्करण किया जा सकता है। मैं उत्सुक हूं कि एक एकीकृत सुसंगत दुनिया को बनाए रखने के लिए यह कैसे किया जा सकता है जहां सभी खिलाड़ी, और सभी एनपीसी बातचीत कर सकते हैं।
यह शायद उतना सामान्य नहीं है जितना आप सोचते हैं; कम से कम, नहीं तो आप सोच रहे हैं कि एक सहज दुनिया एक साथ कई सर्वरों द्वारा प्रबंधित की जाती है।
पूरी तरह से अलग-अलग शार्क की गिनती नहीं, 2 दिशाएं हैं जिनमें आप एक ऑनलाइन गेम को विभाजित कर सकते हैं, जिसे "क्षैतिज" और "ऊर्ध्वाधर" माना जा सकता है:
जाहिर है ये दृष्टिकोण ऑर्थोगोनल हैं और आप दोनों को जोड़ सकते हैं। वास्तव में यह एक अलग डेटाबेस सर्वर के लिए अनिवार्य है, गेमप्ले से एक अलग मशीन पर लॉग इन / ऑउटफिट को पुश करने के लिए बहुत आम है, और चैट और अन्य गैर-महत्वपूर्ण संचार के साथ-साथ खेती करने के लिए तेजी से आम है, भले ही आपका गेम वर्ल्ड कोई भी हो विभाजित है।
लेकिन कुल मिलाकर, जब भौगोलिक विभाजन होता है, तो अधिकांश गेम आपको उन सीमाओं के बीच बातचीत करने देने से बचते हैं, क्योंकि यह अच्छा करना मुश्किल है। इसके बजाय, वे इसे बनाने के अन्य तरीकों का सहारा लेते हैं, ऐसा लगता है जैसे आप अभी भी एक ही शार्क और एक ही सर्वर पर हैं, जब वास्तव में आप नहीं हैं। जैसे। - लोडिंग स्क्रीन या अन्य एनिमेशन जो एक सर्वर को कवर करते हैं, जो ज़ोन और एक महाद्वीप से दूसरे महाद्वीप के बीच संक्रमण करते हैं। - अलग कालकोठरी या छापे उदाहरण जो हर किसी से अलग हो जाते हैं। ये एक शार्प के भीतर एक शार्क की तरह हैं और लोड बैलेंसिंग की मदद से आसानी से एक अलग सर्वर पर चलाए जा सकते हैं।
मैं वाह पर अधिकार के साथ बात नहीं कर सकता, लेकिन मुझे लगता है कि वे ऊपर के लगभग सभी काम कर रहे हैं: उदाहरण, अलग भौगोलिक क्षेत्र जो कि किसी प्रकार के पोर्टल्स, अलग बैक एंड और पोर्ट सर्वर द्वारा शामिल नहीं हो सकते हैं। मैंने सुना है कि WoW realms में एक बार में दिए गए दायरे में 1000 और 10000 खिलाड़ियों के बीच कुछ होता है, जो उपरोक्त योजनाओं के साथ आसानी से प्रबंधनीय है।
लेकिन, मान लेते हैं कि आपके पास एक बहुत बड़ी दुनिया है और आपको खिलाड़ियों को एक एक सर्वर से सटे सर्वर पर बातचीत करने की अनुमति देने की आवश्यकता है। यह सिद्धांत में करना आसान है - पहले, सर्वर को सीमाओं के साथ वस्तुओं का विवरण साझा करने के लिए सहयोग करना चाहिए (इसलिए एक सर्वर पर किसी वस्तु का दूसरे पर एक प्रॉक्सी प्रतिनिधित्व हो सकता है), और फिर बस अपने सभी तर्क को संदेश-पास करने के लिए बदल दें, संदेशों को प्रॉक्सी से वापस आधिकारिक स्रोत पर भेजा जा रहा है जहाँ आवश्यक हो। संदेशों को सर्वर के बीच या सर्वर के भीतर काफी पारदर्शी तरीके से पारित किया जा सकता है ताकि एक दृष्टिकोण सभी प्रणालियों के अनुकूल हो।
यहां समस्या यह है कि पहले सरल तर्क संदेशों के लिए अनुवादित होने पर बहुत जटिल हो सकते हैं - जैसे। 2 खिलाड़ी का व्यापार जो सुरक्षित रूप से और परमाणु रूप से हो सकता है जब दोनों खिलाड़ी एक सर्वर पर होते हैं, एक लंबी प्रक्रिया बन जाती है जब संदेशों को आगे और पीछे भेजना पड़ता है, प्रत्येक भेजने पर श्रद्धेय, और सुरक्षा सुनिश्चित करने के लिए कि एक खिलाड़ी शोषण नहीं कर सकता है। एक संदेश यात्रा करते समय व्यापार को बदलकर। आप यह भी नहीं मान सकते कि संदेश आने तक अन्य खिलाड़ी अभी भी मौजूद रहेंगे (जैसा कि वे मर सकते हैं, लॉग आउट कर सकते हैं, आदि), इसलिए कोड बहुत जटिल हो जाता है। और यह लगभग किसी भी प्रणाली पर लागू होगा जहां 2 या अधिक संस्थाएं बातचीत कर सकती हैं या सहयोग कर सकती हैं - व्यापार, मुकाबला, समूहन, नीलामी, लूट-साझाकरण, प्रशिक्षण, आदि।
ये समस्याएँ असाध्य नहीं हैं, लेकिन अधिकांश खेलों के लिए वे प्रयास करने के लायक हैं जब आप लोड को अन्य माध्यमों से साझा कर सकते हैं और अपने सभी गेम लॉजिक को एक सर्वर पर रख सकते हैं। तो लगभग सभी वर्तमान खेल उस मार्ग के बजाय नीचे जाते हैं।
एक MMO सर्वर को लोड करने के कई तरीके हैं, क्योंकि संसाधित होने के लिए डेटा की एक विस्तृत श्रृंखला है। मैं प्रक्रिया बिन पेड़ विधि पसंद करता हूं।
एक वैश्विक सर्वर उपयोगकर्ता कनेक्शन को एक प्रक्रिया बिन में भेजता है जो एक साथ कई उपयोगकर्ताओं को संभाल सकता है। प्रक्रिया के डिब्बे सभी जटिल प्रसंस्करण करते हैं और केवल वैश्विक सर्वर पर डेटा के साथ प्रतिक्रिया करते हैं जो वैश्विक रूप से प्रासंगिक है जैसे कि वैश्विक चैट और स्थिति। यह विधि क्षेत्र के सर्वरों की तुलना में बहुत बेहतर है, क्योंकि क्षेत्र जनसंख्या में बहुत भिन्न हो सकते हैं, जबकि समग्र उपयोगकर्ता प्रसंस्करण पर्याप्त रूप से भिन्न है कि यह स्वाभाविक रूप से अधिकांश भाग के लिए खुद को संतुलित करना चाहिए।
बस ग्लोबल सर्वर के माध्यम से कुछ बेसिक लोड बैलेंसिंग करें ताकि जब एक प्रोसेस बिन एक निश्चित मेमोरी / सीपीयू उपयोग तक पहुँच जाए, तो आप एक नया प्रोसेस बिन सर्वर स्टार्टअप कर लें।