Offline Queue: prinsiplər, strategiyalar və iş mexanizmləri

Oflayn növbə nədir?

Offline Queue cihazın şəbəkəyə çıxışı olmadıqda tətbiqin lokal olaraq saxladığı sıralanmış əməliyyatlar kolleksiyasıdır (yaratma, yeniləmə, silmə). Əlaə bərpa olunan kimi növbə əməliyyatları istifadəçinin etdiyi ardıcıllıqla serverə göndərir.

Ssenarini təsəvvür edin: istifadəçi metrosunda internet olmadan mesajlar yazır. Hər «Göndər» düyməsinə basıldıqda əməliyyat Offline Queue-ə əlavə olunur. Qatar tuneldən çıxıb şəbəkə görünəndə bütün mesajlar avtomatik göndərilir. Istifadəçi təcrübəsi fasiləsizdir: o, göndərmədəki yüngəl gecikmə xaric oflayn olduğunu hiss etmir.

Uber Engineering (2024)-in məlumatlarına görə, onların oflayn növbəsi aşağı keyfiyyətli əlaqəsi olan regionlarda gündə 2 milyondan çox əməliyyat emal edir. Növbə FIFO sırası və exactly-once zəmanətli çatdırma mexanizmi ilə Room lokal yaddaşından istifadə edir.

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
)

Hər əməliyyat təkrari göndərmə üçün lazım olan bütün məlumatları ehtiva edir: endpoint, sorğu gövdəsi, vaxt damğası və idempotencyKey. Room verilənlər bazası tətbiq yenidən başladıqda və ƏS qəzaları zamanı növbənin qorunmasına zəmanət verir.

Mobil tətbiqdə əməliyyat növbəsi nə üçün lazımdır

Çatdırma zəmanəti növbənin əsas vəzifəsidir. Istifadəçi əmin olmalıdır ki, onun hərəkəti (mesaj göndərmə, bəyənmə, sifariş) şəbəkə icra anında mövcud olmasa belə yerinə yetiriləcək. Retry mexanizmi ilə Offline Queue eventually çatdırılmanı təmin edir.

Zəif əlaqə şəraitində UX-in yaxşılaşdırılması — GSMA Mobile Economy Report (2025)-in məlumatlarına görə, dünyada mobil istifadəçilərin təxminən 40%-i qeyri-sabit internet bağıntısına malikdir. Offline Queue tətbiqi metropoliten, liftlər, uzaq rayonlar — əlaqənin kəsildiyi hər yerdə istifadəyə yararlı edir.

Məlumat itkisinin azaldılması — növbə olmadan oflayn rejimdə edilən bütün əməliyyatlar itirilir. Istifadəçi uzun bir formu doldura, «Göndər» düyməsinə basa və şəbəkə xətası görə bilər — bütün daxil edilən məlumat itir. Offline Queue məlumatları saxlayır və ilk fürstət göndərir. Google Docs-da avtomatik yadda saxlama sənədlər üçün oflayn növbənin klassik nümunəsidir.

Asinxron sinxronizasiya — növbə tətbiqə göndərmə zamanı interfeysi bloklamamağa imkan verir. Istifadəçi işinə davam edir, sinxronizasiya meneceri isə növbəni fonda emal edir. Bu, Reaktiv Arxitektura prinsiplərinə uyğundur və interfeysin cavabdehlik qabiliyyətini yaxşılaşdırır.

Oflayn növbənin arxitekturası: saxlama və emal

Növbənin üç qatı: yaddaş (persistence), dispetçer (scheduler) və prosessor (executor). Yaddaş — QueuedOperation cədvəli ilə Room. Dispetçer — şəbəkə görünəndə sinxronizasiyanı işə salan WorkManager (Android) və ya BGTaskScheduler (iOS). Prosessor — əməliyyatları bir-bir göndərən ardıcıl FIFO iteratoru.

Emal sırası verilən ardıcıllığı üçün kritik əhəmiyyət daşıyır. Istifadəçi yazı yaradıb sonra onu redaktə edibsə, hər iki əməliyyat eyni ardıcıllıqla göndərilməlidir. Əks halda server əvvəlcə mövcud olmayan yazının yenilənməsini alacaq — xəta. Sequential FIFO — əməliyyatlar arasında asılılıqlara nəzarətlə ciddi sıra.

Birləşdirmə strategiyası — növbədə eyni obyektin CREATE və ondan dərhal sonra DELETE-i varsa, hər iki əməliyyat göndərilmədən silinə bilər: son nəticə — obyekt yaradılmayıb. Eynilə, CREATE + UPDATE CREATE son məlumatlarla bir CREATE-ə birləşdirilə bilər. Növbənin optimallaşdırılması HTTP sorğularının sayını azaldır və sinxronizasiyanı sürətləndirir.

Android Developers (2025)-in məlumatlarına görə, WorkManager Android-də Offline Queue-nin emalı üçün üstünlük verilən üsuldur: o, cihaz yenidən başladıldıqdan sonra belə icranı təmin edir, şəbəkə mövcudluğu üçün məhdudiyyətləri dəstəkləyir və NetworkType.CONNECTED vasitəsilə təkrari cɕhd siyasətini təyin etməyə imkan verir.

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 əməliyyat partiyalarını emal edir və uğursuzluqda Result.retry() qaytarır — WorkManager avtomatik olaraq eksponensial gecikmə ilə işə salmanı təkrarlayır. Bu, Android-də etibarlı Offline Queue əldə etməyin ən sadə üsuludur.

Təkrarlanan cəhd strategiyaları: exponential backoff və retry policy

Exponential Backoff — artan fasilələrlə standart təkrarlama strategiyası: 2 san, 4 san, 8 san, 16 san və maksimum həddə qədər davam edir. Bu, müvəqqəti olaraq əlçatmaz olduqda serverin yenidən yüklənməsinin qarşısını alır. Resilience4j (2024) Java kitabxanası konfiqurasiya olunan backoff ilə Retry-nin hazır tətbiqini təqdim edir.

Maksimum cəhd sayı — kritik parametrdir. 5–10 cəhddən sonra əməliyyat uğursuz olarsa, sonrakı cəhdlər faydasızdır. Dead letter queue tövsiyə olunur: cəhdlər tùkəndikdən sonra əməliyyat əl ilə analiz üçün ayrıca cədvələ köçürülür. Microsoft Patterns & Practices (2024)-in məlumatlarına görə, dead letter queue sinxronizasiya problemlərinin debug edilməsini asanlaşdırır və səhv əməliyyatların növbəni bloklamasının qarşısını alır.

Jitter — təsadüfi variasiya — backoff intervalına təsadüfi ədədin əlavə edilməsi. Əgər minlərlə cihaz eyni anda əlaqəni bərpa edərsə, hamısı eyni vaxtda sinxronizasiyaya başlayacaq. Jitter onları zamana görə yayaraq serverdə Cache Stampede-in qarşısını alır. Tam jitter: delay = random(0, backoff) — AWS (2024) tərəfindən API müştəriləri üçün tövsiyə olunur.

Münaqişə həlli: verilən toqquşmalarını necə həll etməli

Last Write Wins (LWW) — ən sadə strategiya: toqquşma zamanı daha gec vaxt damğası olan əməliyyat qalib gəlir. LWW vaxtın sinxronizasiyasını tələb edir — timestamp serverdə yaradılmalı və ya Logical Clock (Lamport saatları) istifadə edilməlidir. Mənfi cəhət: bir istifadəçinin məlumatları xəbərdarlıq edilmədən başqasının məlumatları ilə əvəz oluna bilər.

OT (Operational Transformation) — Google Docs və Figma tərəfindən real vaxt rejimində birgə redaktə üçün istifadə edilən alqoritm, o cümlədən oflayn rejimdə. OT əməliyyatları elə çevirir ki, onlar sənədin istənilən vəziyyətinə tətbiq olunsun, bloklanmadan ardıcıllığı təmin etsin. CRDT (Conflict-Free Replicated Data Types) — mobil tətbiqlərdə populyarlıq qazanan OT alternativi: məlumatlar elə strukturlaşdırılıb ki, toqquşmalar mərkezi server olmadan riyazi şəkildə həll olunsun.

Xüsusi birləşdirmə — sadə verilən modeli olan tətbiqlər (qeydlər, əlaqələr) üçün xüsusi birləşdirmə qaydaları tətbiq edilə bilər. Məsələn, qeyd üçün: mətn iki versiyada dəyişdirilibsə, onları ayırıcı ilə birləşdirin. Istifadəçi tərəfindən həll edilən münaqişə — avtomatik birləşdirmə mümkün deyilsə, istifadəçiyə hər iki versiyanı göstərin və seçim təklif edin. Dropbox (2024) oflayn fayllardakı münaqişələr üçün bu yanaşmanı istifadə edir, «Conflicted Copy» prefiksi ilə surətlər yaradır.

Idempotency keys — dublikasiyadan qorunma

Idempotency Key — serverin təkrarlanan sorğuları aşkar etmək üçün istifadə etdiyi unikal əməliyyat identifikatorudur. Müştəri eyni açarla eyni sorğu göndərərsə, server artıq yerinə yetirilmiş əməliyyatın nəticəsini qaytarır, onu təkrarlamır. Bu, şəbəkə xətaları zamanı təkrari göndərmələrin mümkün olduğu Offline Queue üçün kritik əhəmiyyət daşıyır.

Idempotency key formatı — UUID və ya sorğu parametrlərinin heşi. Server yerinə yetirilmiş açarları nəticə ilə birlikdə müəyyən müddət (adətən 24 saat) saxlamaLıdır ki, dublikatları aşkar etsin. Stripe API (2024) — nümunəvi nümunə: açar Idempotency-Key başlığında ötürülür və eyni açarla təkrari sorğular keşlənmiş cavabı qaytarır.

Müştəri tərəfində yaradılma — açar əməliyyat göndərilməzdən əvvəl müştəri tərəfindən yaradılır və QueuedOperation cədvəlində saxlanılır. Təkrari cəhddə açar dəyişmir. Exactly-once arxitekturası — müştəri tərəfində idempotency key və server tərəfində deduplikasiya kombinasiyası əməliyyatın iki dəfə yerinə yetirilməyəcəyinə zəmanət verməyin yeganə yoludur.

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

Hər əməliyyat iki UUID alır: biri növbədəki yazının identifikatoru, digəri server üçün idempotency key. idempotencyKey əsasında server tərəfində deduplikasiya təkrari göndərmədə belə sifarişin dublikat olunmayacağına zəmanət verir.