Mobil ishlanmada keshni bekor qilish: strategiyalar va mexanizmlar

Keshni bekor qilish nima?

Keshni bekor qilish — ma'lumotlar manbasining joriy holatiga mos kelmaydigan keshlangan yozuvlarni bekor qilish yoki yangilash jarayoni. Butun keshni qo'lda tozalashdan farqli o'laroq, bekor qilish nuqtaviy ishlaydi: faqat dolzarbligi shubha ostida bo'lgan ma'lumotlar.

Kesh tezkor kirish uchun ma'lumotlar nusxalarini saqlaydi. Vaqt o'tishi bilan bazadagi yoki serverdagi asl ma'lumotlar o'zgarishi mumkin — masalan, foydalanuvchi profilni yangiladi yoki lentada yangi post paydo bo'ldi. Agar kesh bekor qilinmasa, ilova eskirgan ma'lumotni ko'rsatadi, bu mobil ilovalarda tranzaksiya xatolariga, noto'g'ri ko'rsatishga va ishonch yo'qotishiga olib keladi.

Har qanday bekor qilishning asosiy qiyinchiligi — mashhur ibora “There are only two hard things in Computer Science: cache invalidation and naming things”. Murakkablik shundaki, kesh manba qachon o'zgarganini bilmaydi, agar unga aniq aytilmasa.

Martin Kleppmann ning „Designing Data-Intensive Applications” (O'Reilly, 2017) kitobi muallifiga ko'ra, to'g'ri bekor qilish yoki o'zgarishlar haqida markazlashtirilgan xabardor qilishni yoki har bir o'qishda dolzarblikni tekshirish mexanizmini talab qiladi — ishlash va izchillik o'rtasidagi murosani.

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 oddiy yondashuvni ko'rsatadi: keshdagi yozuv, agar TTL muddati tugamagan bo'lsa va versiya manbadagi joriy versiyaga mos kelsa, haqiqiy hisoblanadi. Versiyalash mexanizmi — eskirgan ma'lumotlarni ko'rsatishdan qochishning ishonchli usullaridan biri.

Nega mobil ilovalarda bekor qilish kerak

Ma'lumotlarning dolzarbligi — ko'pchilik mobil ilovalar uchun asosiy talab: ijtimoiy tarmoqlar, messenjerlar, bank xizmatlari, e-commerce platformalari. Hisobida noto'g'ri balans yoki eski xabarlarni ko'rgan foydalanuvchi ilovaga bo'lgan ishonchini yo'qotadi.

Foydalanuvchi tajribasidan tashqari, bekor qilish trafik va batareyani tejash muammosini hal qiladi. Davriy to'liq ma'lumot qayta yuklash o'rniga, mobil ilova faqat o'zgargan yozuvlarni bekor qilishi va ularni nuqtaviy yuklashi mumkin. Meta Engineering (2024) ma'lumotlariga ko'ra, Facebook Lite da inkremental bekor qilishni joriy qilish kontent dolzarbligini yo'qotmasdan trafik sarfini 35% ga kamaytirdi.

Yana bir muhim jihat — tranzaksiyalar izchilligi. Xarid savati yoki bron qilish bilan ishlaydigan ilovalarda eskirgan keshdan foydalanish ikki marta hisobdan chiqarish yoki ma'lumotlar ziddiyatlariga olib kelishi mumkin. Kritik operatsiyalardan keyin bekor qilish keyingi so'rovning yangi ma'lumotlarni o'qishini kafolatlaydi.

Keshni bekor qilishning asosiy strategiyalari

TTL (Time-To-Live)

TTL — eng oddiy strategiya, bunda keshdagi har bir yozuv belgilangan yashash muddatini oladi. TTL muddati tugagach, ma'lumotlar eskirgan deb hisoblanadi va keyingi o'qishda o'chiriladi. TTL jadval bo'yicha yangilanadigan ma'lumotlar uchun ideal — masalan, ob-havo yoki valyuta kursi. Kamchilik: ma'lumotlar TTL oralig'ida dolzarb bo'lmasligi mumkin.

Write-Through

Write-Through strategiyasida har bir ma'lumot o'zgarishi kesh orqali o'tadi: yozish bir vaqtning o'zida keshga va manbaga amalga oshiriladi. Bu kesh har doim joriy versiyani o'z ichiga olishini kafolatlaydi. Kamchilik — yozish kechikishi ortadi, chunki operatsiya manbadan tasdiq olinmaguncha tugallanmaydi. Write-Through izchillik uchun muhim ma'lumotlar uchun mos: hisob balansi, buyurtma statusi.

Write-Behind (Write-Back)

Write-Behind — asinxron yozish: ma'lumotlar darhol keshga tushadi, manbaga esa keyinroq alohida jarayon tomonidan yoziladi. Bu yozish uchun yuqori ishlashni beradi, lekin sinxronizatsiyadan oldin nosozlik paytida ma'lumot yo'qotish xavfini keltiradi. Mobil ilovalarda Write-Behind ko'pincha analitika, jurnallar va kritik bo'lmagan foydalanuvchi harakatlari uchun ishlatiladi.

Write-Invalidate

Write-Invalidate — ma'lumot o'zgarishida keshni yangilash o'rniga, shunchaki tegishli yozuvni o'chiradi (bekor qiladi). Keyingi o'qish keshda yo'qligini aniqlaydi va manbadan yangi ma'lumotlarni yuklaydi. Bu strategiya amalga oshirish uchun sodda va o'qish so'rovlari yozish so'rovlaridan sezilarli darajada ko'p bo'lganda yaxshi ishlaydi.

Strategiyani tanlash muayyan stsenariy uchun nima muhimligiga bog'liq: javob tezligi, izchillik yoki resurslarni tejash. Gibrid yondashuvlar — masalan, push xabarnomasi olinganda TTL bilan Write-Invalidate — optimal muvozanatni ta'minlaydi.

Keshning turli darajalarida bekor qilish qanday ishlaydi

HTTP keshi — mijoz tomonidagi birinchi daraja. Brauzer yoki mobil ilova server javoblarini Cache-Control va ETag sarlavhalari bilan saqlaydi. Bekor qilish 304 Not Modified javobi olinganda yoki max-age muddati tugaganda sodir bo'ladi. ETag mijozga to'liq javobni yuklamasdan resursning dolzarbligini tekshirishga imkon beradi.

Ilova keshi — ikkinchi daraja, kod tomonidan boshqariladi: in-memory keshlar (LRU, Androidda LruCache) yoki disk keshlari (SQLite, Room, Realm). Bu erda bekor qilishni dasturchi nazorat qiladi. Android Developers (2025) ma'lumotlariga ko'ra, Room ni Flow va triggerlar orqali bekor qilish bilan to'g'ri ishlatish UI qayta chizishlar sonini 40% ga kamaytiradi.

Server keshi — uchinchi daraja: Redis, Memcached, CDN. Bu darajada bekor qilish TTL, DEL/PURGE buyruqlari yoki xabar brokerlari (RabbitMQ, Kafka) orqali amalga oshiriladi. CDN bekor qilish — alohida vazifa: CDN ning taqsimlangan tabiati tufayli tozalash buyrug'i daqiqalar davomida tarqalishi mumkin. Cloudflare (2024) ma'lumotlariga ko'ra, Purge by URL orqali bekor qilish global tarqatish uchun o'rtacha 5–15 soniya davom etadi.

Barcha darajalarda bekor qilishni muvofiqlashtirish uchun markazlashtirilgan kesh xizmati yoki hodisa brokeri ishlatiladi. Ma'lumot o'zgarganda manba hodisa e'lon qiladi va har bir daraja muayyan kalitlarni bekor qilish buyrug'ini oladi. Bu bir daraja ma'lumotlarni yangilagan, ikkinchisi esa eskirgan versiyani qaytarishda davom etadigan vaziyatning oldini oladi.

Keshni bekor qilishdagi tipik xatolar

Juda uzoq TTL — eng keng tarqalgan xato. Dasturchilar TTLni “zaxira bilan” o'rnatadi, bu foydalanuvchilarning soatlab yoki kunlab eskirgan ma'lumotlarni ko'rishiga olib keladi. Yechim: qisqa TTL (1–5 daqiqa) bilan boshlash va faqat haqiqiy ehtiyojni o'lchagandan keyin oshirish.

Bir o'zgarishda butun keshni bekor qilish — mikrosarviss arxitekturasida tipik muammo. Bir foydalanuvchi avatarni yangiladi va kesh hamma uchun bekor qilinadi. Ko'p sonli foydalanuvchilar bo'lganda bu Cache Stampede effektiga — manbaga so'rovlar ko'chkisiga olib keladi. Yechim: umumiy keshni emas, faqat muayyan foydalanuvchining kalitini bekor qilish.

Yozish xatolarida bekor qilishning yo'qligi — manbaga yozish muvaffaqiyatsiz bo'lsa va kesh allaqachon yangilangan bo'lsa, ilova izchil bo'lmagan holatga tushadi. Yechim: ikki fazali bekor qilish — avval keshni tozalash, keyin manbaga yozish va xato bo'lganda bekor qilishni qaytarish.

Taqsimlangan tabiatni e'tiborsiz qoldirish — klaster muhitida bir tugunda bekor qilish boshqa tugunlar buyruqni olganligini anglatmaydi. Hodisa brokerisiz serverlarning bir qismi eskirgan ma'lumotlarni qaytarishda davom etadi. Redis Pub/Sub yoki Apache Kafka bu muammoni bekor qilish hodisalarini tarqatish orqali hal qiladi.

Bekor qilish strategiyasini qanday tanlash kerak

Dolzarblik talablarini aniqlang — ma'lumotlarning “hozir” yangi bo'lishi qanchalik muhim. Yangiliklar lentasi uchun 1–2 daqiqa kechikish maqbul (TTL). Hisob balansi uchun kechikish mumkin emas (Write-Through).

O'zgarish chastotasini baholang — kuniga bir marta yangilanadigan ma'lumotlar (mahsulot katalogi, shaharlar lug'ati) TTL bilan ajoyib ishlaydi. Sekundiga o'nlab marta o'zgaradigan ma'lumotlar (onlayn statuslar, valyuta kurslari) WebSocket yoki Firebase Cloud Messaging orqali push bekor qilishni talab qiladi.

Manbaning o'qish narxini hisobga oling — agar manba 10 ta jadvaldagi qimmat SQL so'rovi yoki cheklovlari bo'lgan tashqi API bo'lsa, uzoq TTL bilan agressiv keshlashni ishlatish, lekin eskirgan ma'lumotlarni push bekor qilish bilan kompensatsiya qilish yaxshiroq. Agar o'qish arzon bo'lsa (in-memory lookup), qisqa TTL va Write-Invalidate ishlatilishi mumkin.

Google I/O (2025) ma'lumotlariga ko'ra, mobil ilova uchun odatiy naqsh — Stale-While-Revalidate: foydalanuvchi darhol keshlangan ma'lumotlarni ko'radi, ilova esa fonda ularning dolzarbligini tekshiradi va yangilaydi. Bu javob tezligi va dolzarblikni murosasiz birlashtiradi. HTTP Cache-Control sarlavhasi stale-while-revalidate direktivi bilan Android 10 va iOS 13 dan boshlab qo'llab-quvvatlanadi.