टाइमस्टैम्प आधारित सिंकिंग के सामान्य नुकसान क्या हैं?

Question

मैं अपना पहला सिंकिंग कोड लागू कर रहा हूं। मेरे मामले में मेरे पास प्रति उपयोगकर्ता 2 प्रकार के आईओएस क्लाइंट होंगे जो lastSyncTimestamp का उपयोग कर सर्वर पर रिकॉर्ड्स सिंक करेंगे, 64 बिट पूर्णांक जो अंतिम सिंक के मिलीसेकंड में यूनिक्स युग का प्रतिनिधित्व करता है। रिकॉर्ड्स किसी भी समय सर्वर या क्लाइंट पर बनाया जा सकता है और रिकॉर्ड को HTTP पर JSON के रूप में आदान-प्रदान किया जाता है।

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

मुझे पता है कि गिट और कुछ अन्य संस्करण नियंत्रण प्रणाली एक सामग्री आधारित बातचीत समन्वयन दृष्टिकोण के लिए टाइमस्टैम्प के साथ समन्वयित करती है। मैं अपने ऐप्स के लिए भी इस तरह के दृष्टिकोण की कल्पना कर सकता हूं, जहां uuid या hash ऑब्जेक्ट्स का उपयोग करके, दोनों सहकर्मी अपनी ऑब्जेक्ट्स की घोषणा करते हैं, और तब उन्हें एक्सचेंज करते हैं जब तक कि दोनों सहकर्मियों के समान सेट न हों।

यदि कोई सामग्री-आधारित सिंकिंग बनाम सामान्य रूप से टाइमस्टैम्प-आधारित सिंकिंग के किसी भी फायदे या नुकसान को जानता है जो सहायक भी होगा।

संपादित करें - यहां कुछ फायदे/नुकसान हैं जो मैंने टाइमस्टैम्प और सामग्री आधारित सिंकिंग के लिए किए हैं। कृपया चुनौती/सही करें।

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

• जॉनी - "मुझे यह कार्ड मिला।"
• डेवी - "मुझे कार्ड का यह गुच्छा मिला। मुझे वह कार्ड दो।"
• जॉनी - "यह आपका कार्ड है। कार्ड का गुच्छा दें।"
• डेवी - "यहां कार्ड का आपका समूह है।"
• ....
• दोनों - टाइमस्टैम्प आधारित सिंक करना
  • आसान
  • एकल सिंक करने के लिए इस्तेमाल किया संपत्ति को लागू करने की "हम किया जाता है"

  लाभ। के टाइमस्टैम्प आधारित सिंक करना

  • समय पर्यवेक्षक और अलग मशीन का घड़ियों के लिए एक रिश्तेदार अवधारणा है

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

• टाइमस्टैम्प आधारित सिंकिंग क्लाइंट के लिए मास्टर सिंकिंग के लिए काम करता है लेकिन सहकर्मी को सहकर्मी करने के लिए सहकर्मी या 2 स्वामी के साथ सिंकिंग के साथ काम नहीं करता है।
• विफलता का एकल बिंदु, जो भी टाइमस्टैम्प उत्पन्न करता है।
• समय वास्तव में समन्वयित होने की सामग्री से संबंधित नहीं है।

सामग्री आधारित

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

  नुकसान को लागू करने की जरूरत हो सकती है।

• टाइमस्टैम्प आधारित सिंकिंग की तुलना में दोनों पक्षों पर अधिक तर्क।
• थोड़ा अधिक चतुर प्रोटोकॉल (यह क्लस्टर्स में सामग्री को सिंक करके ट्यून किया जा सकता है)।

Answer 1

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

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

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

फिर से, यह कई साल पहले था और मुझे विवरण याद नहीं किया जा सकता है, लेकिन मैं इस अवसर पर इसका उल्लेख करना चाहता हूं कि यह आपके मामले में महत्वपूर्ण है।

Answer 2

समस्या का एक हिस्सा यह है कि समय एक पूर्ण अवधारणा नहीं है। चाहे किसी और चीज से पहले या बाद में कुछ होता है, परिप्रेक्ष्य का मामला है, दीवार घड़ी के अनुपालन के नहीं।

relativity of simultaneity पर थोड़ा पढ़ें समझने के लिए क्यों लोग इन बातों को पता लगाना के लिए दीवार समय का उपयोग करने की कोशिश कर बंद कर दिया है और निर्माणों कि वास्तविक करणीय vector clocks (या कम से कम Lamport clocks) का उपयोग प्रतिनिधित्व करने के लिए चले गए हैं।

यदि आप सिंक्रनाइज़ेशन के लिए घड़ी का उपयोग करना चाहते हैं, तो लॉजिकल घड़ी आपको सबसे अच्छा लगेगी। आप अपने सभी घड़ी सिंक मुद्दों और सामान से बचेंगे।

Answer 3

आप unison पर एक नज़र डाल सकते हैं। यह फ़ाइल-आधारित है लेकिन आपको कुछ विचार दिलचस्प लग सकते हैं।