المزامنة الأشياء بين نظامين المتباينة، وأفضل النهج؟

Question

وأنا أعمل على المزامنة كائنين التجارية بين اي فون وموقع ويب باستخدام حمولة القائم على XML، وأحب أن التماس بعض الأفكار لروتين الأمثل.

وطبيعة هذا السؤال هو عامة إلى حد ما على الرغم من وأستطيع أن أرى كونها تنطبق على مجموعة متنوعة من الأنظمة المختلفة التي تحتاج إلى مزامنة الكائنات الأعمال بين كيان شبكة الإنترنت وعميل (سطح المكتب، والهاتف المحمول، الخ.)

ويمكن تحرير الكائنات الأعمال أو حذفها، وتحديثها على كلا الجانبين. ويمكن لكل من الطرفين تخزين الكائن محليا ولكن يتم بدء المزامنة فقط على الجانب فون للعرض قطع. كل الكائنات لها updated_at وcreated_at الطابع الزمني ودعمت من قبل RDBMS على كلا الجانبين (سكليتي على الجانب فون و MySQL على شبكة الإنترنت ... مرة أخرى أنا لا أعتقد أن هذا يهم كثيرا)، والهاتف لا تسجل الوقت الماضي ل جرت محاولة متزامنة. وإلا، يتم تخزين أي بيانات أخرى (في الوقت الحاضر).

وماذا الخوارزمية التي ستستخدمها للحد من الثرثرة الشبكة بين أنظمة المزامنة؟ كيف يمكنك التعامل مع حذف إذا "لينة حذف" ليست خيارا؟ ما هي التغييرات نموذج البيانات أن تضيفها إلى facilite هذا؟

Answer 1

وأبسط النهج: عندما المزامنة، نقل جميع السجلات where updated_at >= @last_sync_at. الجانب السلبي: هذا النهج لا يتسامح مدار الساعة تحرف جيدا على الإطلاق

وربما هو أكثر أمانا للحفاظ على العمود رقم الإصدار الذي يتزايد في كل مرة يتم تحديث صف (بحيث تحرف على مدار الساعة لا تشوش عملية المزامنة) ورقم الإصدار الأخير مزامن (بحيث التغييرات المحتملة المتضاربة يمكن أن يكون المحددة). لجعل هذا كفاءة عرض النطاق الترددي، والحفاظ على مخبأ في كل قاعدة بيانات الإصدار الأخير إرسالها إلى كل الزملاء النسخ المتماثل بحيث تحتاج إلى أن تنتقل الصفوف المعدلة فقط. إذا كان هذا سيكون طوبولوجيا نجمة، يمكن أن يترك استخدام مخطط مبسط حيث يتم تخزين نسخة مزامن الماضي في كل جدول.

ويطلب من بعض شكل من أشكال-حذف الناعمة من أجل دعم المزامنة من الحذف، ولكن هذا يمكن أن يكون في شكل سجل "علامة" الذي يحتوي فقط على مفتاح الصف المحذوفة. لا يمكن إلا أن شواهد القبور يتم حذف بأمان مرة واحدة كنت متأكدا من أن كافة النسخ المتماثلة وتجهز لهم، وإلا فمن الممكن للنسخة طبق الأصل التيه لإحياء سجل فكرت تم حذف.

Answer 2

لذلك أعتقد أن في ملخص أسئلتك تتعلق تزامن قطع.

وحتى هنا هو ما أعتقد يجب أن يحدث:

وتزامن الأولي يمكنك استرداد البيانات وأية معلومات مرتبطة به (الإصدارات التوالي، اختبارية ملف الخ). فمن المهم أن تخزين هذه المعلومات وترك الأمر البكر حتى المزامنة ناجحة المقبلة. يجب إجراء تغييرات على نسخة من هذه البيانات.

والتغييرات التتبع إذا كنت تتعامل مع صفوف قاعدة بيانات، والفكرة هي، أساسا لديك لتعقب إدراج وتحديث وحذف العمليات. إذا كنت تتعامل مع ملفات نصية مثل XML، ثم في قليلا أكثر تعقيدا. إذا كان من المحتمل أن العديد من المستخدمين سوف تحرير هذا الملف في نفس الوقت، فإنك سوف يكون لديك أداة فرق، لذلك يمكن أن يتم الكشف عن الصراعات في مستوى أكثر تفصيلا (بدلا من الملف بأكمله).

والتحقق من الصراعات مرة أخرى إذا كنت مجرد التعامل مع الصفوف قاعدة البيانات، والصراعات من السهل اكتشافها. هل يمكن أن يكون عمود آخر أن زيادات كلما يتم تحديث الصف (على ما أظن MSSQL له هذا المضمن غير متأكدة الخلية). حتى إذا كان لديك نسخة لديها عدد مختلف من ما هو على الخادم، ثم لديك الصراع. عن الملفات أو الجمل، وسوف الاختباري قيام بهذه المهمة. أفترض أنك يمكن أيضا استخدام تاريخ التعديل ولكن تأكد من أن لديك قياس دقيق جدا ودقيقة لمنع يخطئ. على سبيل المثال: يتيح القول أنا استرداد الملف وحفظه وسرعان ما استرجاعها. دعونا نقول الفارق الزمني هو ميلي ثانية واحدة 1. وبعد ذلك إجراء تغييرات على ملف ثم أحاول حفظه. إذا سجلت وقت آخر تعديل دقيقة فقط إلى 10 ميلي ثانية، هناك فرصة جيدة أن الملف I استردادها سيكون لها نفس التاريخ المعدلة واحد قمت بحفظه حتى يفكر البرنامج theres لا الصراع والكتابة التغييرات. لذلك أنا عموما لا تستخدم هذه الطريقة لمجرد أن يكون على الجانب الآمن. من ناحية أخرى فإن فرص حدوث تصادم الاختباري / التجزئة بعد تعديلات طفيفة على مقربة من لا شيء.

وحل النزاعات الآن هذا هو الجزء صعبة. إذا كانت هذه هي عملية مؤتمتة، ثم عملتم لتقييم الوضع وتقرر ما إذا كنت تريد الكتابة التغييرات، تفقد التغييرات أو استرداد البيانات من الخادم مرة أخرى ومحاولة لإعادة التغييرات. لحسن الحظ بالنسبة لك، ويبدو أنه لن يكون هناك تفاعل البشري. ولكن لا يزال الكثير من الألم إلى رمز. إذا كنت تتعامل مع صفوف قاعدة البيانات، يمكنك التحقق من كل عمود على حدة ومقارنتها ضد البيانات في الخادم وتقديمها للمستخدم. والفكرة هي أن يقدم الصراعات المستخدم بطريقة دقيقة جدا بحيث لا تطغى عليها. معظم الصراعات لديها خلافات صغيرة جدا في العديد من الأماكن المختلفة الحالية لذلك إلى اختلاف مستخدم واحد صغير في وقت واحد. وذلك لملفات نصية، لها تقريبا نفس ولكن أكثر من مائة مرة أكثر تعقيدا. وذلك أساسا عملتم لإنشاء أو استخدام أداة فرق (مقارنة النص هو موضوع مختلف تماما وواسع جدا لذكرها هنا) التي تمكنك من معرفة من التغييرات الصغيرة في ملف وأين هم بطريقة مماثلة كما هو الحال في قاعدة البيانات: حيث تم إدراج نص أو حذفها أو تحريرها. ثم عرض ذلك للمستخدم في نفس الطريق. وذلك أساسا عن كل الصراعات الصغيرة، المستخدم سيكون لاختيار ما إذا كنت تريد تجاهل التغييرات الخاصة بهم، الكتابة فوق التغييرات في الملقم أو إجراء تعديل اليدوي قبل أن يرسل إلى الخادم.

وحتى إذا كنت قد فعلت الأمور في نصابها الصحيح، ينبغي أن تعطى للمستخدم قائمة من الصراعات إذا كان هناك أي. وينبغي أن تكون هذه الصراعات الحبيبية بما فيه الكفاية للمستخدم لاتخاذ قرار بسرعة. هكذا على سبيل المثال، فإن الصراع هو تغيير الإملائي من، سيكون من الأسهل بالنسبة للمستخدم أن يختار من هجاء كلمة في المقابل إلى إعطاء المستخدم الفقرة بأكملها، ونقول له ان كان هناك تغيير، وأنه عليهم أن يقرروا ما يجب القيام به ، فإن المستخدم ثم يكون للبحث عن هذا الخطأ الإملائي صغير.

واعتبارات أخرى: التحقق من صحة البيانات - نضع في اعتبارنا أن لديك لإجراء التحقق من الصحة بعد حل conflicنهاية الخبر لأن البيانات قد تغيرت مقارنة النص - كما قلت، وهذا هو موضوع كبير. حتى جوجل ذلك! تزامن قطع - أعتقد أن هناك عدد قليل من المواد هناك

.

المصدر: https://softwareengineering.stackexchange.com/questions/94634 / التزامن على شبكة الانترنت لخدمة منهجيات أو أوراق