محرك المزامنة: المفاهيم الأساسية والأنواع وآليات العمل

ما هو محرك المزامنة؟

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

يمكن أن يكون Sync Engine من نوع مُضمن (Firebase Firestore، Couchbase Lite، Realm) أو مخصص — مكتوب لمنطق أعمال محدد. توفر المحركات المضمنة وظائف offline-first جاهزة وحل التعارضات. توفر المحركات المخصصة تحكمًا كاملًا في تنسيق البيانات، بروتوكول المزامنة وسياسة التعارضات.

وفقًا لـ Sravana Karthik (2024)، مؤلف كتاب «Mobile Sync Engine Design Patterns»، فإن Sync Engine مخصص مبرر للتطبيقات ذات منطق أعمال معقد (المالية، الرعاية الصحية، IoT) حيث تكون قواعد الدمج المخصصة حاسمة. بالنسبة للسيناريوهات النمطية (الملاحظات، الدردشة، التغذية الإخبارية)، يكفي Firestore أو Realm المضمنين.

interface SyncEngine {
    suspend fun pull(lastSyncTimestamp: Long): SyncResult
    suspend fun push(operations: List<QueuedOperation>): PushResult
    suspend fun resolve(conflicts: List<Conflict>): ResolutionResult
    fun observeSyncState(): Flow<SyncState>
}

تصف هذه الواجهة أدنى عقد Sync Engine: pull (تحميل التغييرات من الخادم)، push (إرسال التغييرات المحلية)، resolve (معالجة التعارضات) و observe (مراقبة حالة المزامنة). يسمح هذا التجريد بتغيير التنفيذ دون تعديل طبقة العرض.

أنواع المزامنة: كاملة، تزايدية ودفعية

المزامنة الكاملة (Full sync) — كل جلسة تقوم بتحميل مجموعة البيانات بأكملها من الخادم. بسيطة في التنفيذ، ولكنها غير مقبولة للأحجام الكبيرة: تنزيل 10,000 سجل في كل مرة تفتح فيها التطبيق يستهلك البيانات والبطارية. المزامنة الكاملة مبررة لبيانات المرجع (قائمة الدول) ذات التحديثات النادرة.

المزامنة التزايدية (Incremental sync) — يتم نقل السجلات التي تم تغييرها منذ آخر مزامنة فقط. يخزن الخادم الطابع الزمني لآخر تغيير لكل سجل أو للمجموعة كاملة. يرسل العميل lastSyncTimestamp ويتلقى فقط السجلات ذات updated_at > تلك القيمة. وفقًا لـ Instagram Engineering (2024)، تقلل المزامنة التزايدية حجم البيانات المنقولة بنسبة 97% مقارنة بالمزامنة الكاملة.

المزامنة الدفعية (يبدءها الخادم) — يقوم الخادم نفسه بإشعار العميل بضرورة المزامنة عبر FCM (Firebase Cloud Messaging)، WebSocket أو SSE (Server-Sent Events). لا يهدر العميل الموارد على الاستعلام الدوري. المزامنة الدفعية هي الخيار الأمثل لتطبيقات الوقت الحقيقي: الدردشة، الإشعارات، الإعجابات. Google Firebase Firestore يستخدم WebSocket للمزامنة الفورية مع التحول التلقائي إلى HTTP polling.

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

المزامنة التزايدية — كيف تعمل نقاط التحكم والديلتات

نقطة التحكم (Checkpoint) — قيمة يخزنها العميل بين جلسات المزامنة. عادةً ما يكون هو updated_at آخر سجل تم تمامه بنجاح. في المزامنة التالية، يرسل العميل نقطة التحكم إلى الخادم، ويعيد الخادم جميع السجلات ذات updated_at بعد نقطة التحكم. الترقيم القائم على المؤشر (Cursor-based pagination) — نسخة متقدمة حيث يعيد الخادم مؤشرًا (مؤشرًا إلى الصفحة التالية) مع البيانات.

مزامنة الديلتا (Delta sync) — يحسب الخادم الفرق بين حالة البيانات الحالية واللقطة التي رآها العميل آخر مرة. بدلًا من إرسال جميع السجلات، يتم نقل العمليات فقط (إنشاء، تحديث، حذف). هذا فعال خاصة لمجموعات البيانات الكبيرة حيث تم تغيير عدة سجلات فقط. Google Drive API (2025) يستخدم changes.list مع pageToken لمزامنة الديلتا للملفات.

إستراتيجية «الديلتات المؤجلة» — على العميل المحمول، لا يتم إرسال التغييرات فورًا بل تُخزن مؤقتًا في طابور عدم الاتصال (Offline Queue). عند الوصول إلى الحد (10 عمليات أو 30 ثانية)، يتم تكوين حزمة ديلتا وإرسالها إلى الخادم. وفقًا لـ Dropbox Mobile Engineering (2024)، قام التجميع الدفعي للديلتات بتقليل عدد طلبات HTTP بنسبة 65% وخفض استهلاك البطارية بنسبة 12%.

data class SyncCheckpoint(
    val lastUpdated: Long,
    val pageToken: String?,
    val version: Int
)

suspend fun syncIncremental(checkpoint: SyncCheckpoint): SyncResult =
    api.pullChanges(
        since = checkpoint.lastUpdated,
        token = checkpoint.pageToken
    )

SyncCheckpoint يخزن كلًا من الطابع الزمني ومؤشر الترقيم للقوائم الطويلة. نقطة تحكم بمعلمين تضمن عدم تخطي أو تكرار أي سجل عند مزامنة مجموعات البيانات الكبيرة.

المزامنة الدفعية — مزامنة فورية عبر WebSocket و FCM

WebSocket — اتصال ثنائي الاتجاه مستمر بين العميل والخادم. يرسل الخادم التحديثات فورًا عند تغيير البيانات. WebSocket هو الخيار الأمثل لتطبيقات الوقت الحقيقي: الدردشة، البث، العمل التعاوني. السلبيات: استهلاك البطارية والبيانات للحفاظ على الاتصال (heartbeat). OkHttp WebSocket على Android و URLSessionWebSocketTask على iOS — تنفيذات مضمنة.

Firebase Cloud Messaging (FCM) — إشعارات دفع يرسلها الخادم ليس لعرضها على المستخدم بل لتحريك المزامنة. عند استلام silent push (رسالة بيانات)، يستيقظ التطبيق ويبدأ Sync Engine. لا يتطلب FCM اتصالًا دائمًا وهو أقل استهلاكًا من WebSocket للإشعارات النادرة.

SSE (Server-Sent Events) — قناة أحادية الاتجاه يرسل الخادم عبرها الأحداث إلى العميل. أبسط في التنفيذ من WebSocket، ولكنه لا يدعم الاتصال ثنائي الاتجاه. EventSource API (JavaScript) و OkHttp SSE (Android) — مكتبات شائعة. SSE مناسب للإشعارات حول البيانات الجديدة عندما لا يحتاج العميل إلى إرسال البيانات عبر نفس القناة.

وفقًا لـ WhatsApp Engineering (2024)، يستخدم Sync Engine خاصتهم مزيجًا من WebSocket للجلسات النشطة و FCM لتنبيه التطبيق في الخلفية: ينفصل WebSocket بعد 5 دقائق من عدم النشاط، وتتم تسليم التحديثات اللاحقة عبر silent push.

مزامنة اللقطات وتحديد إصدارات البيانات

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

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

لقطة مع فارق تزايدي (Snapshot with incremental diff) — نهج هجين: لقطات كاملة نادرة (مرة في اليوم) + مزامنة تزايدية بينها. عند البدء بعد غياب طويل، يحمل العميل لقطة، وأثناء المزامنات المتكررة — ديلتات فقط. نهج شبيه بـ Git — كل إرسال بيانات له تجزئة، ويعرف العميل من أي تجزئة يبدأ. هذا مطبق في Couchbase Lite Sync Gateway (2024) وهو المعيار الذهبي للموثوقية.

data class VersionedEntryT(
    val id: String,
    val data: T,
    val version: Long,
    val deleted: Boolean
)

fun SyncEngine.resolveVersion(local: VersionedEntry*, remote: VersionedEntry*): VersionedEntry* =
    when {
        local.version > remote.version -> local
        remote.version > local.version -> remote
        else -> resolveConflict(local, remote)
    }

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

كيف تبني Sync Engine لتطبيق محمول

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

الخطوة 2: اختيار بروتوكول — REST مع نقاط التحكم، GraphQL مع الاشتراكات، أو gRPC مع التدفق ثنائي الاتجاه. GraphQL Subscriptions — خيار شائع للتطبيقات الحديثة: بروتوكول واحد لكلا السحب والدفع. Apollo Client (2025) يدعم المزامنة بدون اتصال عبر الذاكرة المؤقتة على الجهاز.

الخطوة 3: تنفيذ طابور عدم الاتصال (Offline Queue) — تخزين محلي للتغييرات مع مفاتيح المطابقة (راجع مقال «Offline Queue»). الطابور هو أساس Sync Engine موثوق: بدونه، لا تضمن المزامنة توصيل التغييرات.

الخطوة 4: اختيار محل التعارضات — LWW للحالات البسيطة، CRDT للتحرير التعاوني، دمج مخصص لمنطق الأعمال. القاعدة: يجب أن يكون محل التعارضات مطابقًا — إعادة تطبيق نفس العملية يجب أن ينتج نفس النتيجة.

الخطوة 5: المراقبة والقياسات — تسجيل كل مزامنة: عدد السجلات، وقت التنفيذ، عدد التعارضات، الأخطاء. Firebase Crashlytics أو Sentry (2025) تسمح بتتبع أخطاء المزامنة في الوقت الحقيقي.

وفقًا لـ Realm Team (2024)، يقوم Sync Engine نموذجي للتطبيقات المحمولة بمعالجة 100–500 مزامنة في اليوم لكل جهاز، ينقل متوسطًا 50–200 كيلوبايت من البيانات في الجلسة. تحسين البروتوكول — استخدام ضغط Protobuf بدلاً من JSON — يقلل حجم البيانات المنقولة بنسبة 40–60% إضافية.