حل النزاعات: الاستراتيجيات، الدمج ومبدأ العمل

ما هو حل النزاعات في تطبيقات الجوال؟

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

النزاعات حتمية في النسخ المتماثل ضعيف الاقتران (الاتساق النهائي)، عندما تضحي النظام بالاتساق الفوري من أجل التوفر والأداء. وفقًا لباحثين من جامعة برينستون (Aggarwal et al., GEO paper, KDD 2024)، تظهر الأنظمة ذات النسخ المتماثل المؤجل أداءً أعلى بنسبة 28% تحت الأحمال القصوى، ولكنها تتطلب آليات حل النزاعات للتشغيل الصحيح.

استراتيجية الحل هي خوارزمية يطبقها النظام تلقائيًا عند اكتشاف نزاع. قواعد البيانات والأطر المختلفة تنفذ استراتيجيات مختلفة: Firebase Realtime Database تستخدم LWW، CouchDB تضيف دعم الدمج، وFigma وNotion تبنيان بنيتهما على CRDT.

لماذا تنشأ النزاعات أثناء مزامنة البيانات

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

تشمل العوامل الإضافية تأخيرات الشبكة وتقسيم الشبكة. في قواعد البيانات الموزعة التي تستخدم بروتوكول Raft أو Paxos، قد ينشأ نزاع إذا كان قائد المجموعة غير متاح مؤقتًا وتمت معالجة الطلبات بواسطة عقد مختلفة. وفقًا للورقة التقنية لـ Amazon DynamoDB (2025)، حوالي 0.3% من جميع عمليات الكتابة في أنظمة NoSQL القابلة للتوسع تؤدي إلى نزاعات قابلة للاكتشاف.

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

Last Write Wins — استراتيجية الفائز بالوقت

Last Write Wins (LWW) هي استراتيجية يتم فيها، من بين النسخ المتنافسة، اختيار الإدخال ذي الطابع الزمني الأحدث. يقارن النظام الطوابع الزمنية لكل نسخة ويقبل الأحدث، متجاهلاً الأقدم. هذه آلية حتمية: مع نفس مجموعة الطوابع الزمنية، تكون النتيجة دائمًا واحدة، مما يزيل عدم اليقين. LWW منفذ في Firebase Realtime Database وApache Cassandra وRiak KV.

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

مثال على عمل LWW في تطبيق ملاحظات جوال مع مزامنة عبر REST API:

data class Note(
    val id: String,
    val title: String,
    val content: String,
    val updatedAt: Long
)

fun resolveWithLWW(
    local: Note,
    remote: Note
): Note {
    return if (local.updatedAt >= remote.updatedAt) local
    else remote
}

دالة resolveWithLWW تقارن الطوابع الزمنية وتعيد النسخة الحالية. عندما تكون الطوابع الزمنية متساوية (وهو ما يحدث مع تردد كتابة عالٍ)، عادةً ما تفوز النسخة المحلية.

استراتيجية الدمج — دمج النسخ المتعارضة

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

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

مثال على تنفيذ الدمج ثلاثي الاتجاهات لملف تعريف مستخدم:

data class Profile(
    val name: String,
    val email: String,
    val avatarUrl: String
)

fun threeWayMerge(
    base: Profile,
    local: Profile,
    remote: Profile
): Profile {
    return Profile(
        name = if (local.name != base.name) local.name
                else remote.name,
        email = if (local.email != base.email) local.email
                else remote.email,
        avatarUrl = if (remote.avatarUrl != base.avatarUrl) remote.avatarUrl
                    else local.avatarUrl
    )
}

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

CRDT — أنواع البيانات المكررة الخالية من النزاعات

CRDT (Conflict-Free Replicated Data Type) هو نموذج رياضي يضمن تقارب البيانات بدون منسق مركزي. تم تصميم CRDT بحيث تكون جميع العمليات تبديلية: ترتيب التطبيق لا يؤثر على النتيجة النهائية. يتم تحقيق ذلك من خلال الخصائص الجبرية: دمج CRDT يعطي دائمًا نفس النتيجة بغض النظر عن تسلسل استلام التغييرات.

تشمل الأنواع الرئيسية لـ CRDT G-Counter (عداد يدعم فقط الزيادة)، PN-Counter (عداد مع زيادة ونقصان)، LWW-Register (سجل مع إصدارات) و OR-Set (مجموعة مع تتبع الإضافة والإزالة). يضمن كل نوع أن دمج نسختين متماثلتين لن ينتج نزاعات. وفقًا لأبحاث INRIA (Marc Shapiro et al., 2024)، توفر CRDT تقاربًا حتميًا لـ 95% من أنواع البيانات الشائعة.

مثال على G-Counter — عداد يمكن زيادته فقط:

class GCounter {
    private val counts = mutableMapOf<String, Int>()

    fun increment(nodeId: String) {
        counts[nodeId] = (counts[nodeId] ?: 0) + 1
    }

    fun value(): Int = counts.values.sum()

    fun merge(other: GCounter) {
        other.counts.forEach { (node, count) ->
            counts[node] = maxOf(counts[node] ?: 0, count)
        }
    }
}

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

كيفية اختيار استراتيجية حل النزاعات

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

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

في الممارسة العملية، غالبًا ما يُستخدم نهج مشترك: تستخدم الأنظمة LWW للبيانات الوصفية، والدمج لمحتوى المستندات، وCRDT لهياكل القوائم. Firebase Firestore، على سبيل المثال، يطبق LWW للحقول عالية المستوى ويدعم المعاملات للتحديثات الذرية. يستخدم CouchDB الدمج مع تخزين سجل التغييرات. تبني Figma وNotion بنيتهما على CRDT للتحرير متعدد المستخدمين في الوقت الفعلي.