Mobil inkişafda keşin etibarsızlaşdırılması: strategiyalar və mexanizmlər

Keşin etibarsızlaşdırılması nədir?

Keşin etibarsızlaşdırılması — məlumat mənbəyinin cari vəziyyətinə uyğun gəlməyən keşlənmiş qeydlərin ləğv edilməsi və ya yenilənməsi prosesi. Bütün keşin əl ilə təmizlənməsindən fərqli olaraq, etibarsızlaşdırma nöqtəvi işləyir: yalnız aktuallığı şübhə altında olan məlumatlar.

Keş sürətli giriş üçün məlumatların surətlərini saxlayır. Zamanla bazada və ya serverdə orijinal məlumatlar dəyişə bilər — məsələn, istifadəçi profili yenilədi və ya lentdə yeni post peyda oldu. Keş etibarsızlaşdırılmasa, tətbiq köhnəlmiş məlumatı göstərəcək, bu da mobil tətbiqlərdə əməliyyat səhvlərinə, səhv göstərməyə və etibar itkisinə səbəb olur.

İstənilən etibarsızlaşdırmanın əsas çətinliyi — məşhur deyim “There are only two hard things in Computer Science: cache invalidation and naming things”. Çətinlik ondadır ki, keş mənbənin dəyişdiyini bilmir, əgər ona açıq şəkildə bildirilməsə.

Martin Kleppmann-ın „Designing Data-Intensive Applications” (O’Reilly, 2017) kitabının müəllifinə görə, düzgün etibarsızlaşdırma ya dəyişikliklər haqqında mərkəzləşdirilmiş bildiriş, ya da hər oxunuşda aktuallığı yoxlamaq mexanizmi tələb edir — performans və ardıcıllıq arasında kompromis.

data class CacheEntryT(
    val data: T,
    val expiresAt: Long,
    val version: Int = 0
)

fun CacheT.isValid(key: String): Boolean =
    get(key)?.let { it.expiresAt > currentTimeMillis() && it.version == currentVersion(key) } ?: false

Bu kod sadə yanaşmanı göstərir: keşdəki qeyd, əgər TTL müddəti bitməyibsə və versiya mənbədəki cari versiya ilə uyğundursa, etibarlı sayılır. Versiyalaşdırma mexanizmi — köhnəlmiş məlumatların göstərilməsinin qarşısını almağın etibarlı yollarından biridir.

Mobil tətbiqlərdə etibarsızlaşdırma nə üçün lazımdır

Məlumatların aktuallığı — əksər mobil tətbiqlər üçün əsas tələb: sosial şəbəkələr, messencerlər, bank xidmətləri, e-commerce platformaları. Hesabında səhv balans və ya köhnə mesajlar görən istifadəçi tətbiqə olan etibarını itirir.

İstifadəçi təcrübəsi ilə yanaşı, etibarsızlaşdırma trafik və batareyaya qənaət məsələsini də həll edir. Dövri tam məlumat yenidən yükləməsi əvəzinə, mobil tətbiq yalnız dəyişmiş qeydləri etibarsızlaşdırıb nöqtəvi yükləyə bilər. Meta Engineering (2024) məlumatlarına görə, Facebook Lite-da inkremental etibarsızlaşdırmanın tətbiqi məzmun aktuallığını itirmədən trafik sərfiyyatını 35% azaldıb.

Digər vacib aspekt — əməliyyat ardıcıllığı. Alış-veriş səbəti və ya rezervasiya olan tətbiqlərdə köhnəlmiş keşin istifadəsi ikiqat silinmələrə və ya məlumat konfliktlərinə səbəb ola bilər. Kritik əməliyyatlardan sonra etibarsızlaşdırma növbəti sorğunun təzə məlumatları oxuyacağına zəmanət verir.

Keşin etibarsızlaşdırılmasının əsas strategiyaları

TTL (Time-To-Live)

TTL — ən sadə strategiya, burada keşdəki hər bir qeyd sabit ömür müddəti alır. TTL müddəti bitdikdən sonra məlumatlar köhnəlmiş sayılır və növbəti oxunuşda silinir. TTL cədvəl üzrə yenilənən məlumatlar üçün idealdır — məsələn, hava və ya valyuta məzənnəsi. Mənfi cəhət: məlumatlar TTL intervalı daxilində qeyri-aktual ola bilər.

Write-Through

Write-Through strategiyasında hər bir məlumat dəyişikliyi keşdən keçir: yazma eyni anda həm keşə, həm də mənbəyə yerinə yetirilir. Bu, keşin həmişə cari versiyanı ehtiva etməsini təmin edir. Çatışmazlıq — yazma gecikməsi artır, çünki əməliyyat mənbədən təsdiq alınana qədər tamamlanmır. Write-Through ardıcıllıq üçün kritik məlumatlar üçün uyğundur: hesab balansı, sifariş statusu.

Write-Behind (Write-Back)

Write-Behind — asinxron yazma: məlumatlar dərhal keşə daxil olur, mənbəyə isə daha sonra ayrıca proses tərəfindən yazılır. Bu, yazma üçün yüksək performans verir, lakin sinxronizasiyadan əvvəl nasazlıq zamanı məlumat itkisi riski daşıyır. Mobil tətbiqlərdə Write-Behind tez-tez analitika, jurnallar və kritik olmayan istifadəçi hərəkətləri üçün istifadə olunur.

Write-Invalidate

Write-Invalidate — məlumat dəyişikliyi zamanı keşi yeniləmək əvəzinə, sadəcə müvafiq qeydi silir (etibarsızlaşdırır). Növbəti oxunuş keşdə olmama aşkar edəcək və mənbədən təzə məlumatları yükləyəcək. Bu strategiya tətbiq etmək asandır və oxu sorğuları yazma sorğularından əhəmiyyətli dərəcədə çox olduqda yaxşı işləyir.

Strategiyanın seçimi konkret ssenari üçün nəyin prioritet olmasından asılıdır: cavab sürəti, ardıcıllıq və ya resurslara qənaət. Hibrid yanaşmalar — məsələn, push bildirişi alındıqda TTL ilə Write-Invalidate — optimal tarazlığı təmin edir.

Müxtəlif keş səviyyələrində etibarsızlaşdırma necə işləyir

HTTP keşi — müştəri tərəfində ilk səviyyə. Brauzer və ya mobil tətbiq server cavablarını Cache-Control və ETag başlıqları ilə saxlayır. Etibarsızlaşdırma 304 Not Modified cavabı alındıqda və ya max-age müddəti bitdikdə baş verir. ETag müştəriyə tam cavabı yükləmədən resursun aktuallığını yoxlamağa imkan verir.

Tətbiq keşi — ikinci səviyyə, kod tərəfindən idarə olunur: in-memory keşlər (LRU, Android-də LruCache) və ya disk keşləri (SQLite, Room, Realm). Burada etibarsızlaşdırmanı tərtibatçı idarə edir. Android Developers (2025) məlumatlarına görə, Room-un Flow və triggerlər vasitəsilə etibarsızlaşdırma ilə düzgün istifadəsi UI yenidən çəkilmələrinin sayını 40% azaldır.

Server keşi — üçüncü səviyyə: Redis, Memcached, CDN. Bu səviyyədə etibarsızlaşdırma TTL, DEL/PURGE əmrləri və ya mesaj brokerləri (RabbitMQ, Kafka) vasitəsilə həyata keçirilir. CDN etibarsızlaşdırması — ayrıca məsələ: CDN-in paylanmış təbiətinə görə təmizləmə əmri dəqiqələrlə yayıla bilər. Cloudflare (2024) məlumatlarına görə, Purge by URL vasitəsilə etibarsızlaşdırma qlobal yayılma üçün orta hesabla 5–15 saniyə çəkir.

Bütün səviyyələrdə etibarsızlaşdırmanı əlaqələndirmək üçün mərkəzləşdirilmiş keş xidməti və ya hadisə brokeri istifadə olunur. Məlumat dəyişdikdə mənbə hadisə dərc edir və hər bir səviyyə konkret açarların etibarsızlaşdırılması əmrini alır. Bu, bir səviyyənin artıq məlumatları yenilədiyi, digərinin isə köhnəlmiş versiyanı qaytarmağa davam etdiyi vəziyyətin qarşısını alır.

Keşin etibarsızlaşdırılmasında tipik səhvlər

Çox uzun TTL — ən geniş yayılmış səhv. Tərtibatçılar TTL-ni “ehtiyatla” təyin edir, bu da istifadəçilərin saatlar və ya günlərlə köhnəlmiş məlumatları görməsinə səbəb olur. Həll yolu: qısa TTL (1–5 dəqiqə) ilə başlamaq və yalnız real ehtiyacı ölçdükdən sonra artırmaq.

Bir dəyişiklikdə bütün keşin etibarsızlaşdırılması — mikroservis arxitekturasında tipik problem. Bir istifadəçi avatarı yenilədi, keş isə hamı üçün etibarsızlaşdırılır. Çox sayda istifadəçi olduqda bu Cache Stampede effektinə — mənbəyə sorğu uçqununa səbəb olur. Həll yolu: ümumi keşi deyil, yalnız konkret istifadəçinin açarını etibarsızlaşdırmaq.

Yazma səhvlərində etibarsızlaşdırmanın olmaması — mənbəyə yazma uğursuz olarsa, keş artıq yenilənibsə, tətbiq ardıcıl olmayan vəziyyətə düşür. Həll yolu: iki fazalı etibarsızlaşdırma — əvvəlcə keşi təmizləmək, sonra mənbəyə yazmaq və səhv zamanı etibarsızlaşdırmanı geri qaytarmaq.

Paylanmış təbiətin nəzərə alınmaması — klaster mühitində bir nodda etibarsızlaşdırma digər nodların əmri aldığı anlamına gəlmir. Hadisə brokeri olmadan serverlərin bir hissəsi köhnəlmiş məlumatları qaytarmağa davam edəcək. Redis Pub/Sub və ya Apache Kafka bu problemi etibarsızlaşdırma hadisələrini yaymaqla həll edir.

Etibarsızlaşdırma strategiyasını necə seçmək olar

Aktuallıq tələblərini müəyyən edin — məlumatların “dərhal” təzə olması nə qədər kritikdir. Xəbər lenti üçün 1–2 dəqiqə gecikmə məqbuldur (TTL). Hesab balansı üçün gecikmə yolverilməzdir (Write-Through).

Dəyişmə tezliyini qiymətləndirin — gündə bir dəfə yenilənən məlumatlar (məhsul kataloqu, şəhərlər lüğəti) TTL ilə əla işləyir. Saniyədə dəfələrlə dəyişən məlumatlar (onlayn statuslar, valyuta məzənnələri) WebSocket və ya Firebase Cloud Messaging vasitəsilə push etibarsızlaşdırması tələb edir.

Mənbənin oxu dəyərini nəzərə alın — mənbə 10 cədvəldə bahalı SQL sorğusu və ya limitləri olan xarici API-dirsə, uzun TTL ilə aqressiv keşləmə istifadə etmək, lakin köhnəlmiş məlumatları push etibarsızlaşdırması ilə kompensasiya etmək daha yaxşıdır. Oxu ucuzdursa (in-memory lookup), qısa TTL və Write-Invalidate istifadə oluna bilər.

Google I/O (2025) məlumatlarına görə, mobil tətbiq üçün tipik nümunə — Stale-While-Revalidate: istifadəçi dərhal keşlənmiş məlumatları görür, tətbiq isə fonda onların aktuallığını yoxlayır və yeniləyir. Bu, cavab sürəti və aktuallığı kompromissiz birləşdirir. HTTP Cache-Control başlığı stale-while-revalidate direktivi ilə Android 10 və iOS 13-dən etibarən dəstəklənir.