Yandex.Disk कैसे काम करता है: बूटलोडर

हमने पहले से ही इस बारे में बात की थी कि कैसे WebDAV प्रोटोकॉल के पक्ष में चुनाव किया गया था, साथ ही सर्वर साइड में आने वाली समस्याओं और उनके समाधान के बारे में भी।

आज - सेवा के लिए फ़ाइल लोडर की व्यवस्था कैसे की जाती है, और जब आप इसे Yandex.Disk- स्केल सेवाओं के लिए लिखते हैं तो आपको क्या नहीं भूलना चाहिए।



शुरू करने के लिए, सेवा के आर्किटेक्चर पर समग्र रूप से विचार करें। सेवा mpfs, मैजिक प्रॉक्सी फाइल सिस्टम पर आधारित है। यह बैकएंड है, जिसमें फ़ाइलों, फ़ोल्डरों, निर्देशिकाओं के साथ काम करने के लिए सभी व्यावसायिक तर्क हैं: नई फ़ाइलों की प्रतिलिपि बनाने या बनाने के लिए सभी ऑपरेशन इस प्रणाली से गुजरते हैं। मेटाडेटा के भंडारण के लिए भी यही प्रणाली जिम्मेदार है।

क्लाइंट के साथ सिंक्रनाइज़ेशन WebDAV प्रोटोकॉल के माध्यम से होता है। इसके आधार पर, हमने विंडोज, ओएस एक्स और मोबाइल प्लेटफॉर्म के लिए क्लाइंट बनाए। लेकिन यदि आवश्यक हो, तो WebDAV का उपयोग करके, आप इस प्रोटोकॉल का समर्थन करने वाले किसी भी एप्लिकेशन के साथ सिंक्रनाइज़ेशन को कॉन्फ़िगर कर सकते हैं।



वेब इंटरफ़ेस के माध्यम से, उपयोगकर्ताओं के पास क्लाइंट के माध्यम से समान कार्य होते हैं: डाउनलोड, डाउनलोड और फ़ाइलों को देखें। इसके अलावा, हमारे आंतरिक एपीआई के माध्यम से, हम अन्य यैंडेक्स सेवाओं के साथ बातचीत करते हैं। फिलहाल यह पीपल, मेल, म्यूजिक और ब्राउजर है। उदाहरण के लिए, Yandex.Music मोबाइल क्लाइंट के माध्यम से, आप डिस्क पर डाउनलोड की गई ऑडियो फ़ाइलों तक पहुंच सकते हैं।

खजाना तलवार

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



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

टास्क स्टेज

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

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

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

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


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

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

बस डिस्कनेक्ट नहीं है! बस डिस्कनेक्ट नहीं है!

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