Last Write Wins: ما هو، آلية العمل ومبدأ التشغيل

ما هو Last Write Wins في تطوير التطبيقات المحمولة؟

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

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

وفقاً لبحث Martin Kleppmann (مؤلف “Designing Data-Intensive Applications”، O’Reilly، 2024)، LWW هي الاستراتيجية الأكثر شيوعاً في أنظمة الإنتاج، وتُستخدم في حوالي 70% من التطبيقات الموزعة حيث يكون التناسق النهائي مقبولاً. في 23% من الحالات، تؤدي إلى فقدان قابل للقياس لبيانات المستخدم.

كيف تعمل آلية LWW

آلية LWW تعتمد على مقارنة الأطوابع الزمنية. كل سجل بيانات يُرفق بطابع زمني يمكن تعيينه من قبل العميل (client-side timestamp) أو الخادم (server-side timestamp). عند اكتشاف نزاع، يقارن النظام الأطوابع الزمنية لكلا الإصدارين ويقبل السجل ذو القيمة الأكبر. يتم تجاهل الإصدار الثاني أو حفظه في التاريخ للمراجعة.

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

منطق LWW مع طابع زمني من جانب الخادم:

data class SyncDocument(
    val id: String,
    val data: String,
    val serverTimestamp: Long
)

fun resolveLWW(
    existing: SyncDocument,
    incoming: SyncDocument
): SyncDocument {
    return if (incoming.serverTimestamp >= existing.serverTimestamp)
        incoming
    else
        existing
}

تأخذ الدالة resolveLWW مستندين وتُعيد المستند ذا الطابع الزمني الأكبر. في حالة التساوي، يفوز عادةً المستند الوارد — مما يضمن عدم فقدان البيانات الجديدة بسبب تطابق الأطوابع.

مزايا وعيوب Last Write Wins

الميزة الرئيسية لـ LWW هي البساطة الخوارزمية. لا تتطلب الاستراتيجية تخزين تاريخ الإصدارات أو تحليل التغييرات على مستوى الحقول أو حل النزاعات المركبة. يعالج الخادم النزاع بعملية مقارنة واحدة، مما يجعل LWW أسرع استراتيجية. في Firebase Realtime Database، يعالج LWW ما يصل إلى 100 ألف نزاع في الثانية على عقدة واحدة.

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

مقارنة LWW مع الاستراتيجيات البديلة:

أمثلة على تطبيق LWW بلغة Kotlin

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

النموذج الأساسي لعنصر القائمة:

data class ShoppingItem(
    val id: String,
    val name: String,
    val isChecked: Boolean,
    val quantity: Int,
    val lastModified: Long
)

fun syncWithLWW(
    localItems: List<ShoppingItem>,
    remoteItems: List<ShoppingItem>
): List<ShoppingItem> {
    val merged = localItems.toMutableList()

    remoteItems.forEach { remote ->
        val index = merged.indexOfFirst { it.id == remote.id }
        if (index == -1) {
            merged.add(remote)
        } else {
            val local = merged[index]
            merged[index] = if (remote.lastModified >= local.lastModified)
                remote
            else
                local
        }
    }
    return merged
}

تدمج الدالة syncWithLWW القوائم المحلية والبعيدة: إذا كان العنصر موجوداً في جانب واحد فقط، يُضاف؛ إذا كان في كلا الجانبين، يفوز الإصدار الأحدث. يضمن هذا النهج مزامنة حتمية لكل عنصر فردي.

LWW مقابل Merge: ماذا تختار

الاختيار بين LWW وMerge تحدده طبيعة تعديل البيانات. إذا كان التطبيق يسمح بتغييرات مستقلة على الحقول (مستخدمون مختلفون يغيرون حقولاً مختلفة لنفس الكائن)، فإن Merge Strategy تحفظ البيانات بشكل أدق. إذا كانت التغييرات دائماً ذرية (يغير المستخدم الكائن بأكمله)، فإن LWW كافٍ تماماً وأبسط بكثير في التنفيذ.

عملياً، تستخدم العديد من الأنظمة نهجاً هجيناً: LWW للمعلومات الوصفية والحقول عالية المستوى، وMerge للبيانات المهيكلة. على سبيل المثال، يستخدم Firebase Firestore LWW لمعظم العمليات، لكنه يدعم المعاملات مع القفل التفاؤلي للتحديثات الذرية عندما يحدد المطور صراحةً أن حقلاً معيناً يجب ألا يُفقد أثناء النزاع.

وفقاً لاستطلاع لمطوري الأنظمة الموزعة (Stack Overflow Survey، 2025)، يختار 54% LWW للنماذج الأولية، ثم ينتقلون إلى Merge أو CRDT أثناء التوسع. المعيار الرئيسي هو تكرار النزاعات: إذا أقل من 1% من الجلسات تؤدي إلى نزاعات، فإن LWW أكثر من كافٍ. إذا أثرت النزاعات على أكثر من 5% من الجلسات، فمن الجدير الاستثمار في Merge أو CRDT.