Offline Queue: printsiplar, strategiyalar va ishlash mexanizmlari

Oflayn navbat nima?

Offline Queue qurilma tarmoqqa ulanish imkoniga ega bo‘lmaganda ilova lokal saqlaydigan tartiblangan operatsiyalar to‘plamidir (yaratish, yangilash, o‘chirish). Ulanish tiklanib bo‘lgach, navbat operatsiyalarni foydalanuvchi bajargan tartibda serverga yuboradi.

Stsenariyni tasavvur qiling: messenjer foydalanuvchisi metroda internetsiz xabarlar yozadi. “Yuborish” tugmachasining har bir bosilishi Offline Queue ga qo‘shiladi. Poyezd tunneldan chiqib, tarmoq paydo bo‘lganda, barcha xabarlar avtomatik yuboriladi. Foydalanuvchi tajribasi uzluksiz: u yuborishdagi engil kechikishdan tashqari oflayn bo‘lganini sezmaydi.

Uber Engineering (2024) ma'lumotlariga ko‘ra, ularning oflayn navbati past sifatli aloqaga ega hududlarda kuniga 2 milliondan ortiq operatsiyani qayta ishlaydi. Navbat FIFO tartibi va exactly-once kafolatlangan yetkazish mexanizmi bilan Room lokal omboridan foydalanadi.

data class QueuedOperation(
    val id: String,
    val type: OperationType,
    val endpoint: String,
    val payload: String,
    val timestamp: Long,
    val retryCount: Int = 0,
    val idempotencyKey: String
)

Har bir operatsiya qayta yuborish uchun zarur bo‘lgan barcha ma'lumotlarni o‘z ichiga oladi: endpoint, so‘rov tanasi, vaqt tamg‘asi va idempotencyKey. Room ma'lumotlar bazasi ilova qayta ishga tushirilganda va OT tizimi ishdan chiqqanda navbatning saqlanishini kafolatlaydi.

Mobil ilovada operatsiyalar navbati nima uchun kerak

Yetkazib berish kafolati navbatning asosiy vazifasidir. Foydalanuvchi uning harakati (xabar yuborish, like, buyurtma) bajarilish vaqtida tarmoq mavjud bo‘lmasa ham amalga oshirilishiga ishonch hosil qilishi kerak. Retry mexanizmiga ega Offline Queue eventually yetkazib berishni ta'minlaydi.

Yomon aloqa sharoitida UX ni yaxshilash — GSMA Mobile Economy Report (2025) ma'lumotlariga ko‘ra, dunyodagi mobil foydalanuvchilarning taxminan 40% beqaror internet aloqasiga ega. Offline Queue ilovani metro, liftlar, uzoq hududlar — aloqa uzilib qoladigan hamma joyda foydalanishga yaroqli qiladi.

Ma'lumot yo‘qotilishini kamaytirish — navbat bo‘lmasa, oflayn rejimda bajarilgan barcha harakatlar yo‘qoladi. Foydalanuvchi uzun formani to‘ldirib, “Yuborish” tugmasini bosib, tarmoq xatosini ko‘rishi mumkin — barcha kiritilgan ma'lumotlar yo‘qoladi. Offline Queue ma'lumotlarni saqlaydi va birinchi imkoniyatda yuboradi. Google Docs da avtomatik saqlash hujjatlar uchun oflayn navbatning klassik namunasidir.

Asinxron sinxronizatsiya — navbat ilovaga yuborish vaqtida interfeysni bloklamaslikka imkon beradi. Foydalanuvchi ishini davom ettiradi, sinxronizatsiya menejeri esa navbatni fonda qayta ishlaydi. Bu Reaktiv Arxitektura tamoyillariga mos keladi va interfeysning sezgirligini yaxshilaydi.

Oflayn navbat arxitekturasi: saqlash va qayta ishlash

Navbatning uch qatlami: saqlash (persistence), dispetcher (scheduler) va protsessor (executor). Saqlash — QueuedOperation jadvali bilan Room. Dispetcher — tarmoq paydo bo‘lganda sinxronizatsiyani ishga tushiradigan WorkManager (Android) yoki BGTaskScheduler (iOS). Protsessor — operatsiyalarni birma-bir yuboradigan ketma-ket FIFO iterator.

Qayta ishlash tartibi ma'lumotlar izchilligi uchun juda muhim. Agar foydalanuvchi yozuv yaratib, keyin uni tahrir qilgan bo‘lsa, ikkala operatsiya ham bir xil tartibda yuborilishi kerak. Aks holda server avval mavjud bo‘lmagan yozuvning yangilanishini oladi — xato. Sequential FIFO — operatsiyalar orasidagi bog‘liqliklarni nazorat qilish bilan qat'iy tartib.

Birlashtirish strategiyasi — navbatda bir xil ob'ektning CREATE va undan keyin DELETE i bo‘lsa, ikkala operatsiyani yubormasdan o‘chirish mumkin: yakuniy holat — ob'ekt yaratilmagan. Xuddi shunday, CREATE + UPDATE CREATE ni eng so‘nggi ma'lumotlar bilan bitta CREATE ga birlashtirish mumkin. Navbatni optimallashtirish HTTP so‘rovlar sonini kamaytiradi va sinxronizatsiyani tezlashtiradi.

Android Developers (2025) ma'lumotlariga ko‘ra, WorkManager Android da Offline Queue ni qayta ishlashning afzal usulidir: u qurilma qayta ishga tushirilgandan keyin ham bajarilishni kafolatlaydi, tarmoq mavjudligi bo‘yicha cheklovlarni qo‘llab-quvvatlaydi va NetworkType.CONNECTED orqali qayta urinish siyosatini belgilash imkonini beradi.

class SyncWorker(
    private val context: Context,
    private val params: WorkerParameters
) : CoroutineWorker(context, params) {

    override suspend fun doWork(): Result = runCatching {
        queueRepository.processNextBatch(batchSize = 10)
        Result.success()
    }.getOrDefault(Result.retry())
}

CoroutineWorker operatsiyalar partiyalarini qayta ishlaydi va muvaffaqiyatsizlikda Result.retry() qaytaradi — WorkManager avtomatik ravishda eksponensial kechikish bilan ishga tushirishni takrorlaydi. Bu Android da ishonchli Offline Queue olishning eng oddiy usulidir.

Qayta urinish strategiyalari: exponential backoff va retry policy

Exponential Backoff — ortib boruvchi interval bilan standart takrorlash strategiyasi: 2 soniya, 4 soniya, 8 soniya, 16 soniya va hokazo maksimal chegaragacha. Bu server vaqtincha mavjud bo‘lmaganda uning qayta yuklanishining oldini oladi. Resilience4j (2024) Java kutubxonasi sozlanishi backoff bilan Retry ning tayyor implementatsiyasini taqdim etadi.

Maksimal urinishlar soni — muhim parametr. Agar 5–10 urinishdan keyin operatsiya muvaffaqiyatli bo‘lmasa, keyingi urinishlar foydasiz. Dead letter queue tavsiya etiladi: urinishlar tugagandan so‘ng operatsiya qo‘lda tahlil qilish uchun alohida jadvalga ko‘chiriladi. Microsoft Patterns & Practices (2024) ma'lumotlariga ko‘ra, dead letter queue sinxronizatsiya muammolarini tuzatishni osonlashtiradi va xato operatsiyalar navbatni bloklashining oldini oladi.

Jitter — tasodifiy o‘zgarish — backoff intervaliga tasodifiy son qo‘shish. Agar minglab qurilmalar bir vaqtning o‘zida uzilishdan keyin tarmoqni tiklansa, ularning barchasi bir vaqtning o‘zida sinxronizatsiyani boshlaydi. Jitter ularni vaqt bo‘yicha tarqatib, serverda Cache Stampede ning oldini oladi. To‘liq jitter: delay = random(0, backoff) — AWS (2024) tomonidan API mijozlari uchun tavsiya etilgan.

Konfliktlarni hal qilish: ma'lumotlar to‘qnashuvlarini qanday hal qilish kerak

Last Write Wins (LWW) — eng oddiy strategiya: to‘qnashuvda keyingi vaqt tamg‘asiga ega operatsiya g‘alaba qozonadi. LWW vaqtni sinxronlashtirishni talab qiladi — timestamp serverda yaratilishi yoki Logical Clock (Lamport soatlari) dan foydalanishi kerak. Kamchilik: bir foydalanuvchining ma'lumotlari ogohlantirishsiz boshqa foydalanuvchining ma'lumotlari bilan qoplanishi mumkin.

OT (Operational Transformation) — Google Docs va Figma tomonidan real vaqtda birgalikda tahrirlash uchun ishlatiladigan algoritm, shu jumladan oflayn rejimda. OT operatsiyalarni shunday o‘zgartiradiki, ular hujjatning istalgan holatiga qo‘llanilishi mumkin, blokirovkalarsiz izchillikni ta'minlaydi. CRDT (Conflict-Free Replicated Data Types) — mobil ilovalarda ommalashib borayotgan OT muqobili: ma'lumotlar shunday tuzilganki, to‘qnashuvlar markaziy serversiz matematik tarzda hal qilinadi.

Maxsus birlashtirish — oddiy ma'lumot modeliga ega ilovalar (eslatmalar, kontaktlar) uchun maxsus birlashtirish qoidalari amalga oshirilishi mumkin. Masalan, eslatma uchun: agar matn ikki versiyada o‘zgartirilgan bo‘lsa, ularni ajratgich bilan birlashtiring. Foydalanuvchi tomonidan hal qilingan konflikt — avtomatik birlashtirish imkoni bo‘lmasa, foydalanuvchiga ikkala versiyani ko‘rsating va tanlashni taklif qiling. Dropbox (2024) oflayn fayllardagi konfliktlar uchun ushbu yondashuvdan foydalanadi, “Conflicted Copy” prefiksi bilan nusxalar yaratadi.

Idempotency keys — dublikatsiyadan himoya

Idempotency Key — server takroriy so‘rovlarni aniqlash uchun ishlatadigan noyob operatsiya identifikatoridir. Agar mijoz bir xil kalit bilan bir xil so‘rovni yuborsa, server operatsiyani qayta bajarmasdan allaqachon bajarilgan operatsiya natijasini qaytaradi. Bu tarmoq xatolarida qayta yuborish mumkin bo‘lgan Offline Queue uchun juda muhimdir.

Idempotency key formati — UUID yoki so‘rov parametrlarining heşi. Server bajarilgan kalitlarni natija bilan birga ma'lum vaqt (odatda 24 soat) saqlashi kerak. Stripe API (2024) — namunaviy misol: kalit Idempotency-Key sarlavhasida uzatiladi va bir xil kalit bilan takroriy so‘rovlar keshga olingan javobni qaytaradi.

Mijoz tomonida yaratish — kalit operatsiyani yuborishdan oldin mijoz tomonida yaratiladi va QueuedOperation jadvalida saqlanadi. Qayta urinishda kalit o‘zgarmaydi. Exactly-once arxitekturasi — mijoz tomonida idempotency key va server tomonida dedublikatsiya kombinatsiyasi — operatsiyaning ikki marta bajarilmasligini kafolatlashning yagona usuli.

fun createOperation(type: OperationType, payload: String): QueuedOperation =
    QueuedOperation(
        id = UUID.randomUUID().toString(),
        type = type,
        endpoint = type.endpoint,
        payload = payload,
        timestamp = currentTimeMillis(),
        idempotencyKey = UUID.randomUUID().toString()
    )

Har bir operatsiya ikkita UUID oladi: biri — navbatdagi yozuv identifikatori, ikkinchisi — server uchun idempotency key. idempotencyKey bo‘yicha server tomonida dedublikatsiya qayta yuborishda ham buyurtma dublikat qilinmasligini kafolatlaydi.