हमने Yandex.Disk कैसे किया: सर्वर साइड, WebDAV और Erlang

पिछले हफ्ते, Yandex.Disk एक साल पुराना हो गया, और 8,000,000 से अधिक उपयोगकर्ता इस वर्ष सेवा का उपयोग करने में कामयाब रहे।

और अब हम इस बारे में बात करना जारी रखते हैं कि यह सब संभव करने के लिए कितना प्रयास किया गया। हाल ही में, हमने लिखा कि कैसे और क्यों Yandex.Disk टीम ने WebDAV को डेस्कटॉप क्लाइंट को सर्वर के साथ सिंक्रोनाइज़ करने के लिए चुना और प्रोटोटाइप Yandex.Disk क्लाइंट पर काम करना शुरू किया। आज, जैसा कि वादा किया गया है, यह इस बारे में है कि सर्वर साइड पर सब कुछ कैसे काम करता है।



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

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

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

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

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

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

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

जैसा कि सर्वर से प्राप्त खुद को पचाया जाता है, हम उन्हें मांग पर गणना करके सिंक्रनाइज़ेशन प्रक्रिया को धीमा नहीं करना चाहते थे, इसलिए उन्हें पहले से गणना किए गए सर्वर पर संग्रहीत करने का निर्णय लिया गया था।

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

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


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

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

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