स्केलिंग आसान है। भाग तीन - रणनीतियाँ

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

स्थानीय अनुकूलन की क्षमता बहुत सीमित है।

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

प्रदर्शन केवल स्केलिंग पर काम करने का एकमात्र कारण नहीं है। बहुत हद तक एक प्रणाली की उपलब्धता इस बात पर भी निर्भर करती है कि हम समानांतर में प्रत्येक घटक के कई उदाहरण चला सकते हैं या नहीं, इसके लिए धन्यवाद, सिस्टम के किसी भी हिस्से का नुकसान उठाने में सक्षम हो सकता है। स्केलिंग की शीर्ष पूर्णता प्रणाली को लचीले ढंग से प्रबंधित करने में सक्षम है, अर्थात, यातायात के लिए संसाधनों के उपयोग को समायोजित करने के लिए।

प्रस्तुति परत को स्केल करना आमतौर पर आसान होता है। यह वह स्तर है जो वेब सर्वर या सर्वलेट कंटेनर (उदाहरण के लिए, टॉमकैट या जेट्टी) में चलने वाले वेब एप्लिकेशन संबंधित हैं, और मार्कअप जनरेट करने के लिए जिम्मेदार हैं, अर्थात् HTML, XML या JSON।

आप केवल आवश्यकतानुसार नए सर्वर जोड़ सकते हैं और हटा सकते हैं - जब तक कि एक एकल वेब सर्वर:

• स्टेटलेस, या
• इसकी स्थिति वसूली योग्य है - उदाहरण के लिए, क्योंकि इसमें पूरी तरह से कैश शामिल हैं, या
• उनकी (कैश) स्थिति विशिष्ट उपयोगकर्ताओं को संदर्भित करती है और इस बात की गारंटी है कि एक ही उपयोगकर्ता को हमेशा एक ही सर्वर (सत्र चिपचिपाहट) मिलेगा।

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

यह मुख्य कारण है कि अनुप्रयोग डेटाबेस में बहुत खराब पैमाने पर होते हैं: एक डेटाबेस का मुख्य कार्य केवल डेटा (एसीआईडी ​​और वह सब) को सहेजना है । डेटा पढ़ना उनके लिए बहुत मुश्किल है ("कैसे" और "क्यों" चिल्लाने से पहले, सोचें: आपको ल्यूसीन / सौर / लोचदार खोज जैसे कई इंडेक्सर्स की आवश्यकता क्यों है?)। चूंकि हम आधार के माध्यम से स्केल नहीं कर सकते हैं, हमें एप्लिकेशन टियर के माध्यम से स्केल करने की आवश्यकता है। यह महान काम करता है इसके कई कारण हैं, मैं दो नाम दूंगा:

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

स्केलिंग सेवाओं के लिए अलग-अलग रणनीतियाँ हैं।

स्केलिंग रणनीतियों।

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

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


योजना 5: राउंड-रॉबिन सिद्धांत के अनुसार सेवा कॉल वितरित करें

जब सेवा मामलों में स्थिति होती है, तो उन्हें एक दूसरे के साथ सिंक्रनाइज़ किया जाना चाहिए, उदाहरण के लिए, EventChannel या किसी अन्य प्रकाशित / सब्सक्राइबर विकल्प के माध्यम से राज्य परिवर्तनों की घोषणा करके:


चित्रा 6: राज्य सिंक के साथ गोल-रॉबिन

इसी समय, प्रत्येक उदाहरण सभी परिवर्तनों के अन्य उदाहरणों को सूचित करता है जो इसे प्रत्येक सहेजे गए ऑब्जेक्ट के लिए बनाता है। बदले में, शेष उदाहरण स्थानीय रूप से एक ही ऑपरेशन को दोहराते हैं, उनकी निजी स्थिति को बदलते हैं, और इस तरह सभी उदाहरणों में सेवा की स्थिति (सुसंगत) को बनाए रखते हैं।

यह रणनीति कम ट्रैफ़िक के साथ अच्छी तरह से काम करती है। हालांकि, इसकी वृद्धि के साथ, कई उदाहरणों के साथ एक ही वस्तु को एक साथ बदलने की संभावना के साथ समस्याएं पैदा होती हैं।

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

आदर्श रूप से, हमारे पास एक एकल-मूल्यवान पैरामीटर है, उदाहरण के लिए, UserId, जिसे आसानी से संख्याओं में परिवर्तित किया जा सकता है और शेष के साथ विभाजित किया जा सकता है। कार्यशील उदाहरणों की संख्या से विभाजित, शेष अनुरोध के लक्ष्य उदाहरण को इंगित करता है: शेष 0 के साथ सभी अनुरोध पहली आवृत्ति पर जाते हैं, शेष 1 से दूसरे तक, आदि।


चित्र 7: बचे हुए शेयरिंग

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

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

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


चित्र 8: प्रॉक्सी सेवाएँ

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

उपसंहार

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

हर पोर्टल को स्केल नहीं किया जाना चाहिए, लेकिन जो लोग ऐसा करने में सक्षम होना चाहिए। पूरी तरह से प्रौद्योगिकी (NoSQL, आदि) पर भरोसा करने का मतलब है कि पहिया गलत हाथों को दे रहा है, और अगर प्रौद्योगिकी की पसंद गलत हो जाती है, तो अपने सिस्टम के टुकड़ों को झाड़ू से उठाएं।

यदि आप शुरू से ही सही वास्तुकला चुनते हैं, तो अपने सिद्धांतों और प्रतिमानों को खोजें और उनका पालन करें, तो आप हमेशा आने वाली कठिनाइयों और चुनौतियों का जवाब पा सकते हैं।

सौभाग्य है