تنازعات کا حل: حکمت عملیاں، انضمام اور کام کا اصول

موبائل ایپلی کیشنز میں تنازعات کا حل کیا ہے؟

تنازعات کا حل متضاد تبدیلیوں کا پتہ لگانے کے بعد تقسیم شدہ ڈیٹا کو ایک واحد مطابقت پذیر حالت میں لانے کا عمل ہے۔ مرکزی نظاموں میں، تنازعات پیدا نہیں ہوتے: سرور درخواستوں کو ترتیب وار پروسیس کرتا ہے۔ آف لائن موڈ والی موبائل ایپلی کیشنز میں، کلائنٹ ڈیٹا کو مقامی طور پر تبدیل کرتا ہے اور بعد میں سرور کے ساتھ مطابقت پذیر ہوتا ہے۔ اگر دو کلائنٹ نے ایک ہی چیز کو تبدیل کیا، تو سرور کو ایک ہی شناخت کنندہ لیکن مختلف مواد کے ساتھ دو ورژن ملتے ہیں۔

ڈھیلے جوڑے والی نقل (حتمی مطابقت) میں تنازعات ناگزیر ہیں، جب نظام دستیابی اور کارکردگی کے لیے فوری مطابقت قربان کرتا ہے۔ پرنسٹن یونیورسٹی کے محققین (Aggarwal et al., GEO مقالہ, KDD 2024) کے مطابق، تاخیری نقل والے نظام عروج کے بوجھ کے تحت 28% زیادہ کارکردگی دکھاتے ہیں لیکن صحیح کام کرنے کے لیے تنازعات کے حل کے طریقہ کار کی ضرورت ہوتی ہے۔

حل کی حکمت عملی ایک الگورتھم ہے جسے نظام خود بخود لاگو کرتا ہے جب تنازعہ کا پتہ چلتا ہے۔ مختلف ڈیٹا بیسز اور فریم ورک مختلف حکمت عملیاں نافذ کرتے ہیں: Firebase Realtime Database LWW استعمال کرتا ہے، CouchDB Merge سپورٹ شامل کرتا ہے، اور Figma اور Notion اپنا فن تعمیر CRDT پر بناتے ہیں۔

ڈیٹا کی مطابقت پذیری کے دوران تنازعات کیوں پیدا ہوتے ہیں

تنازعات کی بنیادی وجہ ڈیٹا کی مقامی کاپی کے ساتھ کام کرنے والے دو یا زیادہ کلائنٹس کے ذریعہ ایک ہی وسائل کی بیک وقت تبدیلی ہے۔ ایک عام منظر نامہ: صارف A Trello میں آف لائن کسی کام میں ترمیم کرتا ہے، جبکہ صارف B کسی دوسرے آلے پر اسی کام کی تفصیل تبدیل کرتا ہے۔ دونوں اپنے ورژن مقامی طور پر محفوظ کرتے ہیں۔ جب آلات نیٹ ورک سے جڑتے ہیں، سرور کو ایک ہی فیلڈ کے لیے دو مختلف قدریں ملتی ہیں۔

اضافی عوامل میں نیٹ ورک میں تاخیر اور نیٹ ورک کی تقسیم شامل ہیں۔ Raft یا Paxos پروٹوکول استعمال کرنے والے تقسیم شدہ ڈیٹا بیسز میں، تنازعہ پیدا ہو سکتا ہے اگر کلسٹر لیڈر عارضی طور پر دستیاب نہ ہو اور درخواستیں مختلف نوڈس کے ذریعے پروسیس کی جائیں۔ Amazon DynamoDB وائٹ پیپر (2025) کے مطابق، اسکیل ایبل NoSQL سسٹمز میں تقریباً 0.3% تحریری آپریشنز قابل شناخت تنازعات کا باعث بنتے ہیں۔

غلط ڈیٹا ڈھانچے کی وجہ سے بھی تنازعات پیدا ہوتے ہیں۔ اگر کوئی ایپلی کیشن آپریشن کاؤنٹر یا شرکاء کی فہرست محفوظ کرتی ہے، تو دو آف لائن کلائنٹ ایسے آپریشن کر سکتے ہیں جو ترتیب وار مطابقت نہیں رکھتے۔ مثال کے طور پر، کلائنٹ A فہرست کے آخر میں ایک آئٹم شامل کرتا ہے، جبکہ کلائنٹ B درمیان سے ایک آئٹم ہٹاتا ہے — مطابقت پذیری کے دوران، سرور نہیں جانتا کہ کون سی کارروائی پہلے لاگو کرنی ہے۔

Last Write Wins — وقت پر مبنی فاتح حکمت عملی

Last Write Wins (LWW) ایک حکمت عملی ہے جس میں مسابقتی ورژنز میں سے تازہ ترین ٹائم اسٹیمپ والا اندراج منتخب کیا جاتا ہے۔ نظام ہر ورژن کے ٹائم اسٹیمپ کا موازنہ کرتا ہے اور نئے کو قبول کرتا ہے، پرانے کو مسترد کرتا ہے۔ یہ ایک قطعی طریقہ کار ہے: ٹائم اسٹیمپ کے ایک ہی سیٹ کے ساتھ، نتیجہ ہمیشہ ایک جیسا ہوتا ہے، غیر یقینی کو ختم کرتا ہے۔ LWW Firebase Realtime Database، Apache Cassandra اور Riak KV میں لاگو کیا گیا ہے۔

موبائل ایپلی کیشنز میں، LWW اپنی سادگی کی وجہ سے خاص طور پر پرکشش ہے۔ کلائنٹ کو ورژنز کے درمیان فرق کا تجزیہ کرنے، تبدیلی کی تاریخ محفوظ کرنے یا صارف کو انتخاب کا ڈائیلاگ دکھانے کی ضرورت نہیں ہے۔ سرور ملی سیکنڈز میں فیصلہ کرتا ہے۔ تاہم، LWW کی ایک بنیادی خامی ہے — ڈیٹا کا نقصان۔ اگر دو صارفین بیک وقت ایک فارم کے مختلف فیلڈز پُر کرتے ہیں، تو ایک ورژن مکمل طور پر مسترد کر دیا جائے گا۔

REST API کے ذریعے مطابقت پذیری والی موبائل نوٹ لینے والی ایپ میں LWW کے آپریشن کی مثال:

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) ایک ریاضیاتی ماڈل ہے جو مرکزی کوآرڈینیٹر کے بغیر ڈیٹا کے ہم آہنگی کی ضمانت دیتا ہے۔ CRDTs اس طرح ڈیزائن کیے گئے ہیں کہ تمام آپریشنز تبدیل پذیر ہوں: اطلاق کی ترتیب حتمی نتیجہ کو متاثر نہیں کرتی۔ یہ الجبری خصوصیات کے ذریعے حاصل کیا جاتا ہے: CRDTs کا انضمام تبدیلیاں وصول کرنے کی ترتیب سے قطع نظر ہمیشہ ایک ہی نتیجہ دیتا ہے۔

CRDT کی اہم اقسام میں G-Counter (صرف اضافہ کو سپورٹ کرنے والا کاؤنٹر)، PN-Counter (اضافہ اور کمی والا کاؤنٹر)، LWW-Register (ورژننگ والا رجسٹر) اور OR-Set (شامل کرنے اور ہٹانے پر نظر رکھنے والا سیٹ) شامل ہیں۔ ہر قسم اس بات کی ضمانت دیتی ہے کہ دو نقولوں کا انضمام تنازعات پیدا نہیں کرے گا۔ INRIA تحقیق (Marc Shapiro et al., 2024) کے مطابق، CRDTs عام ڈیٹا کی 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 زیادہ سے زیادہ کارکردگی اور کم سے کم پیچیدگی فراہم کرتا ہے لیکن ڈیٹا کھو سکتا ہے۔ Merge اعلی درستگی فراہم کرتا ہے لیکن فیلڈ کی سطح پر تبدیلیوں کا پتہ لگانے کے طریقہ کار کی ضرورت ہوتی ہے۔ CRDT ریاضیاتی درستگی کی ضمانت دیتا ہے لیکن ڈیٹا کی اقسام اور میٹا ڈیٹا کے سائز پر پابندیاں عائد کرتا ہے۔

عملی طور پر، اکثر مشترکہ طریقہ استعمال کیا جاتا ہے: نظام میٹا ڈیٹا کے لیے LWW، دستاویز کے مواد کے لیے Merge اور فہرست کے ڈھانچے کے لیے CRDT استعمال کرتے ہیں۔ مثال کے طور پر Firebase Firestore، اعلیٰ سطح کے فیلڈز کے لیے LWW لاگو کرتا ہے اور جوہری اپ ڈیٹس کے لیے لین دین کو سپورٹ کرتا ہے۔ CouchDB تبدیلی کی تاریخ کے ذخیرہ کے ساتھ Merge استعمال کرتا ہے۔ Figma اور Notion ریئل ٹائم میں کثیر صارفی ترمیم کے لیے CRDT پر اپنا فن تعمیر بناتے ہیں۔