अत्यधिक भरी हुई प्रणालियाँ: मुख्य समस्याओं को हल करना

हेलो, हेब्र!

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

सबसे पहले, कुछ आंकड़े। 2009 से प्लेजरियम गेम विकसित कर रहा है। फिलहाल, हमारी परियोजनाओं को सभी सबसे लोकप्रिय सामाजिक नेटवर्क (Vkontakte, My World, Odnoklassniki, Facebook) में लॉन्च किया गया है, कई गेम प्रमुख गेमिंग पोर्टल्स में एकीकृत हैं: games.mail.ru, Kabam। अलग से, "नियम के युद्ध" की रणनीति का एक ब्राउज़र और मोबाइल (आईओएस) संस्करण है। डेटाबेस में 80 मिलियन से अधिक उपयोगकर्ता (5 गेम, 7 भाषाओं में स्थानीयकरण, प्रति दिन 3 मिलियन अद्वितीय खिलाड़ी) शामिल हैं, परिणामस्वरूप, हमारे सभी सर्वरों को प्रति सेकंड औसतन लगभग 6,500 अनुरोध और प्रति दिन 561 मिलियन अनुरोध प्राप्त होते हैं।

मुकाबला सर्वर पर एक हार्डवेयर प्लेटफॉर्म के रूप में, 4 कोर (x2 HT), 32-64 जीबी रैम, 1-2 टीबी एचडीडी के साथ दो सर्वर सीपीयू मुख्य रूप से उपयोग किए जाते हैं। सर्वर Windows Server 2008 R2 चला रहे हैं। 5 Gbps तक की बैंडविड्थ के साथ सीडीएन के माध्यम से सामग्री वितरित की जाती है।
C # प्रोग्रामिंग भाषा में .NET फ्रेमवर्क 4.5 के तहत विकास है।

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


NoSQL बनाम। संबंधपरक

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

ORM बनाम ADO.NET

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

वितरित लेनदेन बनाम। स्वयं की सुसंगत संगति

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

सोप, डब्ल्यूसीएफ, आदि। बनाम HTTP पर JSON

जब ऑफ़-द-शेल्फ SOAP- शैली समाधान (मानक .NET, WCF, वेब API, आदि वेब सेवाओं) का उपयोग करते हुए, अपर्याप्त लचीलेपन का पता लगाया गया था, तो विभिन्न क्लाइंट प्रौद्योगिकियों के कॉन्फ़िगरेशन और समर्थन के साथ कठिनाइयां पैदा हुईं, और एक अतिरिक्त बुनियादी ढांचा मध्यस्थ दिखाई दिया। डेटा के साथ काम करने के लिए, हमने JSON को HTTP पर भेजने का विकल्प चुना, न केवल इसकी अधिकतम सादगी के कारण, बल्कि इसलिए भी कि इस तरह के प्रोटोकॉल का उपयोग करके समस्याओं का निदान करना और उन्हें ठीक करना बहुत आसान था। इसके अलावा यह सरल संयोजन सबसे व्यापक रूप से ग्राहक प्रौद्योगिकियों को शामिल करता है।

MVC.NET, Spring.NET बनाम नग्न ASP.NET

अपने अनुभव के आधार पर, मैं कह सकता हूं कि MVC.NET, Spring.NET और इसी तरह के फ्रेमवर्क अनावश्यक मध्यवर्ती निर्माण बनाते हैं जो अधिकतम प्रदर्शन को निचोड़ने से रोकते हैं। हमारा समाधान ASP.NET द्वारा प्रदान की जाने वाली सबसे बुनियादी सुविधाओं पर बनाया गया है। वास्तव में, प्रवेश बिंदु कुछ सामान्य हैंडलर हैं। हम एक भी मानक मॉड्यूल का उपयोग नहीं करते हैं; आवेदन में एक भी सक्रिय ASP.NET सत्र नहीं है। सब कुछ स्पष्ट और सरल है।

साइकिल के बारे में थोड़ा

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

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

इसलिए, हमने स्वतंत्र रूप से हमारे डेटा की बारीकियों को ध्यान में रखते हुए क्रमबद्धता लिखी। उसी समय, परीक्षणों पर, परिणामी समाधान JSON.Net की तुलना में 10 गुना तेज और FastJSON से 3 गुना तेज निकला।

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

स्मृति

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

मेमोरी के साथ काम करते समय, हम अलग-अलग उम्र बढ़ने और अद्यतन नीतियों के साथ विभिन्न आकारों के कई कैश का उपयोग करते हैं, जबकि कुछ कैश का डिज़ाइन बिना किसी तामझाम के बेहद सरल है। नतीजतन, सभी कैश के लिए दक्षता सूचक 90-95% से कम नहीं है।

मेमकेच्ड परीक्षण करने के बाद, हमने इसे भविष्य के लिए स्थगित करने का फैसला किया, जैसा कि इसकी अभी कोई जरूरत नहीं है। सामान्य तौर पर, परिणाम खराब नहीं थे, लेकिन समग्र प्रदर्शन लाभ कैश में डेटा रखने पर अतिरिक्त क्रमांकन / डीरिएरलाइजेशन की लागत से अधिक नहीं था।

अतिरिक्त उपकरण

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



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



सकारात्मक पहलुओं में से:

- काउंटर हमेशा चालू रहते हैं;
- न्यूनतम लागत (सीपीयू द्वारा उपयोग किए जाने वाले संसाधन का 0.5% से कम);
- profiled वर्गों की पहचान के लिए एक सरल और लचीला दृष्टिकोण;
- प्रवेश बिंदु (नेटवर्क अनुरोध, विधियों) के लिए काउंटरों की स्वचालित पीढ़ी;
- माता-पिता - बच्चे के आधार पर देखने और एकत्र करने की क्षमता;
- आप न केवल वास्तविक समय के डेटा का मूल्यांकन कर सकते हैं, बल्कि आगे देखने और विश्लेषण की संभावना के साथ समय के साथ मीटर के माप के मूल्यों को भी बचा सकते हैं।

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

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

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

निष्कर्ष

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