نمط لمزامنة قوائم الكائن بين أجهزة الكمبيوتر (في C ++)؟

Question

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

وهذا سيكون طوبولوجيا نجمة - هناك سيد المركزي، والباقي عملاء

ولدي مفهوم الدورة، بحيث يمكن تخزين البيانات عن كل عميل.

هل هناك نمط التصميم الجيد لمتابعة لهذا؟ حتى أفضل، وهناك (قالب مقرها؟) مكتبة التي من شأنها أن التعامل مع طلب الحاوية ما الذي تغير منذ العميل X جاء من قبل ويحصل على هذا دلتا لترسل؟

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

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

هل هذا النمط المعروف؟ أي اقتراحات إضافية؟

Answer 1

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

هل يمكن أن ننظر أيضا في نمط المراقب و <لأ href = "HTTP: / /en.wikipedia.org/wiki/Publish/subscribe "يختلط =" نوفولو noreferrer "> نشر / الاشتراك .

Answer 2

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

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

ووAPI librsync بسيط، ونقل بيانات التوقيع / دلتا فعال نسبيا.

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

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