Sync Engine: مفاهیم کلیدی، انواع و مکانیزم‌های عملکرد

موتور همگام‌سازی چیست؟

Sync Engine — یک لایه معماری بین پایگاه داده محلی و API راه‌دور است که جریان داده را در هر دو جهت مدیریت می‌کند. وظایف آن: ردیابی تغییرات، ارسال آنها به سرور، دریافت تغییرات از سرور و حل تعارضات. کاربر با داده‌های محلی کار می‌کند و Sync Engine آنها را به طور یکپارچه با سرور همگام می‌کند.

Sync Engine می‌تواند داخلی (Firebase Firestore, Couchbase Lite, Realm) یا سفارشی — نوشته شده برای منطق تجاری خاص — باشد. موتورهای داخلی قابلیت آماده offline-first و حل تعارض را ارائه می‌دهند. موتورهای سفارشی کنترل کامل بر قالب داده، پروتکل همگام‌سازی و سیاست تعارضات می‌دهند.

به گفته Sravan Kartik (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 (نظارت بر وضعیت همگام‌سازی). این انتزاع امکان تغییر پیاده‌سازی را بدون تغییر لایه Presentation فراهم می‌کند.

انواع همگام‌سازی: کامل، افزایشی و push

Full sync (همگام‌سازی کامل) — در هر جلسه کل مجموعه داده از سرور بارگیری می‌شود. پیاده‌سازی ساده، اما برای حجم‌های بزرگ غیرقابل قبول: بارگیری ۱۰۰۰۰ رکورد در هر بار باز کردن برنامه ترافیک و باتری مصرف می‌کند. Full sync برای داده‌های مرجع (لیست کشورها) با به‌روزرسانی نادر توجیه‌پذیر است.

Incremental sync (همگام‌سازی افزایشی) — فقط رکوردهایی که از آخرین همگام‌سازی تغییر کرده‌اند منتقل می‌شوند. سرور timestamp آخرین تغییر را برای هر رکورد یا کل مجموعه ذخیره می‌کند. کلاینت lastSyncTimestamp را ارسال می‌کند و فقط رکوردهایی با updated_at > این مقدار دریافت می‌کند. به گزارش Instagram Engineering (2024)، incremental sync حجم داده‌های منتقل شده را ۹۷٪ در مقایسه با full sync کاهش می‌دهد.

Push sync (همگام‌سازی مبتنی بر سرور) — سرور خود کلاینت را از نیاز به همگام‌سازی از طریق FCM (Firebase Cloud Messaging)، WebSocket یا SSE (Server-Sent Events) مطلع می‌کند. کلاینت منابع را برای polling دوره‌ای مصرف نمی‌کند. Push sync گزینه بهینه برای برنامه‌های بلادرنگ است: چت‌ها، اعلان‌ها، لایک‌ها. Google Firebase Firestore از WebSocket برای همگام‌سازی بلادرنگ با fallback خودکار به HTTP polling استفاده می‌کند.

رویکرد ترکیبی — ترکیبی از انواع: در شروع برنامه full sync برای داده‌های پایه، سپس incremental sync برای به‌روزرسانی‌ها و برای رویدادهای بحرانی — push sync از طریق FCM. این هم سرعت و هم صرفه‌جویی در منابع را فراهم می‌کند.

Incremental sync — نقاط بازرسی و دلتاها چگونه کار می‌کنند

نقطه بازرسی — مقداری که کلاینت بین جلسات همگام‌سازی ذخیره می‌کند. معمولاً این updated_at آخرین رکوردی است که با موفقیت همگام‌سازی شده است. در همگام‌سازی بعدی، کلاینت نقطه بازرسی را به سرور ارسال می‌کند و سرور تمام رکوردهایی با updated_at بعد از نقطه بازرسی را برمی‌گرداند. صفحه‌بندی مبتنی بر نشانگر — نسخه پیشرفته‌ای که سرور نشانگر (اشاره‌گر به صفحه بعد) را همراه با داده‌ها برمی‌گرداند.

همگام‌سازی دلتا — سرور تفاوت بین وضعیت فعلی داده و snapshots که کلاینت دیده را محاسبه می‌کند. به جای ارسال همه رکوردها، فقط عملیات‌ها (insert, update, delete) منتقل می‌شوند. این برای مجموعه‌های داده بزرگ که فقط چند رکورد تغییر کرده‌اند بسیار مؤثر است. Google Drive API (2025) از changes.list با pageToken برای همگام‌سازی دلتا فایل‌ها استفاده می‌کند.

استراتژی «دلتاهای تأخیری» — در کلاینت موبایل، تغییرات بلافاصله ارسال نمی‌شوند، بلکه در Offline Queue بافر می‌شوند. پس از رسیدن به آستانه (۱۰ عملیات یا ۳۰ ثانیه)، یک بسته دلتا تشکیل و به سرور ارسال می‌شود. به گزارش Dropbox Mobile Engineering (2024)، دسته‌بندی دلتاها تعداد درخواست‌های HTTP را ۶۵٪ کاهش داده و مصرف باتری را ۱۲٪ کاهش داده است.

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 هم timestamp و هم نشانگر صفحه‌بندی را برای لیست‌های طولانی ذخیره می‌کند. نقطه بازرسی دوپارامتری تضمین می‌کند که هیچ رکوردی در همگام‌سازی مجموعه‌های داده بزرگ از دست نرود یا تکراری نشود.

Push sync — همگام‌سازی فوری از طریق WebSocket و FCM

WebSocket — یک اتصال دائمی دوطرفه بین کلاینت و سرور. سرور به‌محض تغییر داده، به‌روزرسانی‌ها را ارسال می‌کند. WebSocket برای برنامه‌های بلادرنگ optimal است: چت‌ها، استریمینگ، کار مشارکتی. نکته منفی: مصرف باتری و ترافیک برای نگهداری اتصال (heartbeat). OkHttp WebSocket در اندروید و URLSessionWebSocketTask در iOS پیاده‌سازی‌های داخلی هستند.

Firebase Cloud Messaging (FCM) — اعلان‌های فشاری که سرور نه برای نمایش به کاربر، بلکه برای راه‌اندازی همگام‌سازی ارسال می‌کند. با دریافت silent push (data message)، برنامه بیدار می‌شود و Sync Engine را اجرا می‌کند. FCM به اتصال دائمی نیاز ندارد و برای اعلان‌های نادر مقرون‌به‌صرفه‌تر از WebSocket است.

SSE (Server-Sent Events) — کانال یک‌طرفه که سرور از طریق آن رویدادها را برای کلاینت ارسال می‌کند. پیاده‌سازی ساده‌تر از WebSocket، اما از ارتباط دوطرفه پشتیبانی نمی‌کند. EventSource API (JavaScript) و OkHttp SSE (Android) کتابخانه‌های محبوب هستند. SSE برای اعلان‌های داده جدید مناسب است، وقتی کلاینت نیازی به ارسال داده از طریق همان کانال ندارد.

به گزارش WhatsApp Engineering (2024)، Sync Engine آنها از ترکیب WebSocket برای جلسه فعال و FCM برای بیدار کردن برنامه در پس‌زمینه استفاده می‌کند: WebSocket پس از ۵ دقیقه عدم فعالیت قطع می‌شود و به‌روزرسانی‌های بعدی از طریق silent push تحویل داده می‌شوند.

Snapshot sync و نسخه‌بندی داده‌ها

Snapshot-based sync — سرور به طور دوره‌ای یک snapshots کامل از داده ایجاد می‌کند و به آن نسخه اختصاص می‌دهد. کلاینت شماره نسخه فعلی را ذخیره می‌کند. اگر قدیمی باشد — snapshots جدید را بارگیری می‌کند. این یک استراتژی ساده و قابل اعتماد است، اما برای تغییرات مکرر ناکارآمد است — هر بار کل مجموعه داده بارگیری می‌شود.

نسخه‌بندی در سطح رکورد — هر رکورد فیلد version دارد. در حین همگام‌سازی، کلاینت نسخه‌های همه رکوردها را ارسال می‌کند و سرور فقط رکوردهایی با نسخه تغییر یافته را برمی‌گرداند. این کارآمدتر از snapshot sync است، اما نیاز به ذخیره نسخه‌ها در کلاینت دارد. ساعت‌های برداری (Vector Clocks) — تکنیک پیشرفته برای سیستم‌های توزیع‌شده که هر گره نسخه خود را اختصاص می‌دهد و تعارضات بر اساس ترتیب جزئی حل می‌شوند.

Snapshot با diff افزایشی — رویکرد ترکیبی: snapshots کامل نادر (یک بار در روز) + همگام‌سازی افزایشی بین آنها. پس از غیبت طولانی، کلاینت snapshots را بارگیری می‌کند و در همگام‌سازی‌های مکرر — فقط دلتاها. رویکرد شبیه به گیت — هر commit داده یک هش دارد و کلاینت می‌داند از کدام commit شروع کند. این در 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)
    }

قانون حل نسخه‌ها: اگر نسخه‌ها مطابقت دارند — تغییری نیست. اگر نسخه محلی جدیدتر است — نسخه محلی برنده می‌شود. اگر نسخه سرور جدیدتر است — نسخه سرور برنده می‌شود. فقط در صورت نسخه‌های برابر اما داده‌های متفاوت — conflict resolver فراخوانی می‌شود. Last Write Wins با پرچم version — ساده‌ترین اما قابل اعتمادترین استراتژی.

چگونه Sync Engine برای برنامه موبایل بسازیم

مرحله ۱: تعریف مدل داده — کدام موجودیت‌ها همگام‌سازی می‌شوند، چقدر تغییر می‌کنند، چه حجمی دارند. برای هر موجودیت استراتژی (incremental / full / push) و تأخیر مجاز همگام‌سازی تعیین کنید.

مرحله ۲: انتخاب پروتکل — REST با نقاط بازرسی، GraphQL با Subscriptions یا gRPC با جریان دوطرفه. GraphQL Subscriptions انتخاب محبوبی برای برنامه‌های مدرن است: یک پروتکل هم برای pull و هم برای push. Apollo Client (2025) از همگام‌سازی آفلاین از طریق کش روی دستگاه پشتیبانی می‌کند.

مرحله ۳: پیاده‌سازی Offline Queue — ذخیره‌ساز محلی تغییرات با کلیدهای idempotency (به مقاله «Offline Queue» مراجعه کنید). صف بنیاد یک Sync Engine قابل اعتماد است: بدون آن همگام‌سازی تحویل تغییرات را تضمین نمی‌کند.

مرحله ۴: انتخاب conflict resolver — LWW برای موارد ساده، CRDT برای ویرایش مشترک، Custom merge برای منطق تجاری. قانون: resolver باید idempotent باشد — اعمال مکرر همان عملیات باید نتیجه یکسانی داشته باشد.

مرحله ۵: نظارت و معیارها — هر همگام‌سازی را ثبت کنید: تعداد رکوردها، زمان اجرا، تعداد تعارضات، خطاها. Firebase Crashlytics یا Sentry (2025) امکان ردیابی خطاهای همگام‌سازی در زمان واقعی را فراهم می‌کند.

به گزارش Realm Team (2024)، یک Sync Engine معمولی برای برنامه موبایل روزانه ۱۰۰–۵۰۰ همگام‌سازی در هر دستگاه پردازش می‌کند و به طور متوسط ۵۰–۲۰۰ کیلوبایت داده در هر جلسه منتقل می‌کند. بهینه‌سازی پروتکل — فشرده‌سازی Protobuf به جای JSON — حجم داده‌های منتقل شده را ۴۰–۶۰٪ دیگر کاهش می‌دهد.