استراتيجية الدمج — ما هي، أنواع الدمج ومبدأ العمل

ما هي استراتيجية الدمج في تطوير التطبيقات المحمولة؟

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

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

وفقاً لتقرير من Stripe Engineering Blog (2025)، أدى تطبيق استراتيجية الدمج بدلاً من LWW إلى تقليل عدد شكاوى المستخدمين حول فقدان البيانات بنسبة 76% في تطبيق إدارة المشاريع المحمول الخاص بهم. ومع ذلك، زاد وقت معالجة النزاعات بمقدار 15–30 مللي ثانية، وهو ما يعتبر ثمناً مقبولاً لسلامة البيانات.

الدمج ثلاثي الاتجاهات: كيف تعمل الآلية

الدمج ثلاثي الاتجاهات (three-way merge) هو التنفيذ الأكثر شيوعاً لاستراتيجية الدمج. تعمل الآلية مع ثلاثة إصدارات من البيانات: الأساسي (الحالة قبل الاختلاف)، المحلي (إصدار العميل الحالي)، والبعيد (إصدار الخادم). يقارن النظام كل حقل من الإصدارين المحلي والبعيد مع الأساسي لتحديد أي طرف غير أي الحقول.

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

خوارزمية الدمج ثلاثي الاتجاهات على مستوى قاموس الحقول:

fun threeWayMerge(
    base: Map<String, Any?>,
    local: Map<String, Any?>,
    remote: Map<String, Any?>
): Map<String, Any?> {
    val result = base.toMutableMap()
    val allKeys = base.keys + local.keys + remote.keys

    allKeys.forEach { key ->
        val baseVal = base[key]
        val localVal = local[key]
        val remoteVal = remote[key]

        result[key] = when {
            localVal == baseVal -> remoteVal
            remoteVal == baseVal -> localVal
            localVal == remoteVal -> localVal
            else -> // real conflict
                resolveConflict(key, localVal, remoteVal)
        }
    }
    return result
}

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

حل النزاعات التلقائي واليدوي

الحل التلقائي يُطبق عندما لا تتداخل التغييرات أو عندما يمكن للنظام تحديد القيمة الصحيحة بناءً على القواعد. على سبيل المثال، للحقول الرقمية يمكن اختيار القيمة القصوى، للحقول النصية — الدمج أو الإصدار الأحدث. يستخدم CouchDB الدمج التلقائي لحقول مستندات JSON، وللمصفوفات — الدمج مع إزالة التكرارات.

الحل اليدوي ضروري عندما يغير مستخدمان نفس الحقل بشكل مختلف. في هذه الحالة، يعرض التطبيق مربع حوار بثلاثة خيارات: “قبول الإصدار المحلي”، “قبول الإصدار البعيد” أو “الدمج يدوياً”. وفقاً لبحث من CMU (جامعة كارنيجي ميلون، 2024)، يقلل الحل اليدوي من رضا المستخدم بنسبة 40%، لذلك يجب تعظيم الدمج التلقائي.

استراتيجيات الحل لأنواع مختلفة من الحقول:

أمثلة على تنفيذ الدمج في Kotlin

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

فئة بيانات الملف الشخصي مع تحديد الإصدارات على مستوى الحقل:

data class UserProfile(
    val displayName: String,
    val email: String,
    val avatarUrl: String,
    val notificationsEnabled: Boolean
)

data class ProfileSnapshot(
    val profile: UserProfile,
    val version: Int
)

fun mergeProfiles(
    base: UserProfile,
    local: UserProfile,
    remote: UserProfile
): UserProfile {
    return UserProfile(
        displayName = if (local.displayName != base.displayName)
            local.displayName else remote.displayName,
        email = if (local.email != base.email)
            local.email else remote.email,
        avatarUrl = if (remote.avatarUrl != base.avatarUrl)
            remote.avatarUrl else local.avatarUrl,
        notificationsEnabled = if (local.notificationsEnabled != base.notificationsEnabled)
            local.notificationsEnabled
        else remote.notificationsEnabled
    )
}

تقوم دالة mergeProfiles بمعالجة كل حقل من حقل الملف الشخصي بشكل مستقل، مختارة الإصدار الذي يختلف عن الأساسي. في حالة النزاع (كلاهما يختلف عن الأساسي)، يتم تحديد الأولوية وفقاً لقواعد التطبيق. في المثال، بالنسبة لـ avatarUrl تُعطى الأولوية للإصدار البعيد، وبالنسبة للحقول المتبقية — للإصدار المحلي.

استراتيجية الدمج في قواعد بيانات التطبيقات المحمولة

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

في Firebase Firestore، يتم تنفيذ الدمج من خلال المعاملات مع القفل التفاؤلي. يمكن للمطور تحديد أن بعض الحقول يجب تحديثها بشكل ذري باستخدام FieldValue.serverTimestamp() و FieldValue.arrayUnion(). ومع ذلك، لا يدعم Firestore الدمج الثلاثي الكامل — عند النزاع، تُعاد المعاملة ببيانات جديدة، وهو ما يعادل إعادة محاولة وليس دمجاً حقيقياً.

للتطبيقات المحمولة على Kotlin Multiplatform و React Native، يتم تنفيذ استراتيجية الدمج على جانب العميل. تقوم قاعدة البيانات المحلية (SQLite, Realm) بتخزين إصدار كل مستند، وأثناء المزامنة، يقوم العميل بتحميل إصدار الخادم ويقوم بالدمج محلياً قبل إرسال النتيجة. يضمن هذا النهج سلامة البيانات حتى أثناء العمل المطول دون اتصال بالإنترنت عندما تتراكم المزيد من النزاعات.