Skyforge के उदाहरण पर ऑनलाइन गेम सर्वर की वास्तुकला

हेलो, हेब्र! मैं एंड्री फ्रॉलोव हूं, जो एक प्रमुख प्रोग्रामर है, नेक्स्ट-जनरल MMORPG स्काईफोर्ज पर Mail.Ru में काम कर रहा है। आप ऑनलाइन खेल में डेटाबेस की वास्तुकला पर मेरा लेख पढ़ सकते हैं। आज मैं Skyforge सर्वर डिवाइस के बारे में रहस्य प्रकट करूंगा। मैं उदाहरणों के साथ यथासंभव विस्तृत रूप से बताने की कोशिश करूंगा, और यह भी बताऊंगा कि यह या उस वास्तु का निर्णय क्यों किया गया। अतिशयोक्ति के बिना, हम अपने सर्वर पर एक पूरी किताब लिख सकते हैं, इसलिए लेख में जाने के लिए, मुझे केवल मुख्य बिंदुओं से गुजरना होगा।

सिंहावलोकन

• एक सर्वर जावा कोड की लगभग दो मिलियन लाइनें है। C ++ में लिखे क्लाइंट का उपयोग सर्वर से कनेक्ट करने और एक सुंदर चित्र प्रदर्शित करने के लिए किया जाता है।
• पचास प्रोग्रामर ने सर्वर कोड में योगदान दिया। कोड को कई वर्षों तक रूसी "रूढ़िवादी" gamedev के सर्वश्रेष्ठ विशेषज्ञों द्वारा लिखा गया है। इसमें दुनिया भर के सभी सफल विचार शामिल हैं।
• फिलहाल, हमने 5200 स्वचालित परीक्षणों के बारे में लिखा है, बॉट्स का उपयोग करके निरंतर एकीकरण और लोड परीक्षण स्थापित किया है।
• सर्वर दर्जनों और सैकड़ों सर्वर पर शुरू और चला सकता है, एक ही समय में सैकड़ों हजारों लोगों के खेल का समर्थन करता है। हमने MMO के लिए पारंपरिक शार्किंग तकनीक को छोड़ने और सभी खिलाड़ियों को एक बड़ी दुनिया में लॉन्च करने का फैसला किया।

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

सेवा वास्तुकला

विकास की मुख्य विशेषताओं में से एक यह है कि हमें पता नहीं है कि हमारे पास कितने खिलाड़ी होंगे। हो सकता है कि केवल एक ही है - डेवलपर खुद, या शायद एक ही समय में 100,000। इसलिए, सर्वर को एक छोटे कॉन्फ़िगरेशन में, लैपटॉप पर, और खिंचाव, यदि आवश्यक हो, तो दसियों और सैकड़ों शक्तिशाली सर्वरों को चलाने में सक्षम होना चाहिए।



दूसरी विशेषता यह है कि विकास की शुरुआत में, हमें नहीं पता था कि हमारा खेल क्या होगा, इसमें क्या विशेषताएं होंगी, सेवाएं आदि। नई सेवाओं और सुविधाओं को जोड़ने के मामले में सर्वर संरचना यथासंभव लचीली होनी चाहिए।



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



यहां से हमारी सार्वभौमिक सर्वर संरचना का जन्म हुआ, जिसका उपयोग स्काईफोर में किया जाता है:

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

इस प्रकार, हम "स्थानीय सर्वर" की भूमिका लॉन्च कर सकते हैं, जहां सब कुछ आवश्यक होगा, और हम सर्वर को कई दसियों भूमिकाओं में तोड़ सकते हैं - खाता सर्वर, आइटम सर्वर, गेम मैकेनिक्स, आदि। - और इसे दर्जनों विभिन्न भौतिक सर्वरों पर चलाएं। संरचना बेहद लचीली और आरामदायक निकली, मैं आपको इसे गंभीरता से देखने की सलाह देता हूं।

मुख्य सेवाएँ

सेवाओं का एक निश्चित सेट है जो मुख्य गेम लोड करता है। प्रत्येक सर्वर को स्केल करने में सक्षम होना चाहिए। आदर्श रूप से - to infinity। दुर्भाग्य से, बड़े पैमाने पर सर्वर लिखना एक आसान काम नहीं है। इसलिए, हमने मुख्य सेवाओं को स्केलेबल बनाकर शुरू किया, और बाद में मुख्य भार नहीं उठाने वाले किसी भी अतिरिक्त विवरण को छोड़ दिया। यदि हमारे पास बहुत सारे उपयोगकर्ता हैं, तो हमें स्केलेबिलिटी प्रदान करने के लिए उन्हें सुधारना होगा।

• खाता सेवा। नए ग्राहकों के प्राधिकरण और कनेक्शन के लिए जिम्मेदार।
• खेल यांत्रिकी सर्वर। यहाँ, वास्तव में, खेल ही जगह लेता है। प्राधिकरण के बाद, ग्राहक यहां से जुड़ता है और यहां खेलता है। ग्राहक अन्य सेवाओं के साथ सीधे बातचीत नहीं करता है। ऐसी सेवाओं को कई दर्जनों, या सैकड़ों भी लॉन्च किए जा सकते हैं। ये सेवाएं मुख्य बोझ हैं।
• डेटाबेस सेवाएँ ये सेवाएं गेम के पात्रों, उनकी वस्तुओं, धन, विकास प्रगति के डेटा पर संचालन करती हैं। वे आमतौर पर कुछ टुकड़े चलाते हैं। आप मेरी पिछली रिपोर्ट में डेटाबेस आर्किटेक्चर के बारे में अधिक पढ़ सकते हैं। ( habrahabr.ru/company/mailru/blog/182088 )
• चैट करें। उपयोगकर्ताओं के बीच चैट संदेशों को रूट करने में लगे हुए हैं।
• अन्य सभी सेवाएं। उनमें से कई दर्जन हैं, और वे आमतौर पर एक भारी भार नहीं बनाते हैं, और इसलिए अलग सर्वर की आवश्यकता नहीं होती है।

नेटवर्क

"नेटवर्क" शब्द से मेरा अभिप्राय एक सेवा से दूसरी सेवा या एक वस्तु से दूसरी वस्तु तक संदेश पहुंचाने की प्रणाली से है। ऐतिहासिक रूप से, हमारे पास एक साथ दो ऐसी प्रणालियाँ हैं। एक संदेश पर आधारित है। दूसरी प्रणाली दूरस्थ प्रक्रिया कॉल (RPC) पर आधारित है। Skyforge में, एक संदेश प्रणाली का उपयोग गेम मैकेनिक्स सेवा के अंदर एक अवतार से एक भीड़ को संदेश भेजने के लिए किया जाता है, साथ ही साथ क्लाइंट और सर्वर संचार के लिए भी। RPC का उपयोग सेवाओं के बीच संचार के लिए किया जाता है।

संदेशों

सभी ऑब्जेक्ट जो संदेश भेजना या प्राप्त करना चाहते हैं, उन्हें ग्राहक कहा जाता है। प्रत्येक ग्राहक एक सामान्य निर्देशिका में पंजीकृत होता है और एक विशिष्ट पहचानकर्ता - एक पता प्राप्त करता है। जो कोई भी किसी भी ग्राहक को संदेश भेजना चाहता है, उसे "और" जहां "पते का संकेत देना चाहिए।" नेटवर्क इंजन जानता है कि ग्राहक कहाँ है और उसे एक संदेश देता है। संदेश एक जावा ऑब्जेक्ट है जिसमें एक रन () विधि है। भेजते समय, यह ऑब्जेक्ट सीरियलाइज्ड हो जाता है, लक्ष्य सब्सक्राइबर के लिए उड़ान भरता है, वहां डिसेरलाइज़ किया जाता है, और फिर रन सब्सक्राइबर को टारगेट पर बुलाया जाता है।











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

आरपीसी

संदेश थ्रेड्स की समस्या को हल करने के लिए दूरस्थ प्रक्रिया कॉल या RPC दिखाई दी।

मुख्य विचार सहकारी मल्टीटास्किंग (कॉरटीन, फाइबर) का उपयोग करना है। किसी ऐसे व्यक्ति के लिए जो इस अवधारणा से परिचित नहीं है, विषय को समझने के लिए, मैं आपको विकिपीडिया को देखने की सलाह देता हूं। en.wikipedia.org/wiki/Coroutine

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











इस प्रकार, हम तर्क को एक विधि में केंद्रित करते हैं, और इसे सैकड़ों संदेशों में नहीं फैलाते हैं। कोड को बहुत सरल किया गया है, यह कुछ वस्तुओं के कॉलिंग फ़ंक्शन के संदर्भ में लिखा जा सकता है, न कि संदेश भेजने के संदर्भ में। लेकिन एक प्रकार की मल्टीथ्रेडिंग के साथ समस्याएं हैं, क्योंकि जब हम रिमोट कॉल से लौटे, तो वातावरण पहले से ही बदल सकता था। सामान्य तौर पर, यह दृष्टिकोण बहुत सुविधाजनक होता है जब सेवा में एक दर्जन विधियों का सीमित इंटरफ़ेस होता है। जब कई तरीके होते हैं, तो इंटरफ़ेस को कई हिस्सों में तोड़ना बेहतर होता है।



आप सर्गेई ज़गुरस्की ( www.youtube.com/watch?v=YWLHELcvNbE ) के एक व्याख्यान से फ़ाइबर के हमारे कार्यान्वयन के बारे में अधिक जान सकते हैं।

क्रमबद्धता

हमारे लिए एक संदेश भेजने की व्यवस्था और दूरस्थ प्रक्रिया कॉल करने के लिए, हमें एक क्लाइंट-सर्वर प्रोटोकॉल और ऑब्जेक्ट्स को क्रमांकित / डीज़ेरिअलाइज़ करने का एक तरीका चाहिए। मुझे आपको याद दिलाना है कि हमें क्लाइंट से सर्वर पर कमांड और डेटा भेजने की आवश्यकता है, अर्थात्। C ++ से Java और इसके विपरीत। ऐसा करने के लिए, हम जावा कक्षाओं के लिए C ++ में उनकी प्रतियां तैयार करते हैं, और वस्तुओं को क्रमबद्ध और बाइट करने के लिए एक बाइट स्ट्रीम में तरीके भी उत्पन्न करते हैं। क्रमबद्धता के लिए कोड सीधे कक्षाओं के अंदर एम्बेडेड होता है और सीधे कक्षा के क्षेत्रों तक पहुंचता है। इस प्रकार, सर्वर प्रतिबिंब का उपयोग करके कक्षाओं को दरकिनार करके सीपीयू समय बर्बाद नहीं करता है। हम यह सब IntelliJ IDEA के लिए एक मालिकाना प्लगइन की मदद से उत्पन्न करते हैं। सेवाओं के बीच संचार के लिए इंट्रा-सर्वर प्रोटोकॉल पूरी तरह से क्लाइंट-सर्वर प्रोटोकॉल के समान है।



जब किसी क्लास को बाइट स्ट्रीम में क्रमबद्ध करते हैं, तो क्लास आईडी को पहले लिखा जाता है, फिर इस क्लास के फील्ड डेटा को। दूसरी तरफ, आईडी को पढ़ा जाता है, इसी वर्ग को चुना जाता है, और एक विशेष निर्माता को इसमें से बुलाया जाता है, जो क्लास को बाइट स्ट्रीम से पुनर्स्थापित करता है।

खेल यांत्रिकी

मुख्य सेवा जो आपके लिए रुचिकर होगी वह है खेल यांत्रिकी सेवा। यह वहाँ है कि खेल से संबंधित सभी कोड को सीधे निष्पादित किया जाता है, यह वहाँ है कि पूरे खेल की दुनिया मॉडलिंग की जाती है, आग के गोले उड़ते हैं और "कोरोवनी को लूटते हैं।"

नक्शे और लोड संतुलन

गेम मैकेनिक्स के सर्वर पर, नक्शे बनाए जाते हैं, जिस पर, वास्तव में, खिलाड़ी, मॉब स्थित होते हैं और सभी मज़ेदार होते हैं। प्रत्येक कार्ड में उन खिलाड़ियों की संख्या की सीमा होती है जो उस पर हो सकते हैं। उदाहरण के लिए, सीमा व्यक्तिगत रोमांच के लिए एक के बराबर हो सकती है, समूह की गतिविधियों के लिए 10-30 और बड़े कार्ड के लिए 250 हो सकती है। यदि कोई अन्य खिलाड़ी कार्ड पर प्राप्त करना चाहता है तो सीमा समाप्त होने पर क्या होता है? फिर उसी कार्ड की एक और कॉपी बनाई जाएगी। इन कार्डों के खिलाड़ी एक-दूसरे को नहीं देखेंगे, एक-दूसरे के साथ हस्तक्षेप नहीं करेंगे। यानी किसी भी खेल शहर में हजारों लोग हो सकते हैं, लेकिन वहां भीड़ नहीं होगी। खिलाड़ियों को संगठित करने के इस तरीके को "चैनल" कहा जाता है।



केंद्रीय सेवा "कार्ड बैलेंसर" कार्ड बनाने के लिए ज़िम्मेदार है, जो गेम मैकेनिक्स की सेवाओं के अनुसार जनसंख्या, भार और अन्य जादुई कारणों के आधार पर कार्ड वितरित करता है, एक समान लोड वितरण और खिलाड़ियों के सामान्य घनत्व को बनाए रखने की कोशिश करता है ताकि वे ऊब न हों।



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

अवतार और भीड़

एक अवतार एक खिलाड़ी द्वारा नियंत्रित चरित्र है, एक भीड़ एक राक्षस है जिसे एक खिलाड़ी मारता है। ये बहुत अलग हैं, लेकिन अक्सर बहुत समान इकाइयां हैं। भीड़ और अवतार दोनों मानचित्र पर चल सकते हैं, उनके पास स्वास्थ्य है, वे मंत्र का उपयोग कर सकते हैं, आदि। केवल अवतार को खिलाड़ी द्वारा नियंत्रित किया जाता है, और भीड़ का अपना मस्तिष्क होता है। इसके अलावा, कार्डों पर सभी प्रकार के चेस्ट, पौधे और अन्य इंटरैक्टिव इकाइयां हैं। बहुत बार आपको कुछ कार्य करने की आवश्यकता होती है और इसे विभिन्न संस्थाओं से जोड़ा जाता है। इन उद्देश्यों के लिए, हम एक घटक दृष्टिकोण का उपयोग करते हैं, कार्यात्मकताओं के एक सेट से गेम इकाई एकत्र करते हैं। मैं एक उदाहरण के साथ समझाऊंगा। मान लीजिए कि एक खिलाड़ी और भीड़ में स्वास्थ्य का सूचक है। इस मामले में, हम "स्वास्थ्य" तत्व को एक अलग जावा वर्ग के रूप में डिज़ाइन करते हैं जिसमें हम वर्णन करते हैं कि स्वास्थ्य कैसे व्यवहार करता है: यह कैसे घट सकता है, कैसे ठीक हो सकता है, वहां क्या टाइमर हैं, आदि। फिर हम बस इकाई के अंदर एक विशेष HashMap में सभी कार्यक्षमता डालते हैं और आवश्यकतानुसार इसे वहां से ले जाते हैं। हमारे पास सैकड़ों ऐसे घटक हैं, जिनमें से आधे खेल यांत्रिकी उन पर इकट्ठे हैं।



चूंकि सर्वर एप्लिकेशन बहुत जटिल है, इसलिए त्रुटियां अपरिहार्य हैं। यह सुनिश्चित करना आवश्यक है कि एक त्रुटि की घटना, यहां तक ​​कि एक अनहेल्ड NullPointerException, सर्वर क्रैश के लिए नेतृत्व नहीं करता है। आप बस त्रुटि को जमा कर सकते हैं और आगे बढ़ सकते हैं, लेकिन यदि त्रुटि अवतार पर कुछ लंबी कार्रवाई के बीच में होती है, तो अवतार टूटी हुई और असंगत स्थिति में हो सकता है। यहां "लोकेल" नामक एक अवधारणा हमारी सहायता के लिए आती है। एक लोकेल एक संदर्भ है जिसके भीतर वस्तुएं एक दूसरे को संदर्भित कर सकती हैं। एक स्थान की वस्तुएँ दूसरे से वस्तुओं का संदर्भ नहीं ले सकती हैं। यदि एक अनजाने अपवाद लोकेल से उड़ जाता है, तो पूरा लोकेल हटा दिया जाता है। अवतार, मॉब और अन्य संस्थाएं स्थान हैं, पूरी तरह से हटा दिए जाते हैं और अन्य अवतार और मॉब से लिंक नहीं रख सकते हैं। इसलिए, अवतार और मॉब के बीच सभी इंटरैक्शन संदेश प्रणाली के माध्यम से जाता है, हालांकि वे एक ही मशीन पर एक साथ स्थित हैं और सिद्धांत रूप में, एक दूसरे से सीधा लिंक पकड़ सकते हैं।

प्रतिकृति

आपको न केवल सर्वर पर, बल्कि आंशिक रूप से क्लाइंट पर गेम की दुनिया का अनुकरण करने की आवश्यकता है। उदाहरण के लिए, एक क्लाइंट को अन्य खिलाड़ियों और मॉब को देखने की जरूरत है जो उसके बगल में हैं। इसके लिए, क्लाइंट-सर्वर प्रतिकृति के तंत्र का उपयोग किया जाता है, जब आसपास के खेल की दुनिया के अपडेट सर्वर से क्लाइंट को भेजे जाते हैं। यह एक कोड जनरेटर का उपयोग करके किया जाता है जो सर्वर-साइड जावा ऑब्जेक्ट्स के सेटर्स में अपडेट भेजने को एम्बेड करता है। एक निश्चित त्रिज्या का एक घेरा खिलाड़ी के चारों ओर बनाया जाता है, और यदि कोई, उदाहरण के लिए, कोई अन्य अवतार, इस घेरे में आता है, तो वह ग्राहक को दोहराने लगता है। प्रतिकृति के साथ एक मूलभूत समस्या है। यदि एन अवतारों को एक स्थान पर भीड़ दी जाती है, तो एन प्रतिकृतियों को उनमें से प्रत्येक को भेजना होगा। इस प्रकार, एक द्विघात निर्भरता उत्पन्न होती है, जो एक स्थान पर इकट्ठा होने वाले अवतार की संख्या को सीमित करती है। यह इस मौलिक विद्रूपता के कारण ठीक है कि सभी आईएमओ के ग्राहक राजधानियों में धीमा हो रहे हैं। हम नक्शे पर खिलाड़ियों की संख्या को सीमित करके और उन्हें पूरे चैनलों में वितरित करके इस समस्या से बचते हैं।

संसाधन प्रणाली

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

कार्रवाई में सर्वर

आइए अब हम कई परिदृश्यों के उदाहरणों को देखते हैं कि यह पूरी प्रणाली कैसे काम करती है।

कुत्ते को मार डालो

क्लासिक परीक्षण जिसे हम हमेशा करते हैं यदि हमने बुनियादी ढांचे को बहुत बदल दिया है और यह जांचना चाहते हैं कि सब कुछ काम करता है "कुत्ते को मार डालो"। आपको क्लाइंट के रूप में सर्वर पर जाने और वहां किसी भी भीड़ को मारने की आवश्यकता है। यह परीक्षण सर्वर के लगभग सभी मुख्य बिंदुओं को कवर करता है और उपरोक्त सभी को एक साथ रखने के लिए एक उत्कृष्ट उदाहरण के रूप में कार्य करता है। आइए अंक देखते हैं, दुर्भाग्यपूर्ण कुत्ते को मारने पर क्या और कैसे होता है। बेशक, कुछ कदम सरल हैं, लेकिन यह समझने के लिए महत्वपूर्ण नहीं है।

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

स्केलिंग

आइए दूसरी तरफ जाएं और देखें कि सर्वर लोड के तहत कैसे व्यवहार करता है।

• 0 ग्राहक। , . , .
• 1 . , , , .
• 500 . 500 , . realm .
• 10000 . 10000 . , realm .
• 100000 . 100000 .
• , . , , , . , , . , realm , . , - - . , .

निष्कर्ष

, , , , .

, .

• Java www.youtube.com/watch?v=YWLHELcvNbE
• Skyforge, – habrahabr.ru/company/mailru/blog/193452 habrahabr.ru/company/mailru/blog/191378
• -. Skyforge habrahabr.ru/company/mailru/blog/182088
• allodsteam.ru/#posts

. sf.mail.ru

. .











, .











PS: , .