نمط / خوارزمية تزامن خادم العميل؟

Question

لدي شعور بأنه يجب أن تكون هناك أنماط مزامنة بين العميل والخادم.لكنني فشلت تمامًا في البحث عن واحدة على Google.

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

هل هناك أي أنماط/ممارسات جيدة لمثل هذا الموقف، أو إذا كنت لا تعرف أيًا منها، فما هو النهج الذي ستتبعه؟

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

البديل هو الاحتفاظ بتاريخ التعديل لكل سجل، وبدلاً من إجراء عمليات حذف للبيانات، ما عليك سوى وضع علامة عليها كمحذوفة.

أي أفكار؟

Answer 1

يجب أن تنظر إلى كيفية عمل إدارة التغيير الموزعة.انظر إلى SVN وCVS والمستودعات الأخرى التي تدير أعمال الدلتا.

لديك العديد من حالات الاستخدام.

• مزامنة التغييرات.يبدو أسلوب سجل التغيير (أو سجل الدلتا) جيدًا لهذا الغرض.يرسل العملاء دلتاهم إلى الخادم؛يقوم الخادم بدمج وتوزيع الدلتا على العملاء.هذه هي الحالة النموذجية.تسمي قواعد البيانات هذا "النسخ المتماثل للمعاملة".

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

• العميل مشبوه.في هذه الحالة، تحتاج إلى مقارنة العميل بالخادم لتحديد ما إذا كان العميل محدثًا ويحتاج إلى أي دلتا.

يجب عليك اتباع نمط تصميم قاعدة البيانات (وSVN) لترقيم كل تغيير بشكل تسلسلي.وبهذه الطريقة يمكن للعميل تقديم طلب تافه ("ما المراجعة التي يجب أن أقوم بها؟") قبل محاولة المزامنة.وحتى في هذه الحالة، يعد الاستعلام ("جميع الدلتا منذ 2149") بسيطًا للغاية بحيث يمكن للعميل والخادم معالجته.

Answer 2

كجزء من الفريق، قمت بالعديد من المشاريع التي تتضمن مزامنة البيانات، لذلك يجب أن أكون مؤهلاً للإجابة على هذا السؤال.

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

استنادًا إلى مراجعة الحلول الجاهزة الموجودة، يمكننا تحديد عدة فئات رئيسية للمزامنة، تختلف في تفاصيل الكائنات الخاضعة للمزامنة:

• يتم استخدام مزامنة مستند كامل أو قاعدة بيانات في التطبيقات السحابية، مثل Dropbox أو Google Drive أو Yandex.Disk.عندما يقوم المستخدم بتحرير ملف وحفظه، يتم تحميل إصدار الملف الجديد إلى السحابة بالكامل، مما يؤدي إلى استبدال النسخة السابقة.في حالة وجود تعارض، يتم حفظ كلا الإصدارين من الملف بحيث يمكن للمستخدم اختيار الإصدار الأكثر صلة.
• يمكن استخدام مزامنة أزواج القيمة الرئيسية في التطبيقات ذات بنية بيانات بسيطة، حيث تعتبر المتغيرات ذرية، أي.لا تنقسم إلى مكونات منطقية.يشبه هذا الخيار مزامنة المستندات بأكملها، حيث يمكن الكتابة فوق كل من القيمة والمستند بالكامل.ومع ذلك، من وجهة نظر المستخدم، فإن المستند عبارة عن كائن معقد يتكون من أجزاء كثيرة، ولكن زوج المفتاح والقيمة ليس سوى سلسلة قصيرة أو رقم.ولذلك، في هذه الحالة يمكننا استخدام استراتيجية أكثر بساطة لحل النزاع، مع الأخذ في الاعتبار القيمة الأكثر أهمية، إذا كانت آخر من تغير.
• يتم استخدام مزامنة البيانات المنظمة على شكل شجرة أو رسم بياني في التطبيقات الأكثر تعقيدًا حيث تكون كمية البيانات كبيرة بما يكفي لإرسال قاعدة البيانات بالكامل عند كل تحديث.في هذه الحالة، يجب حل الصراعات على مستوى الكائنات أو الحقول أو العلاقات الفردية.نحن نركز في المقام الأول على هذا الخيار.

لذلك، قمنا بتجميع معرفتنا في هذه المقالة والتي أعتقد أنها قد تكون مفيدة جدًا لجميع المهتمين بالموضوع => مزامنة البيانات في تطبيقات iOS المستندة إلى البيانات الأساسية (http://blog.denivip.ru/index.php/2014/04/data-syncing-in-core-data-based-ios-apps/?lang=en)

Answer 3

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

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

Answer 4

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

Answer 5

ولقد بنيت مثل هذا النظام للحصول على التطبيق قبل حوالي 8 سنوات، وأنا يمكن أن تشترك في طرق زوجين تطورت على أنها استخدام التطبيق نمت.

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

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

وأخيرا علمت أن UUIDs يمكن تجنب هذا، ولكن بحلول ذلك الوقت قاعدة البيانات الخاصة بي والحصول كبير جدا، وكنت أخشى أن التنفيذ الكامل UUID خلق مشكلة أداء. وذلك بدلا من استخدام UUIDs كاملة، بدأت باستخدام بشكل عشوائي، مفاتيح 8 حرف أبجدي رقمي كما معرفات، وتركت التعليمات البرمجية الموجودة بلدي في المكان للتعامل مع الصراعات. في مكان ما بين بلدي مفاتيح 8 أحرف الحالية و36 حرفا من UUID يجب أن يكون هناك بقعة الحلو من شأنها أن تقضي الصراعات دون سخام لا لزوم لها، ولكن منذ لدي بالفعل رمز وحل النزاعات، وأنه لم يكن أولوية لهذه التجربة مع ذلك .

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

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

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

Answer 6

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

لمرآة قاعدة البيانات، بعض الأطر على شبكة الإنترنت تستخدم قاعدة بيانات مصغرة المحلية لمزامنة قاعدة جانب الملقم المحلي في قاعدة بيانات المتصفح، ويدعم مزامنة جزئية. تحقق meteror .