बड़े सर्वर कैसे न लिखें

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

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

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

चलो शुद्धतम ("वेनिला") Minecraft सर्वर के साथ शुरू करते हैं, या यों कहें कि यह बिल्कुल भी करता है। ये चीजें सर्वर द्वारा संसाधित होती हैं:

• हिस्सा - जो लोग नहीं जानते हैं, उनके लिए पूरे Minecraft की दुनिया को 16x16 क्यूब्स के क्षेत्र और सेटिंग्स के आधार पर ऊंचाई के साथ टुकड़ों में विभाजित किया गया है। खिलाड़ी दृश्यता सीमा के भीतर सभी विखंडू को सर्वर की मेमोरी में लोड किया जाता है और हाशप में स्थित होता है, प्रत्येक सर्वर टिक होता है, प्रत्येक चंक को संसाधित किया जाता है। इस समय, निम्नलिखित प्रदर्शन किया जाता है: सभी सक्रिय विखंडू (जो खिलाड़ियों से एक निश्चित दायरे के भीतर हैं) को बारी-बारी से चुना जाता है। प्रत्येक चंक के लिए, मौसम को संसाधित किया जाता है (बर्फ डालें, बिजली के साथ मारा जाए), साथ ही ब्लॉकों के यादृच्छिक प्रसंस्करण - पूरे चंक से कई दर्जन यादृच्छिक ब्लॉकों का चयन किया जाता है, यह जाँच की जाती है कि क्या इन ब्लॉकों को अपडेट करने की आवश्यकता है (ब्लॉक प्रकार से) और चयनित ब्लॉक पर एक विशेष कार्य कहा जाता है।
• टाइलें विशेष ब्लॉक हैं जो हर टिक से संसाधित होती हैं, और संयोग से नहीं। इन ब्लॉकों में भट्टियां शामिल हैं (जलती हुई सामग्री की स्थिति को अपडेट करते हुए, शेष ईंधन, यह समान रूप से किया जाना चाहिए, और संयोग से नहीं, अन्य ब्लॉकों के टिक की तरह), स्पॉन मॉब्स भी हैं (ब्लॉक जो उनके चारों ओर मॉब्स को फैलाते हैं), औषधि की तरह और बातें। वे सभी सूची में संग्रहीत किए जाते हैं, जो एक चंक को लोड करते समय या ऑपरेशन के दौरान एक नई टाइल स्थापित करते समय भरा जाता है, और बदले में प्रत्येक चक्र के माध्यम से पुनरावृत्त होता है।
• तत्काल ब्लॉक - बेशक, उन्हें उस तरह से नहीं बुलाया जाता है, लेकिन फिर भी, ये ऐसे ब्लॉक हैं जिन्हें "तत्काल" संसाधित करने की आवश्यकता है, अर्थात अगले चक्र पर या थोड़ी देरी के साथ (चक्र में भी, सब कुछ चक्र में गिना जाता है, यहां तक ​​कि समय भी अल्लाह ), और संयोग से नहीं, क्योंकि यादृच्छिक ब्लॉक औसतन हर कुछ मिनट में एक बार संसाधित होते हैं। उन्हें लगभग टाइल के रूप में संसाधित किया जाता है, केवल उन्हें देरी से संकेत दिया जा सकता है, कितने चक्रों के बाद उन्हें संसाधित करने की आवश्यकता होती है। खिलाड़ी कार्यों या अन्य ब्लॉकों के कारण प्रसंस्करण कार्य आमतौर पर सर्वर संचालन के दौरान उत्पन्न होते हैं। विशेष रूप से, यह है कि रेडस्टोन का इलाज कैसे किया जाता है, जिसे बाहरी परिवर्तनों, आग के ब्लॉक, बहते पानी और इसी तरह से बहुत जल्दी प्रतिक्रिया करनी चाहिए।
• लाइट अपडेट - Minecraft ब्लॉकों में विभाजित स्थिर प्रकाश व्यवस्था का उपयोग करता है। प्रत्येक ब्लॉक का अपना रोशनी स्तर 15 से 0. होता है। जब ब्लॉक बदलते हैं, तो उनकी रोशनी को पुनर्गणना होना चाहिए, एल्गोरिथ्म बहुत जटिल नहीं है, लेकिन पुनरावर्ती है, और दो प्रकार के प्रकाश भी हैं - ब्लॉक (मशाल, आग, आदि) और आकाश से, वे। स्वतंत्र रूप से गणना की जानी चाहिए, अर्थात, प्रत्येक परिवर्तन के लिए दो बार (यदि दुनिया में आकाश है, तो यह नीदरलैंड में नहीं है)।
• इकाई लगभग सभी वस्तुओं की है। भीड़, खिलाड़ी, फर्श पर पड़ी वस्तुएं, गाड़ियां, नावें, पेंटिंग, बिजली, तीर और बहुत कुछ। उन सभी को एक बड़ी सूची में संग्रहीत किया जाता है और टिक () फ़ंक्शन को एक-एक करके उन पर कॉल किया जाता है, इससे पहले कि यह जांचा जाता है कि क्या वे मर गए हैं, अगर उनकी मृत्यु हो गई है, तो उन्हें क्रमशः सूची और सर्वर की मेमोरी से हटा दिया जाता है।
• मॉब स्पॉन भी एक अलग क्रिया है। मॉब्स खिलाड़ी से एक निश्चित दायरे में घूमते हैं, और चंक में एक यादृच्छिक बिंदु का चयन किया जाता है और, विभिन्न दिशाओं में कई बदलावों के आधार पर, यह चुना जाता है कि क्या भीड़ को वहां रखा जा सकता है, और इसे बनाया गया है
• प्लेयर हैंडलिंग - खिलाड़ियों को भेजे जाने वाले सभी पैकेजों को स्पष्ट रूप से नियंत्रित करने की आवश्यकता होती है।
• लोड हो रहा है और चंक्स उत्पन्न करना - यदि एक चंक ब्लॉक को एक्सेस करने का प्रयास किया जाता है जो मेमोरी में नहीं है, तो डिस्क से चंक को लोड किया जाना चाहिए, यदि यह डिस्क पर नहीं है, तो इसे जेनरेट किया जाना चाहिए। यह समझाने की आवश्यकता नहीं है कि एक हार्ड ड्राइव लगभग हमेशा एक अड़चन है। चंक उत्पन्न करना लोड करने से भी अधिक जटिल है।
• चंक सेविंग - सामान्य सर्वर सेविंग के दौरान या बस जब चंक को लंबे समय तक इस्तेमाल नहीं किया जाता है और इसे अनलोड किया जा सकता है, तो चंक्स को डिस्क में सेव करना होगा - एक स्ट्रीम में कनवर्ट किया जाएगा और एक फाइल पर लिखा जाएगा।

ऐसा लगता है कि सब कुछ ठीक है और कुछ भी आपराधिक नहीं है, सब कुछ काफी अच्छी तरह से किया जाता है और जोड़ने के लिए कुछ भी नहीं है। यहां समस्या यह है: यह सब एक मुख्य धागे में संसाधित होता है । हाल के संस्करणों में, Mojang ने बहुस्तरीय चीजों के बारे में थोड़ा पढ़ा और एक अलग स्ट्रीम में डिस्क से चंक्स को बचाने का तरीका सीखा। बेशक, यह एक सफलता है, क्योंकि यह एक अड़चन का नरक था, बहुत समय पहले सर्वर को 15 मिनट के लिए संग्रहीत किया गया था और इस समय यह पूरी तरह से लटका हुआ था, अब कोई नहीं है। हालाँकि, समस्या हल नहीं है।

आप पूछ सकते हैं कि यहाँ क्या समस्या है? इतने सारे करते हैं: एक धागे में आवेदन का मुख्य तर्क, यह प्रोग्राम के लिए बहुत सुविधाजनक है, आपको सिंक्रनाइज़ेशन और समानांतर अनुप्रयोगों की अन्य समस्याओं के बारे में चिंता करने की आवश्यकता नहीं है। यहां समस्या यह है कि यदि सर्वर में मानक 20 चक्रों के बजाय 40 से अधिक लोग हैं, तो यह पहले से ही 15 है, यदि 70 लोग हैं, तो 10, यदि 100 हैं, तो यह अविश्वसनीय मानों के बराबर है। यह इस तथ्य के बावजूद है कि मेरे पास वास्तव में 6-कोर कोर i7 और 64 जीबी की रैम है! और मैं इन संसाधनों को अब कहां रखूं, अगर 12 में से दो प्रवाह पर बल होता है?

मैं बेकार की बात नहीं करूंगा, मैं एक उदाहरण दूंगा:
सर्वर पर 223 खिलाड़ी हैं, और दृश्यता की त्रिज्या को काफी छोटा चुना गया है, इसमें 46577 विखंडू, 524 "अत्यावश्यक" ब्लॉक, 87 रेडस्टोन और पिस्टन ब्लॉक, 11240 एंटिटी आइटम, 4274 एंटिटी जानवर, 19 वर्ग और नावें, 717 अन्य एंटिटी खिलाड़ी हैं। जो इकाई भी हैं और उचित प्रसंस्करण की आवश्यकता है।
मेरा सर्वर जानकारी में टाइल और प्रकाश अपडेट की संख्या प्रदर्शित नहीं करता है (मुझे इसकी आवश्यकता नहीं है), लेकिन आप विश्वास कर सकते हैं कि उनमें से बहुत सारे हैं।

अकेले जानवरों को संसाधित करना एक बहुत कठिन प्रक्रिया है - वे नियमित रूप से एक मार्ग की खोज करते हैं, आसपास के अन्य संस्थाओं की खोज करते हैं, उनके पास एआई (नवीनतम संस्करणों में काफी उन्नत) है, इसलिए 4,000 जानवरों का प्रसंस्करण पहले से ही बहुत काम है।

लगभग 3 मिलियन ब्लॉक प्राप्त करना (लगभग इतने ही रैंड के साथ कई यादृच्छिक ब्लॉक संसाधित किए जाते हैं) भी कोई तुच्छ कार्य नहीं है।

11 हजार वस्तुओं को स्थानांतरित किया जाना चाहिए, कुछ अन्य कार्यों को करना चाहिए, अपडेट खिलाड़ियों को भेजा जाना चाहिए और इसी तरह।

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

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

सौभाग्य से, कुछ प्लगइन डेवलपर्स ने अपने प्लगइन्स के भारी तर्क को एक अलग धागे में खींचने के लिए सीखा है। उज्ज्वल और अच्छे उदाहरण OreObfuscator और Dynmap प्लगइन्स हैं। अनावश्यक डेटा से खिलाड़ी को भेजे गए ब्लॉक को पहले "क्लीन" करता है ताकि खिलाड़ी दीवारों के माध्यम से धोखा न दे सके। यह एक अलग धागे में करता है, पैकेट को एक कतार में रखता है और उन्हें सर्वर लॉजिक से अलग से संसाधित करता है। दूसरा ब्राउजर के लिए एक डायनेमिक मैप तैयार करता है, वह भी बहुत उच्च गुणवत्ता वाला। सामान्य तौर पर, उनकी प्रशंसा करें कि वे मुख्य धारा को और अधिक लोड नहीं करते हैं।

एक प्लगइन भी है जो उन चीजों की संख्या को कम करता है जो सर्वर प्रति चक्र प्रक्रिया करता है। पास में पड़ी वस्तुओं को जोड़ती है, मॉब्स को अनलोड करता है, चंक्स के प्रसंस्करण को सीमित करता है। यह बहुत अच्छा है, कोई भी सर्वर इस प्लगइन के बिना नहीं कर सकता है - NoLagg।

यह कैसे करना सही है (मेरी राय में)
हम यह सब लंबे समय तक झेलते रहे, जब डेढ़ साल पहले हमारा ऑनलाइन 100 लोगों तक बढ़ गया, और गति घटकर 0.5-1 चक्र प्रति सेकंड हो गई। हमने सर्वर ऑप्टिमाइज़ेशन करने की कोशिश की, कोड को ठीक किया, जितना संभव हो उतना हटाने की कोशिश की, कुछ जगहों पर काम चक्र में नहीं बल्कि सेकंड में (उदाहरण के लिए, एक भट्टी में बदल दिया। यह भी बुक्कट में जोड़ा गया था ... कुछ महीनों के बाद)। अंत में, हमने एक भयानक सर्वर अस्थिरता हासिल की और इस सब पर थूकने का फैसला किया।

एकमात्र विकल्प जो हमें ऑनलाइन आरामदायक प्रदान कर सकता था, जैसा कि हम चाहते थे कि एक स्केलेबल सर्वर था। मुझे यह समझाना आवश्यक नहीं है कि किसी प्रक्रिया का प्रवाह मापनीय नहीं है, यह केवल एक समय में एक प्रोसेसर कोर पर काम कर सकता है, और इसका प्रदर्शन कर्नेल के प्रदर्शन द्वारा सीमित है। प्रोसेसर में कोर अब काफी उत्पादक हैं, लेकिन बहुत काम है, और प्रोसेसर अब मल्टी-कोर कर रहे हैं, कुछ मल्टी-थ्रेडेड नहीं करने का समय नहीं है।

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

तो सर्वर का जन्म संभव के रूप में कई धाराओं के आधार पर हुआ था: दुनिया को 64x64 विखंडू के टुकड़ों में विभाजित किया गया है और इस तरह के प्रत्येक टुकड़े को एक धारा में विखंडित किया जाता है, तत्काल खंडों को संसाधित करने के लिए एक धारा, रेडस्टोन और पिस्टन के लिए एक धारा, मॉब के लिए एक धारा, वस्तुओं के लिए एक धारा, गाड़ियों के लिए एक धारा, एक धारा अन्य इकाई और दुनिया के बारे में अन्य जानकारी संसाधित करती है, एक धारा प्रकाश की गणना करती है, दुनिया के विभिन्न हिस्सों में चार धाराएं दुनिया को डिस्क पर सहेजती हैं, एक धारा एक नक्शे को प्रस्तुत करती है, एक धारा सर्वर और कमांड को बनाए रखती है। क्ष कंसोल, अपडेट आँकड़े। खिलाड़ियों के लिए, एक प्रणाली का उपयोग किया जाता है जो पैकेट प्रसंस्करण को प्रत्येक खिलाड़ी के लिए एक अलग थ्रेड पर या थ्रेड पूल पर या प्रत्येक खिलाड़ी के लिए अलग थ्रेड पर सेट करने की अनुमति देता है। एक ही समय में, सब कुछ कई और थ्रेड्स में विभाजित किया जा सकता है: कम से कम 20 अलग-अलग थ्रेड्स में एक ही प्रकार की वस्तुओं को संसाधित करें। मानक I / O के विपरीत नेटवर्क इंजन के रूप में Netty (NIO) के साथ-साथ।

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

इस कल्पित कहानी का नैतिक यह है: यदि आप उम्मीद करते हैं कि आपकी परियोजना कम से कम किसी तरह लोकप्रिय होगी और यह सोचें कि यह कम से कम सैद्धांतिक रूप से संभव है कि सर्वर पर कम से कम बहुत सारे लोग होंगे ... एक स्केलेबल आर्किटेक्चर बनाने में कंजूसी न करें।

मैं आपके सड़े हुए टमाटरों के लिए तत्पर हूं, इस लेख को बेहतर बनाने के लिए सुझाव, साथ ही अगले लेख में आप जो देखना चाहते हैं, उसके लिए सुझाव।

विचारों की धारा में वर्तनी की त्रुटियाँ हो सकती हैं, जैसे यह एक सांस में लिखा गया था।