संक्षेप (टीएल;डीआर)
- समस्या: एक ही फोल्डर को लैपटॉप, फोन और ब्राउजर पर एक जैसा रखना, करोड़ों उपयोगकर्ताओं के लिए जिनके पास कई गीगाबाइट हैं, अस्थिर नेटवर्क पर, जबकि लोग ऑफलाइन वही फाइलें बदलते हैं और उम्मीद करते हैं कि कुछ भी कभी न खोए।
- डिजाइन: फाइलों को उनके हैश से पहचाने जाने वाले तय आकार के ब्लॉक में बांटें, सिर्फ वे ब्लॉक अपलोड करें जो सर्वर के पास पहले से नहीं हैं, और हर नए संस्करण को मेटाडेटा डेटाबेस में ब्लॉक हैश की सूची के रूप में दर्ज करें। हर दर्ज बदलाव नामस्थान की बदलाव पत्रिका में जुड़ता है; एक सूचना सेवा दूसरे डिवाइसों को अपने कर्सर के बाद के बदलाव लाने को कहती है। दर्ज करना आशावादी समवर्तिता से होता है, और होड़ हारने पर चुपचाप ऊपर लिखने के बजाय टकराव वाली प्रति बनती है।
- नतीजा: बड़ी फाइल बदलने पर गीगाबाइट नहीं, मेगाबाइट अपलोड होते हैं, एक जैसी सामग्री एक बार रखी जाती है, डिवाइस एक कर्सर खोज से बराबर हो जाते हैं, और डेटा खोने का इकलौता बचा रास्ता वह है जो उपयोगकर्ता जानबूझकर चुनते हैं।
मिलान वाला उत्पाद एक ऐसा वादा करता है जो सरल लगता है पर है नहीं: फोल्डर हर जगह एक जैसा है। नीचे यह एक वितरित सिस्टम है जहां हर लैपटॉप एक प्रतिकृति है जो दिनों तक ऑफलाइन रहती है, और जो उपयोगकर्ता इसे बदलते हैं वही टकराव लिखते हैं।
ड्रॉपबॉक्स ने इस लेख में बताया गया आर्किटेक्चर लोकप्रिय बनाया, और गूगल ड्राइव, वनड्राइव और आईक्लाउड ड्राइव यही समस्या लगभग मिलते-जुलते तरीकों से हल करते हैं।
जरूरतें और संख्याएं
कार्यात्मक: डिवाइसों के बीच फाइलें और फोल्डर अपलोड, डाउनलोड और मिलान करना; संस्करण इतिहास और बहाली; अनुमतियों के साथ साझा करना; ऑफलाइन बदलाव जो बाद में मिलें; साझा सामग्री बदलने पर सूचना।
गैर-कार्यात्मक: पुष्टि हो चुका डेटा कभी न खोए; ऑनलाइन डिवाइस पर बदलाव सेकंडों में मिलें; धीमे और नापे गए नेटवर्क पर कुशल; सैकड़ों पेटाबाइट तक बढ़े।
| मान्यता | मान | नतीजा |
|---|---|---|
| उपयोगकर्ता | ५ करोड़ | |
| हर उपयोगकर्ता का औसत स्टोरेज | १० जीबी | दोहराव हटाने और दबाने से पहले लगभग ५०० पेटाबाइट |
| हर उपयोगकर्ता के रोज फाइल बदलाव | लगभग २ | रोज लगभग १० करोड़ दर्ज बदलाव, औसतन लगभग १,२०० प्रति सेकंड |
| फाइल का औसत आकार | लगभग ५०० केबी, कई जीबी वाली फाइलों की लंबी पूंछ के साथ | ज्यादातर बदलाव छोटे; कुछ बैंडविड्थ पर हावी |
| हर उपयोगकर्ता के डिवाइस | २ से ३ | हर बदलाव १ से २ और डिवाइस डाउनलोड करते हैं |
आर्किटेक्चर
- लैपटॉप मिलान क्लाइंट। सबसे जटिल हिस्सा। यह फाइल सिस्टम पर नजर रखता है, एक स्थानीय डेटाबेस रखता है कि उसके हिसाब से सर्वर के पास क्या है, बदली फाइलों को ब्लॉक में बांटता है, अपलोड करता है, दर्ज करता है, और दूर के बदलाव लागू करता है। ड्रॉपबॉक्स ने अपना क्लाइंट (रस्ट में लिखा "न्यूक्लियस" इंजन) ठीक इसीलिए दोबारा लिखा क्योंकि मिलान को सही रखना इतना कठिन है।
- फोन / वेब। आमतौर पर पूरा फोल्डर नहीं रखते; वे मेटाडेटा देखते हैं और मांग पर फाइलें डाउनलोड करते हैं।
- लोड बैलेंसर। ब्लॉक ट्रैफिक और मेटाडेटा ट्रैफिक को अलग बेड़ों पर भेजता है, क्योंकि उनकी शक्ल अलग है: बड़ी बहती सामग्री बनाम छोटे लेनदेन वाले अनुरोध।
- ब्लॉक सेवा (अपलोड, दोहराव हटाना)। हैश से पहचाने ब्लॉक स्वीकार करती है। उस हैश वाला ब्लॉक पहले से हो तो अपलोड छोड़ दिया जाता है। दोबारा शुरू होने वाले हस्तांतरण का समर्थन करती है।
- ब्लॉक स्टोर (सामग्री से पता पाने वाला)। ऐसा ऑब्जेक्ट स्टोर जिसकी कुंजी ब्लॉक का हैश है। अपरिवर्तनीय: ब्लॉक कभी बदला नहीं जाता, सिर्फ उसका हवाला दिया जाता है या उसे हटाया जाता है। ड्रॉपबॉक्स ने २०१६ में इस स्तर का ज्यादातर हिस्सा अमेजन एस३ से अपने एक्साबाइट पैमाने वाले सिस्टम मैजिक पॉकेट पर पहुंचाया।
- मेटाडेटा एपीआई (फाइलें, संस्करण)। पेड़ का अधिकृत रिकॉर्ड: रास्ते, संस्करण, ब्लॉक सूचियां, अनुमतियां। हर बदलाव यहां एक लेनदेन है।
- मेटाडेटा डेटाबेस (नामस्थान से बंटा)। नामस्थान किसी उपयोगकर्ता की जड़ या साझा फोल्डर है। नामस्थान से बांटने पर किसी फोल्डर का पूरा इतिहास और उसकी पत्रिका एक ही हिस्से पर रहते हैं, इसलिए दर्ज करना एक हिस्से वाला लेनदेन है।
- बदलाव पत्रिका (हर नामस्थान की)। किसी नामस्थान के हर दर्ज बदलाव का क्रमबद्ध लॉग। हर डिवाइस अपना कर्सर (पत्रिका में अपनी जगह) याद रखता है।
- सूचना (लंबी पोलिंग / वेबसॉकेट)। बदलाव नहीं ले जाती, सिर्फ यह कि "नामस्थान एन में कुछ बदला।" फिर डिवाइस मेटाडेटा एपीआई से अपने कर्सर के बाद का सब मांगता है।
- ठंडा स्तर। सिर्फ पुराने संस्करणों या कम खोली जाने वाली फाइलों के ब्लॉक सस्ते स्टोरेज पर चले जाते हैं।
ब्लॉक सब कुछ क्यों बदल देते हैं
फाइलों को पूरी वस्तु मानने का मतलब है कि १ जीबी वीडियो का एक बाइट बदलने पर पूरा १ जीबी दोबारा अपलोड हो। उन्हें ब्लॉक की सूची मानना एक साथ तीन समस्याएं सुलझाता है:
१. सिर्फ बदलाव का मिलान। केवल बदले हुए ब्लॉक जाते हैं। ड्रॉपबॉक्स ४ एमबी के ब्लॉक इस्तेमाल करने की बात बता चुका है। बड़ी फाइल के बीच का बदलाव आमतौर पर एक या दो ब्लॉक छूता है। (फाइल की शुरुआत में बाइट जोड़ने पर तय आकार के ब्लॉक खिसक जाते हैं; घूमते हैश के साथ सामग्री से तय होने वाला बंटवारा, जो आरसिंक और कई बैकअप टूल के पीछे का विचार है, ज्यादा जटिलता की कीमत पर सीमाएं स्थिर रखता है।) २. दोहराव हटाना। एक जैसे ब्लॉक एक बार रखे जाते हैं, चाहे वे उसी फाइल के पिछले संस्करण में हों, उपयोगकर्ता की बनाई प्रति में, या कई उपयोगकर्ताओं के डाउनलोड किए एक ही इंस्टॉलर में। उपयोगकर्ताओं के बीच दोहराव हटाने के निजता पर असर हैं: हमलावर अपलोड की रफ्तार देखकर जान सकता है कि कोई सामग्री पहले से मौजूद है या नहीं, इसलिए कई सेवाएं दोहराव हटाना एक ही खाते तक सीमित रखती हैं। ३. फिर से शुरू करना। विफल अपलोड शून्य से नहीं, अगले गायब ब्लॉक से फिर शुरू होता है।
दर्ज करने का तरीका:
१. ग्राहक ब्लॉकों का हैश निकालकर पूछता है "इनमें से कौन से हैश तुम्हारे पास नहीं हैं?"
२. ग्राहक सिर्फ वही अपलोड करता है।
३. ग्राहक दर्ज करता है फाइल एक्स, नई ब्लॉक सूची, मूल संस्करण v7।
४. सर्वर तभी स्वीकार करता है जब मौजूदा संस्करण अब भी ७ हो, फिर उसे पत्रिका में जोड़ता है।
हरा नोट इसका व्यावहारिक फायदा है। लाल नोट वह समवर्तिता नियम है जिससे अगला खंड काम करता है।
टकराव: कभी चुपचाप विजेता मत चुनो
दो डिवाइस ऑफलाइन एक ही फाइल बदलते हैं। दोनों ऑनलाइन आते हैं। दोनों मूल संस्करण ७ के साथ दर्ज करते हैं। पहला जीतकर संस्करण ८ बनता है। दूसरे को मिलता है "टकराव: मूल बदल चुका है।"
ग्राहक को क्या करना चाहिए? हर बड़े मिलान उत्पाद ने एक ही चुनाव किया: दोनों रखो। हारा हुआ बदलाव बगल में कुछ इस नाम से सहेजा जाता है report (Alice's conflicted copy 2026-02-10).docx। यह भद्दा है। यही इकलौता जवाब भी है जो कभी किसी का काम नष्ट नहीं करता।
असली समय के साझा संपादक (गूगल डॉक्स, ऑफिस ऑनलाइन) इससे अलग तरह बचते हैं: वे पूरी फाइलें नहीं, बारीक बदलाव संचालन रूपांतरण या सीआरडीटी से मिलाते हैं। फाइल मिलान और दस्तावेज पर साथ काम करना अलग उत्पाद हैं, और इसकी वजह है।
टकराव के दूसरे मामले जिन्हें साफ तौर पर संभालना चाहिए:
| मामला | समझदारी वाला हल |
|---|---|
| एक डिवाइस पर बदलाव, दूसरे पर मिटाना | बदली हुई फाइल रखें; मिटाना नए बदलाव को नष्ट न करे |
| एक डिवाइस पर नाम बदलना, दूसरे पर बदलाव | दोनों लागू करें: फाइल नए नाम और नई सामग्री के साथ |
| एक ही नाम के दो फोल्डर बने | सुरक्षित हो तो मिलाएं, वरना एक के नाम में कुछ जोड़ें |
| छोटे-बड़े अक्षर न पहचानने वाले फाइल सिस्टम पर सिर्फ अक्षरों के आकार वाला नाम बदलना | सावधानी से संभालें; मिलान बग का एक पुराना स्रोत |
संस्करण, बहाली और मिटाना
क्योंकि ब्लॉक अपरिवर्तनीय हैं और संस्करण ब्लॉक हैश की सूचियां हैं, संस्करण इतिहास लगभग मुफ्त है: हर संस्करण मेटाडेटा की एक छोटी पंक्ति है। पुराना संस्करण बहाल करना पुरानी ब्लॉक सूची की ओर इशारा करने वाला एक नया दर्ज बदलाव है।
मिटाना दिखने से कठिन है। कोई ब्लॉक तभी हटाया जा सकता है जब किसी फाइल का कोई संस्करण उसका हवाला न दे, और संस्करण एक नीति अवधि (जैसे ३० दिन, या भुगतान वाले स्तरों पर ज्यादा) तक रखे जाते हैं। कचरा हटाना पृष्ठभूमि का एक सावधान काम है, मेटाडेटा पर हवालों की गिनती या चिह्नित करके साफ करने के साथ, क्योंकि अब भी इस्तेमाल हो रहा ब्लॉक मिटाना स्थायी डेटा नुकसान है।
साझा करना
साझा फोल्डर अपना अलग नामस्थान है, जो हर सदस्य के पेड़ में जोड़ा जाता है। अनुमतियां नामस्थान पर रहती हैं (देखने वाला, टिप्पणी करने वाला, संपादक)। क्योंकि पत्रिका और सूचनाएं हर नामस्थान की हैं, एक सदस्य का बदलाव हर सदस्य के डिवाइसों को ठीक उसी रास्ते से सूचित करता है जिससे किसी उपयोगकर्ता के अपने बदलाव।
लिंक ("लिंक वाला कोई भी") एक अलग, वापस लिया जा सकने वाला अधिकार है, वैकल्पिक समाप्ति और पासवर्ड के साथ, जिसे मेटाडेटा एपीआई हर पहुंच पर जांचता है।
विफलताएं
| विफलता | व्यवहार |
|---|---|
| अपलोड बीच में रुका | अगले गायब ब्लॉक से फिर शुरू |
| दर्ज करना सफल, पर दर्ज करने से पहले ग्राहक गिरा | दोबारा शुरू होने पर ग्राहक पत्रिका से पूछकर अपना दर्ज बदलाव देखता है |
| सूचना सेवा बंद | ग्राहक समय-समय पर अपने कर्सर से पूछने पर लौटते हैं |
| मेटाडेटा का एक हिस्सा बंद | वह नामस्थान दर्ज नहीं कर सकता; बाकी अप्रभावित। ग्राहक स्थानीय बदलाव कतार में रखते हैं |
| स्टोरेज में खराब ब्लॉक | पढ़ते समय हैश मेल न खाने से पकड़ा जाता है; प्रतिकृति या मिटाव कोड वाले टुकड़ों से मरम्मत |
| ग्राहक का बग स्थानीय रूप से सब मिटा दे | सर्वर का संस्करण इतिहास और रद्दी टोकरी इसे वापस लाने देती है; बड़े पैमाने पर मिटाने की दर सीमित करें और पुष्टि लें |
उत्पादन जांच सूची
- अपलोड से पहले ब्लॉक हैश और गायब ब्लॉक की बातचीत
- सामग्री से पता पाने वाला, अपरिवर्तनीय ब्लॉक स्टोरेज, पढ़ते समय सत्यता जांच के साथ
- नामस्थान से बंटा मेटाडेटा; दर्ज करना एक हिस्से वाला लेनदेन
- मूल संस्करण के साथ आशावादी समवर्तिता; टकराव वाली प्रतियां, चुपचाप ऊपर लिखना कभी नहीं
- हर नामस्थान की बदलाव पत्रिका और हर डिवाइस का कर्सर
- सूचनाएं इशारे के रूप में, पोलिंग के सहारे के साथ
- संस्करण रखने की नीति और सुरक्षित, जांचा हुआ कचरा हटाना
- बड़े पैमाने पर मिटाने से सुरक्षा और रद्दी टोकरी
- डैशबोर्ड: मिलान की देरी (दर्ज होने से दूसरे डिवाइस पर लागू होने तक), टकराव दर, दोहराव हटाने से बचे अपलोड बाइट, पत्रिका की देरी
जो बचा रह गया
मिलान वाले फोल्डर का जादू यह है कि लोग भूल जाते हैं कि वह है। वे रात को लैपटॉप पर फाइल सहेजते हैं और सुबह फोन पर खोलते हैं, बीच के सैकड़ों ब्लॉक, हैश, पत्रिकाओं और कर्सरों के बारे में सोचे बिना।
जिस दिन उन्हें याद आता है कि वह है, वह अक्सर वही दिन होता है जब उसने टकराव वाली प्रति बनाई। भद्दा नाम, दोनों संस्करण सुरक्षित। वह फाइल सिस्टम का अपना इकलौता असली वादा निभाना है।
स्रोत
- ड्रॉपबॉक्स टेक ब्लॉग: हमारे मिलान इंजन का दिल दोबारा लिखना (न्यूक्लियस)
- ड्रॉपबॉक्स टेक ब्लॉग: मैजिक पॉकेट के अंदर
- ड्रॉपबॉक्स टेक ब्लॉग: बहती फाइल का मिलान
- ड्रॉपबॉक्स सहायता: टकराव वाली प्रतियां
- ट्रिजेल और मैकेरास, आरसिंक एल्गोरिदम
- इसी श्रृंखला में: कुंजी-मान स्टोर डिजाइन करें, यूट्यूब जैसा वीडियो मंच डिजाइन करें, सूचना सिस्टम डिजाइन करें