संघर्ष समाधान: रणनीतियाँ, विलय और कार्य सिद्धांत

मोबाइल एप्लिकेशन में संघर्ष समाधान क्या है?

संघर्ष समाधान विरोधाभासी परिवर्तनों का पता लगने के बाद वितरित डेटा को एक एकल सुसंगत स्थिति में लाने की प्रक्रिया है। केंद्रीकृत सिस्टम में, संघर्ष उत्पन्न नहीं होते: सर्वर अनुरोधों को क्रमिक रूप से संसाधित करता है। ऑफ़लाइन मोड वाले मोबाइल एप्लिकेशन में, क्लाइंट डेटा को स्थानीय रूप से संशोधित करता है और बाद में सर्वर के साथ सिंक्रोनाइज़ करता है। यदि दो क्लाइंट ने एक ही ऑब्जेक्ट को संशोधित किया, तो सर्वर को समान पहचानकर्ता लेकिन अलग सामग्री वाले दो संस्करण प्राप्त होते हैं।

ढीली-युग्मित प्रतिकृति (अंतिम सुसंगतता) में संघर्ष अपरिहार्य हैं, जब सिस्टम उपलब्धता और प्रदर्शन के लिए तत्काल सुसंगतता का त्याग करता है। प्रिंसटन विश्वविद्यालय के शोधकर्ताओं (Aggarwal et al., GEO paper, 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 फ़ंक्शन टाइमस्टैम्प की तुलना करता है और वर्तमान संस्करण लौटाता है। जब टाइमस्टैम्प बराबर होते हैं (जो उच्च लेखन आवृत्ति पर होता है), आमतौर पर स्थानीय संस्करण जीतता है।

Merge Strategy — संघर्षशील संस्करणों का विलय

Merge Strategy एक दृष्टिकोण है जहां सिस्टम किसी एक संस्करण को पूरी तरह से नहीं छोड़ता बल्कि दोनों के परिवर्तनों को एक सुसंगत स्थिति में संयोजित करने का प्रयास करता है। यह 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 उन एप्लिकेशन के लिए इष्टतम है जहां नवीनतम संस्करण को हमेशा प्राथमिकता होती है — समाचार फ़ीड, सूचनाएं, स्थितियाँ। Merge Strategy संरचित दस्तावेज़ों के लिए उपयुक्त है जहां प्रत्येक फ़ील्ड स्वतंत्र है — उपयोगकर्ता प्रोफ़ाइल, फ़ॉर्म, कॉन्फ़िगरेशन। CRDT वितरित सिस्टम में सहयोगी संपादन, सूचियों और काउंटरों के लिए आदर्श है।

रणनीति चुनते समय, तीन कारकों का मूल्यांकन किया जाता है: डेटा सुसंगतता, प्रदर्शन और कार्यान्वयन जटिलता। LWW अधिकतम प्रदर्शन और न्यूनतम जटिलता प्रदान करता है लेकिन डेटा खो सकता है। Merge उच्च सटीकता प्रदान करता है लेकिन फ़ील्ड स्तर पर परिवर्तनों का पता लगाने के तंत्र की आवश्यकता होती है। CRDT गणितीय शुद्धता की गारंटी देता है लेकिन डेटा प्रकारों और मेटाडेटा आकार पर सीमाएं लगाता है।

व्यवहार में, अक्सर संयुक्त दृष्टिकोण का उपयोग किया जाता है: सिस्टम मेटाडेटा के लिए LWW, दस्तावेज़ सामग्री के लिए Merge और सूची संरचनाओं के लिए CRDT का उपयोग करते हैं। Firebase Firestore, उदाहरण के लिए, उच्च-स्तरीय फ़ील्ड के लिए LWW लागू करता है और परमाणु अद्यतन के लिए लेन-देन का समर्थन करता है। CouchDB परिवर्तन इतिहास भंडारण के साथ Merge का उपयोग करता है। Figma और Notion वास्तविक समय में बहु-उपयोगकर्ता संपादन के लिए CRDT पर अपनी वास्तुकला बनाते हैं।