अत्यधिक लोड एप्लीकेशन आर्किटेक्चर। स्केलिंग वितरित प्रणाली। एक भाग

कुछ समय पहले, मास्को सगाई विकास कार्यालय के उप प्रमुख एलेक्सी रयबक और आईटी-कोमपोट प्रस्तुतकर्ताओं ने पॉडकास्ट की वास्तुकला “उच्च भारित अनुप्रयोगों के आर्किटेक्चर” को जारी किया। वितरित सिस्टम स्केलिंग। "

अब हमने पॉडकास्ट के डिकोडिंग को बनाया है, इसे एक पठनीय रूप में लाया और इसे 2 भागों में विभाजित किया।

उन्होंने पहले भाग में क्या बात की:

• बुश परियोजना के बारे में सामान्य जानकारी: प्रौद्योगिकी स्टैक, प्रकृति और कार्यभार की मात्रा, यातायात।
• परियोजना की क्षैतिज स्केलिंग:

- वेब सर्वर, कैशिंग, निगरानी आदि;
- एक परियोजना को स्केल करते समय नुकसान;
- स्केलिंग डेटाबेस, शार्पिंग कैसे करें।


प्रस्तुतकर्ता: सभी को नमस्कार, आप आईटी कम्पोट पॉडकास्ट के 45 वें अंक को सुन रहे हैं, और आपको एंटोन कोप्पलोव और एंटोन सर्गेयेव द्वारा होस्ट किया गया है।
आज हमने बैक-एंड के बारे में, वेब विकास के बारे में और विशेष रूप से अत्यधिक लोड किए गए अनुप्रयोगों की वास्तुकला और वितरित सिस्टम को कैसे स्केल किया जाए, इसके बारे में बात करने का फैसला किया। हमारे मेहमान, अलेक्सी रयबाक, हमारी मदद करेंगे। हाय एलेक्सी!

एलेक्सी रयबक: नमस्कार!

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

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

वेद: मैं देखता हूं। लेकिन हम नहीं जा रहे थे, इसलिए बोलने के लिए, आपको अन्य डेवलपर्स की पृष्ठभूमि के खिलाफ बहुत ऊंचा करना, यह कहना कि आप एक ऐसे अच्छे साथी हैं। हमारे पास अभी भी टीम के बारे में सवाल होंगे, दर्शकों ने हमसे ऐसे सवाल पूछे।

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

अलेक्सई, कृपया मुझे संक्षेप में बताएं कि आप विकास की दुनिया में कैसे आए, अब आप क्या कर रहे हैं और आप भविष्य में सामान्य रूप से क्या करने की योजना बना रहे हैं, आपकी योजनाएं क्या हैं।

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

वेद: हर कोई शायद इस डेटिंग साइट को जानता है, पहला बड़ा ज्ञात सामाजिक नेटवर्क। कम से कम मैं उसे इंटरनेट के "डायल-अप" के समय से याद करता हूं।

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

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

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

वेद: लेकिन मैं यह पता लगाना चाहता था। आपने अभी उल्लेख किया है कि आपका बैक-एंड syshny है - क्या आपके आवेदन में वास्तव में बहुत सारे कोड हैं?

AR: वास्तव में, बहुत सारे कोड हैं, लेकिन, यदि आप करेंगे, तो मैं आपको थोड़ा बाद में बताऊंगा कि हमारे पास ऐसी तकनीक क्यों है।

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

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

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

वेद: हाँ। और इसलिए मूल रूप से, जहाँ तक मुझे पता है, हमारे मूल निवासी PHP में लिखा है?

AR: हां, मूल रूप से यह PHP भाषा है, और हम MySQL का उपयोग डेटाबेस के रूप में करते हैं, अर्थात्, बहुत ही सरल प्रतीत होने वाली तकनीकें। फिर भी, उन पर सब कुछ किया जा सकता है - महान और अद्भुत।

वेद: हाँ। और अब आपके पास कितने सक्रिय दैनिक दर्शक हैं?

AR: अच्छा सवाल है। मुझे शायद अब विशिष्ट संख्या याद नहीं है, मुझे दस प्रतिशत तक गलत किया जा सकता है। दैनिक या मासिक में रुचि रखते हैं? मुझे लगता है कि 10 मिलियन के क्षेत्र में दैनिक दर्शक। यह मैं अधिकृत उपयोगकर्ताओं के बारे में बात कर रहा हूँ। और अगर हम उन लोगों के बारे में बात करते हैं जो कभी-कभी आते हैं और कुछ प्रोफाइलों को देखते हैं, तो मुझे लगता है कि सभी 20 मिलियन हैं।

वेद: और एक ही समय में आपके पास एक बड़ा असमान अनुप्रयोग है। मेरा मतलब है कि यह मोबाइल प्लेटफॉर्म पर सक्रिय रूप से दर्शाया गया है - ये फोन, टैबलेट, वेब संस्करण हैं ... क्या आप Xbox, प्लेस्टेशन कंसोल पर अनुपस्थित किसी भी मौका से हैं?

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

वेद: और इस तरह से परियोजना हमेशा शुरू होती है। उसके साथ, अगर यह उपयोगकर्ताओं के लिए वास्तव में सफल, दिलचस्प परियोजना है, तो दर्शक तेजी से बढ़ने लगते हैं। तदनुसार, किसी भी तरह से इस पूरी चीज का ठीक से समर्थन करना आवश्यक है, ताकि सेवा गिर न जाए, ताकि सेवा पर्याप्त रूप से प्रतिक्रिया दे। तदनुसार, यहाँ इस तरह की बहुत ही सामान्य बात है कि केवल आलसी अब बात नहीं कर रहा है क्षैतिज स्केलिंग है। अलग-अलग तरीके और प्रौद्योगिकियां हैं - अमेज़ॅन, अमेज़ॅन नहीं, बादल, भौतिक होस्टिंग; कुछ भी उपयोग किया जाता है - PHP, पायथन, रूबी, जावा, मुझे नहीं पता ... यहां तक ​​कि एर्लांग - शायद कोई ऐसा व्यक्ति है जो तुरंत इसका उपयोग करता है, भगवान न करे। आपने इसे कैसे अपनाया, आप क्या उपयोग कर रहे हैं, और वास्तव में ये तकनीकें क्यों हैं?

AR: मेरे लिए सबसे सामान्य तरीके से जवाब देना कठिन है, मैं इस बारे में अधिक बात करता हूं कि हम क्या उपयोग करते हैं। यह मुझे लगता है कि दुनिया में "प्रौद्योगिकी चिड़ियाघर" ऐसा है कि इतने सारे लोग, इस या उस तकनीक को चुनते हैं, जो जल्दी या बाद में एक साइकिल का आविष्कार करने के लिए मजबूर होते हैं। लेकिन चूंकि समुदाय एक या किसी अन्य भाषा के आसपास काफी बड़ा है, इसलिए अंत में यह साइकिल समुदाय के लिए एक पूरे के रूप में एक साइकिल बन जाती है, और एक या दूसरे तरीके से, एक या किसी अन्य भाषा का चयन करते हुए, स्केलिंग समस्या को हल करने की सबसे अधिक संभावना है।

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

हमारे द्वारा हल किए गए कार्य मुख्य रूप से स्केलिंग से नहीं, बल्कि विश्वसनीयता से संबंधित थे। 2005 के बाद से, मेरी राय में, हमने PHP को पैच कर दिया है। नतीजतन, परियोजना तथाकथित PHP FastCGI प्रक्रिया प्रबंधक या PHP-FPM में बदल गई और 2008 या 2009 में PHP के मूल में प्रवेश किया। और यह वास्तव में हमारा विकास है। आंद्रेई निगमाटुलिन ने शुरू में यह सब किया था, और यह केवल मापनीयता के लिए नहीं, बल्कि समर्थन की सुविधा के लिए भी किया गया था, ताकि आप आसानी से पुनः आरंभ कर सकें।

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

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

वेद: लेकिन आपने स्वचालन के माध्यम से एक व्यक्ति का नियंत्रण प्राप्त किया, नए नोड्स, बैकअप और इतने पर?

उ।: हाँ।

वेद: क्या आपके पास इसके लिए अपने स्वयं के उपकरण हैं या आप किसी भी समाधान का उपयोग कर रहे हैं?

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

वेद: हाँ।

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

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

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

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

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

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

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

AR: हम मूल रूप से यह, हाँ रखी।

वेद: यहाँ स्केलिंग के बारे में एक और बात है। , , . : « - , ». : , , , , , — .

..: , , - . - , . , . , . , , - . , , , , , . - , , . - , , , .

, , . - iPhone Android', «» http, , , . , html, - — , -, , , — , — , — storage-, .

, , , «» , , 0,1-0,2 , 0,2 — , , . , , , , . , 0,5 — , , . , . application- Pinba, - – url, , , , , URL.

.: , : , ? , - , - , « » - ?

..: , . , . , , : , - , ? , - — , - rebuild - - , ? ? , , , 100 , , . , , , , . — 0,001 100 — 100 000 . : 1000 , - , « », , - , . , . , . , - , - , , , . . : , .

.: , , .

..: , . , -. , , , .

2005 , — , , statement based. , data- , , , . , - , . , - , - — , - .

, , , ( — ), . , , , . . MySQL.

.: Mysqldump -, - , , - ?

..: . , , .

.: . , - , , ?

..: , , , , , .

.: : , ? «» ?

..: — — . , , , : , , data- . «» , . , , — 10-15 data-.

.: , - , front-end, — PHP, , ? , nginx?

..: , nginx.

.: , PHP-FPM. , , — , , , , — FlySoft, , FPM- PHP , , , Apache , nginx PHP-FPM, -, «». : - , , Amazon S3 , EC2 - . , - , data-?

..: data-. , , — , , , « », , , , . . - , - , , , . , , - . - , , . , , , : -, CDN, - — . «» , .

, , , , . . data-. , , , , - , - , . , . , , , , .

.: .

..: . CDN', , - , , . - - research connectivity, , - . CDN' - - — , CDN. , , - . , - — , , - research. , , . CDN. , - , - CDN CDN, .

.: , . , — , Vagrant, , , . ? memcached ?

..: , «» memcached — .

.: , - Redis', ?

..: , . production . - , , Redis - . production memcached.

.: , , , , , ?

..: , , ? , — , , ()… .

.: , , () . , : « ? - , ?» . : , , ORM , , - , , , , , , , ? ? , -, - , ORM . , , , ?

..: — ORM , , « — ». , , , , « »? — . - production , : - , , - , , , , . — «» , , , , .
: «, , ». , , . , . , , — .

जारी रखने के लिए ...
.