Sync Engine: asosiy tushunchalar, turlari va ishlash mexanizmlari

Sinxronizatsiya dvigateli nima?

Sync Engine — lokal ma'lumotlar bazasi va uzoq API o'rtasidagi arxitektura qatlami bo'lib, ma'lumot oqimini har ikki yo'nalishda boshqaradi. Uning vazifalari: o'zgarishlarni kuzatish, ularni serverga yuborish, serverdan o'zgarishlarni qabul qilish va konfliktlarni hal qilish. Foydalanuvchi lokal ma'lumotlar bilan ishlaydi, Sync Engine esa ularni server bilan uzluksiz sinxronizatsiya qiladi.

Sync Engine ichki (Firebase Firestore, Couchbase Lite, Realm) yoki maxsus — muayyan biznes mantiqi uchun yozilgan bo'lishi mumkin. Ichki dvigatellar tayyor offline-first funksionalligi va konfliktlarni hal qilishni taklif qiladi. Maxsus dvigatellar ma'lumot formati, sinxronizatsiya protokoli va konflikt siyosati ustidan to'liq nazorat beradi.

Sravan Kartik (2024), «Mobile Sync Engine Design Patterns» kitobi muallifining fikriga ko'ra, maxsus Sync Engine murakkab biznes mantiqiga ega ilovalar (moliya, tibbiyot, IoT) uchun asoslanadi, bu erda maxsus birlashtirish qoidalari muhim. Oddiy stsenariylar (eslatmalar, chatlar, lentalar) uchun ichki Firestore yoki Realm etarli.

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>
}

Ushbu interfeys Sync Engine uchun minimal shartnomani tavsiflaydi: pull (serverdan o'zgarishlarni yuklash), push (lokal o'zgarishlarni yuborish), resolve (konfliktlarni boshqarish) va observe (sinxronizatsiya holatini kuzatish). Ushbu abstraksiya Presentation qatlamini o'zgartirmasdan amalga oshirishni o'zgartirishga imkon beradi.

Sinxronizatsiya turlari: to'liq, qo'shimcha va push

Full sync (to'liq sinxronizatsiya) — har bir seansda serverdan barcha ma'lumotlar to'plami yuklanadi. Oddiy amalga oshirish, lekin katta hajmlar uchun qabul qilib bo'lmaydi: ilovani har ochishda 10 000 ta yozuvni yuklash trafik va batareyani sarflaydi. Full sync kamdan-kam yangilanadigan ma'lumotnomalar (mamlakatlar ro'yxati) uchun asoslanadi.

Incremental sync (qo'shimcha sinxronizatsiya) — oxirgi sinxronizatsiyadan beri o'zgartirilgan yozuvlar uzatiladi. Server har bir yozuv yoki butun to'plam uchun oxirgi o'zgarish vaqtini saqlaydi. Mijoz lastSyncTimestamp yuboradi va updated_at > bu qiymat bo'lgan yozuvlarni oladi. Instagram Engineering (2024) ma'lumotlariga ko'ra, incremental sync ma'lumot hajmini full sync bilan solishtirganda 97% ga kamaytiradi.

Push sync (server tomonidan boshlangan sinxronizatsiya) — server FCM (Firebase Cloud Messaging), WebSocket yoki SSE (Server-Sent Events) orqali mijozni sinxronizatsiya zarurligi haqida o'zi xabardor qiladi. Mijoz davriy pollinq uchun resurs sarflamaydi. Push sync real vaqt ilovalari uchun eng maqbul variant: chatlar, bildirishnomalar, layklar. Google Firebase Firestore real vaqt sinxronizatsiyasi uchun WebSocket-dan avtomatik HTTP polling fallback bilan foydalanadi.

Gibrid yondashuv — turlarning kombinatsiyasi: ilova ishga tushganda asosiy ma'lumotlar uchun full sync, keyin yangilanishlar uchun incremental sync, muhim hodisalar uchun esa FCM orqali push sync. Bu ham tezlik, ham resurs tejashni beradi.

Incremental sync — tekshirish nuqtalari va deltalari qanday ishlaydi

Tekshirish nuqtasi — mijoz sinxronizatsiya seanslari o'rtasida saqlaydigan qiymat. Odatda bu oxirgi muvaffaqiyatli sinxronizatsiya qilingan yozuvning updated_at maydoni. Keyingi sinxronizatsiyada mijoz tekshirish nuqtasini serverga yuboradi va server tekshirish nuqtasidan keyingi updated_at bo'lgan barcha yozuvlarni qaytaradi. Cursor-based pagination — server ma'lumotlar bilan birga kursorni (keyingi sahifa ko'rsatkichi) qaytaradigan rivojlangan versiya.

Delta sinxronizatsiyasi — server ma'lumotlarning joriy holati va mijoz ko'rgan nusxa o'rtasidagi farqni hisoblaydi. Barcha yozuvlarni yuborish o'rniga faqat operatsiyalar (insert, update, delete) uzatiladi. Bu faqat bir nechta yozuv o'zgargan katta ma'lumot to'plamlari uchun ayniqsa samarali. Google Drive API (2025) fayllarning delta sinxronizatsiyasi uchun pageToken bilan changes.list dan foydalanadi.

«Kechiktirilgan deltalar» strategiyasi — mobil mijozda o'zgarishlar darhol yuborilmaydi, balki Offline Queue'da buferlanadi. Chegaraga erishilganda (10 operatsiya yoki 30 soniya) delta paketi shakllantiriladi va serverga yuboriladi. Dropbox Mobile Engineering (2024) ma'lumotlariga ko'ra, deltalarni yig'ish HTTP so'rovlar sonini 65% ga kamaytirdi va batareya sarfini 12% ga pasaytirdi.

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 ham vaqt tamg'asini, ham uzun ro'yxatlar uchun sahifalash kursorni saqlaydi. Ikki parametrli tekshirish nuqtasi katta ma'lumot to'plamlarini sinxronizatsiya qilishda hech qanday yozuv o'tkazib yuborilmasligi yoki takrorlanmasligini kafolatlaydi.

Push sync — WebSocket va FCM orqali oniy sinxronizatsiya

WebSocket — mijoz va server o'rtasidagi doimiy ikki tomonlama aloqa. Server ma'lumot o'zgarishi bilan darhol yangilanishlarni yuboradi. WebSocket real vaqt ilovalari uchun maqbuldir: chatlar, striming, hamkorlikdagi ish. Kamchiligi: aloqani saqlash uchun batareya va trafik sarfi (heartbeat). Android'da OkHttp WebSocket va iOS'da URLSessionWebSocketTask — o'rnatilgan amalga oshirishlar.

Firebase Cloud Messaging (FCM) — server foydalanuvchiga ko'rsatish uchun emas, balki sinxronizatsiyani ishga tushirish uchun yuboradigan push bildirishnomalari. Silent push (data message) qabul qilinganda ilova uyg'onadi va Sync Engine'ni ishga tushiradi. FCM doimiy aloqani talab qilmaydi va kamdan-kam bildirishnomalar uchun WebSocket'dan tejamkorroq.

SSE (Server-Sent Events) — server mijozga hodisalarni yuboradigan bir tomonlama kanal. WebSocket'dan soddaroq, ammo ikki tomonlama aloqani qo'llab-quvvatlamaydi. EventSource API (JavaScript) va OkHttp SSE (Android) — mashhur kutubxonalar. SSE mijoz xuddi shu kanal orqali ma'lumot qaytarishi shart bo'lmaganda yangi ma'lumotlar haqida bildirishnomalar uchun mos keladi.

WhatsApp Engineering (2024) ma'lumotlariga ko'ra, ularning Sync Engine faol seans uchun WebSocket va ilovani fonda uyg'otish uchun FCM kombinatsiyasidan foydalanadi: WebSocket 5 daqiqa harakatsizlikdan keyin o'chadi va keyingi yangilanishlar silent push orqali yetkaziladi.

Snapshot sync va ma'lumotlarni versiyalash

Snapshot-based sync — server vaqti-vaqti bilan ma'lumotlarning to'liq nusxasini (snapshot) yaratadi va unga versiya beradi. Mijoz joriy versiya raqamini saqlaydi. Agar eskirgan bo'lsa — yangi nusxani yuklaydi. Bu oddiy va ishonchli strategiya, ammo tez-tez o'zgarishlar uchun samarasiz — har safar to'liq ma'lumot to'plami yuklanadi.

Yozuv darajasida versiyalash — har bir yozuv version maydoniga ega. Sinxronizatsiya paytida mijoz barcha yozuvlarning versiyalarini yuboradi va server faqat versiyasi o'zgargan yozuvlarni qaytaradi. Bu snapshot sync'dan samaraliroq, ammo mijozda versiyalarni saqlashni talab qiladi. Vector Clocks — taqsimlangan tizimlar uchun ilg'or texnika, bu erda har bir tugun o'z versiyasini belgilaydi va konfliktlar qisman tartibda hal qilinadi.

Qo'shimcha diff bilan snapshot — gibrid yondashuv: kamdan-kam to'liq nusxa (kuniga bir marta) + ular orasida incremental sync. Uzoq vaqt yo'qligidan keyin mijoz nusxani yuklaydi, tez-tez sinxronizatsiyalarda esa faqat deltalarni. Git'ga o'xshash yondashuv — har bir ma'lumot commit'ining xeshi bor va mijoz qaysi commit'dan boshlashni biladi. Bu Couchbase Lite Sync Gateway (2024) da amalga oshirilgan va ishonchlilik standartidir.

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)
    }

Versiyalarni hal qilish qoidasi: versiyalar mos kelsa — o'zgarish yo'q. Agar lokal versiya yangiroq bo'lsa — lokal g'alaba qozonadi. Agar server versiyasi yangiroq bo'lsa — server g'alaba qozonadi. Faqat teng versiyalar, ammo turli ma'lumotlar bo'lganda conflict resolver chaqiriladi. Last Write Wins version flag bilan — eng oddiy, ammo ishonchli strategiya.

Mobil ilova uchun Sync Engine qanday quriladi

1-qadam: Ma'lumot modelini aniqlang — qaysi ob'ektlar sinxronizatsiya qilinadi, qanchalik tez-tez o'zgaradi, hajmi qancha. Har bir ob'ekt uchun strategiya (incremental / full / push) va ruxsat etilgan sinxronizatsiya kechikishi belgilanadi.

2-qadam: Protokolni tanlang — REST tekshirish nuqtalari bilan, GraphQL Subscriptions yoki gRPC ikki tomonlama oqim bilan. GraphQL Subscriptions — zamonaviy ilovalar uchun mashhur tanlov: ham pull, ham push uchun bitta protokol. Apollo Client (2025) qurilmadagi kesh orqali offline sinxronizatsiyani qo'llab-quvvatlaydi.

3-qadam: Offline Queue'ni amalga oshiring — idempotency kalitlari bilan o'zgarishlarning lokal xotirasi (qarang: «Offline Queue» maqolasi). Navbat ishonchli Sync Engine'ning asosidir: usiz sinxronizatsiya o'zgarishlarni yetkazib berishni kafolatlamaydi.

4-qadam: Conflict resolver'ni tanlang — oddiy holatlar uchun LWW, birgalikda tahrirlash uchun CRDT, biznes mantiqi uchun Custom merge. Qoida: resolver idempotent bo'lishi kerak — bir xil operatsiyani takroriy qo'llash bir xil natijani berishi kerak.

5-qadam: Monitoring va metrikalar — har bir sinxronizatsiyani qayd eting: yozuvlar soni, bajarilish vaqti, konfliktlar soni, xatolar. Firebase Crashlytics yoki Sentry (2025) real vaqtda sinxronizatsiya xatolarini kuzatish imkonini beradi.

Realm Team (2024) ma'lumotlariga ko'ra, mobil ilova uchun odatdagi Sync Engine qurilmada kuniga 100–500 sinxronizatsiyani qayta ishlaydi, har seansda o'rtacha 50–200 KB ma'lumot uzatadi. Protokol optimallashtirish — JSON o'rniga Protobuf siqish — uzatiladigan ma'lumot hajmini yana 40–60% ga kamaytiradi.