Logo GH

Keshlash strategiyasi

1) Nima uchun va qayerda keshlash kerak?

Kesh - bu latentlik va qimmatbaho resurslarga (CPU/DB/tashqi API) yukni kamaytiradigan tez xotira qatlami. Muhim maqsadlar:
  • Tezlik (p95/p99 past), qiymat (egress/CPU kam), barqarorlik (cho’qqi ostidagi kamroq bog’liqlik).
  • Cho’qqilarni tekislash va «shovqinli qo’shnilardan» ajratish.
Namunaviy darajalar:

1. Mijoz (brauzer/mobil) - HTTP-kesh, IndexedDB, local storage.

2. Edge/CDN - POP tugunlari foydalanuvchiga yaqinroq, statik va API qismini kesh qiladi.

3. L7-shlyuz/Reverse-proxy - Nginx/Envoy/Varnish (mikrokesh, SWR).

4. Service kesh - klaster ichida Redis/Memcached.

5. Jarayon ichidagi - in-memory (Caffeine/Guava/LRU-map).

6. DBdagi kesh - moddiy tasavvurlar, ikkilamchi indekslar.

Qoida: isteʼmolchiga iloji boricha yaqinroq kesh qiling, lekin haqiqatni bir marta saqlang.

2) Keshlash patternlari

2. 1 Cache-aside (“lazy loading”)

Dastur birinchi navbatda keshdan oʻqiydi; xato yuz berganda - manbadan, so’ngra keshga yozadi.
Afzalliklari: soddaligi, nazorati. Kamchiliklar: sovuq startlar, kelishmovchilik oynalari.

2. 2 Read-through

Oʻqish har doim xato roʻy berganda manbaga oʻtadigan kesh (kutubxona/proksatsiya qatlami) orqali amalga oshiriladi.
TTL/serilizatsiya siyosatini markazlashtirish qulay.

2. 3 Write-through / Write-back (write-behind)

Write-through: keshga yozish va manbani sinxron → muvofiqlik yuqoriroq, yashirlik yuqoriroq.
Write-back: keshga yozish, manbaga asinxron flesh yozish → tez, ammo yo’qotish va mojarolar xavfi.

2. 4 Refresh-ahead (proactive)

«TTL yaqinda tugaydi» deb bashorat qiladi va stampede oldini olish uchun orqa fonda kalitni yangilaydi.

2. 5 Negative caching

Qisqa TTL uchun «maʼlumot yoʻq/404/boʻsh» keshlash manbaga yukni kamaytiradi.

2. 6 Micro-caching

Juda qisqa TTL (0. 5-5 s) L7 da «deyarli dinamika» uchun (ro’yxatlar, asosiy) - dumlarini keskin pasaytiradi.

3) HTTP kesh: sarlavhalar va nazorat

3. 1 Asosiy sarlavhalar

`Cache-Control`: `max-age`, `s-maxage` (для shared кэшей), `public/private`, `no-store`, `stale-while-revalidate`, `stale-if-error`.
Validatorlar:’ETag’(xesh tarkibi),’Last-Modified’.
’If-None-Match’,’If-Modified-Since’→ 304 Not Modified shartlari bilan so’rovlar.

3. 2 Vari va kalitlar

’Vary: Accept-Encoding, Authorization, Cookie, Accept-Language’ - keshning turli variantlarini shakllantiradi. Kardinallikni «portlatmaslik» uchun «Vary» ni minimallashtiring.

3. 3 HTTP javobining misoli


Cache-Control: public, max-age=60, s-maxage=300, stale-while-revalidate=60
ETag: "a1b2c3"
Vary: Accept-Encoding

4) Kalitlar va TTLni loyihalash

4. 1 Kalitlar

Tuzish:’tenant: user: {id}: profile: v3’(sxemaning versiyasini yoqing).
PII kalitidan qoching.
To’plamlar uchun - kalit + so’rov parametrlari (normallashtirilgan va saralangan).

4. 2 TTL va muvofiqlik

Qisqa TTL kelishmovchilikni kamaytiradi, lekin xatolarni oshiradi.
Tanqidiy ma’lumotlar uchun - validatorlar (’ETag’) va SWR (stale-while-revalidate).
Kamdan-kam o’zgaruvchilar uchun - uzoq muddatli TTL + nogironlik «bombochkalari».

4. 3 Version/basting

Mos kelmaydigan o’zgarishlar bo’lsa, kalit prefiksini/versiyasini o’zgartiring (’v2 → v3’).
Statik manbalar uchun - fayl nomidagi content hash.

5) Nogironlik: strategiya va amaliyot

5. 1 Toʻgʻridan-toʻgʻri olib tashlash

’DEL key ’/’ PURGE’ proksi. Xavf: o’chirish va ko’p martalik o’quvchilar o’rtasidagi poygalar.

5. 2 Taglar/Surrogate keys

Hujjatni taglar toʻplami bilan bogʻlang (kategoriya/muallif). Nogironlik - teglar bo’yicha.
В Varnish/Edge — `Surrogate-Key: article:42 tag:author:7` + `BAN tag:author:7`.

5. 3 Event-driven nogironlik

Pub/Sub (Kafka/NATS): manba o’zgarganda, «invalidate» voqeasini e’lon qilamiz.
Kesh konsumerlari kalitlarni tinglaydi va olib tashlaydi/yangilaydi.

5. 4 Ikki fazali

Avval kalitni eskirgan (soft TTL) deb belgilaymiz, stale-ga xizmat ko’rsatamiz, fonda yangilaymiz va atom bilan almashtiramiz.

6) Stampede/dogpile va issiq kalitlarga qarshi kurash

6. 1 Request coalescing (singleflight)

Bitta prodyuser kalitni yangilaydi, qolganlari natijani kutmoqda (muteks/yorliq «yangilanmoqda»).

6. 2 Jitter к TTL

Sinxron ± oldini olish uchun TTLga tasodifiy (10-20%) qo’shing.

6. 3 Soft-TTL + hard-TTL

soft-TTLgacha keshdan xizmat ko’rsatamiz, triggerim refresh bilan parallel ravishda; hard-TTL bo’yicha - xato deb hisoblaymiz.

6. 4 Issiq kalitlar

Umumiy keshlar (two-tier).
Issiq kalitni bir nechta shardlarda replikatsiya qilish va random tanlash (faqat read-only uchun).
Aniq kalitni yangilash uchun rate limit.

6. 5 Redis + Lua misoli (singleflight-eskiz)

lua
-- SETNX lock with TTL to avoid deadlocks local ok = redis. call("SET", KEYS[1], "1", "NX", "EX", ARGV[1])
if ok then return "LOCKED"
else return "WAIT"
end

7) Chetlatish va keshga qabul qilish siyosati

7. 1 Eviction

LRU: oddiy va mahalliy uchun yaxshi.
LFU: «uzoq umr ko’radigan» issiq kalitlarda yaxshiroqdir.
ARC/TinyLFU: balans recency/frequency.

7. 2 Admission (kirish)

Ulkan noyob ob ob’ektlarni (TinyLFU/Bloom filtrlari) kiritmang.
«O’lcham/yashirin» chegarasida katta qiymatlarni (LZ4/Zstd) siqish.

8) Shardalashtirish va topologiyalar

8. 1 Consistent hashing

Tugmalar boʻyicha kalitlarni barqaror taqsimlaydi, klaster oʻsganda/siqilganda harakatlarni kamaytiradi.

8. 2 Topologiyalar Redis/Memcached

Redis Cluster (slotlar/shardlar), Sentinel (feilover), read-only replikatsiyasi.
Memcached - server darajasida replikatsiyasiz mijoz sayd sharding (ketama hashing).

8. 3 Lokal + taqsimlangan

Kaskad: in-proc (mikro-TTL/LRU) → Redis (TTL uzunroq) → manba.
Ikki nuqtali TTL va kesh validatorlariga ehtiyot boʻling.

9) Edge, CDN va L7-kesh

9. 1 Micro-cache на Nginx

nginx proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=api:100m inactive=10m;
map $request_method $skip_cache { default 0; POST 1; PUT 1; DELETE 1; }

server {
location /api/list {
if ($skip_cache) { add_header Cache-Control "no-store"; }
proxy_cache api;
proxy_cache_valid 200 2s;       # micro-cache proxy_cache_use_stale error timeout updating;
proxy_cache_background_update on;   # SWR add_header X-Cache $upstream_cache_status;
proxy_pass http://upstream;
}
}

9. 2 Envoy (SWR va shartlar)

yaml http_filters:
- name: envoy. filters. http. cache typed_config:
"@type": type. googleapis. com/envoy. extensions. filters. http. cache. v3. CacheConfig typed_config:
"@type": type. googleapis. com/envoy. extensions. http. cache. file_system_http_cache. v3. FileSystemHttpCacheConfig cache_path: "/var/cache/envoy"

9. 3 Varnish (Surrogate keys)

Paketli nogironlik uchun’Surrogate-Key’va’ban’taglaridan foydalaning.

10) Kesh va ma’lumotlarning muvofiqligi

10. 1 Read-your-writes

Foydalanuvchi profillari/chiqindilar qutisi uchun qisqa TTL yoki kesh orqali yozish (write-through) yoki mijozning markalanishini (yozilgandan keyin N soniya davomida bypass) taʼminlang.

10. 2 Eventual vs Strong

Tavsiya/tahliliy uchun - eventual + uzun TTL.
Pul/buyurtma maqomlari uchun - qisqa TTL, validatsiya, ba’zan muhim yo’llarda keshsiz.

10. 3 Invariantlar

Qattiq TTL va qayta tekshirmasdan, xavfsizlik/ACLga taʼsir qiluvchi maydonlarni keshlamang.

11) Kuzatuv, SLO va boshqaruv

11. 1 Metrika

hit_ratio (общий и per-route), byte_hit_ratio, miss_rate.
stampede_prevented_total, refresh_ahead_total, ban/purge_total.
Latentlik: p50/p95/p99 kesh vs manba.
hot_keys_topN va ularning QPS/baytlari.

11. 2 Logi i trassirovki

’X-Cache: HIT/MISS/STALE/UPDATING’ ga murojaat qiling.
Treyslarda javob manbasini belgilang (’cache = true’,’tier = edge’service’local’).

11. 3 SLO yondashuvi

Masalan: "API/catalog p99 ≤ 250 ms, cache hit ≥ 85%, stampede ≤ 0. 1% soʻrovlar".

11. 4 Runbooks

«Xatolar ortib bormoqda» → TTL, isitish/nogironlik, hot-keys, kesh hajmi va qabul qilish siyosatini tekshirish.

12) Xavfsizlik va ko’p tenantlik

Tenant-id’ni kalitlarga (va’Vary’ga HTTP bilan) joylashtiring.
Shaxsiy javoblaringizni’public’deb keshlamang.
Sezgir maʼlumotlar bilan keshni shifrlang yoki faqat PII/ID emas.

13) Namunaviy retseptlar

13. 1 Katalog/lenta (deyarli dinamika)

Edge-mikrokesh 1-3 s + SWR, ichida - Redis 15-60 s, yangilanish voqealari bo’yicha nogironlik.

13. 2 Foydalanuvchi profili

Cache-aside bilan TTL 30-120 s, bypass 5-10 s bilan profilni yangilashdan keyin (cookie/xeder) yoki write-through.

13. 3 Valyuta kurslari/ma’lumotnomalar

Uzoq TTL (daqiqa-soat) + yangi ma’lumotlarni e’lon qilishda maqsadli nogironlik; shartli GET uchun’ETag’.

13. 4 Qidiruv natijalari

Edge-mikrokesh 1-2 s, ichida - refresh-ahead va coalescing, kalitda query-parametrlarni normallashtirish.

14) Anti-patternlar

Nogironligi bo’lmagan kesh: faqat TTLda umid → uzoq oynalar ahamiyatsizdir.
Gigant’Vary’: «portlash» variantlari → past hit-rate.
prod/experiments → ifloslanish uchun yagona kesh.
TTL tugaganida manbada stampede → choʻqqidan himoya yoʻq.
Qat’iy kafolatsiz pul/huquq/ACL kesh.
Kompresssiya «hammasi ketma-ket» - ortiqcha CPU, kichik ob’ektlarda p99 yomonlashuvi.

15) Joriy etish chek-varaqasi

  • Kesh darajalari va ularning maqsadlarini aniqlang (edge/service/local).
  • Kalitlarni loyihalashtiring (version, tenant, parametrlarni normallashtirish).
  • Pattern (cache-aside/read-through/refresh-ahead) ni tanlang.
  • TTL/soft-TTL/jitterni moslab, SWRni yoqing.
  • coalescing/singleflight, stampede himoyasini amalga oshiring.
  • Nogironlikni tashkil qiling (voqealar, teglar, purge/ban).
  • Hit-ratio/latentlik metrlarini va’X-Cache’dashbordlarini kiriting.
  • Issiq kalitlar bilan yuklash testlarini o’tkazing.
  • SLO va runbooks.
  • Xavfsizlik/tenant-izolyatsiya va’Vary’ni tekshiring.

16) FAQ

Q: Nima tanlash kerak - cache-aside yoki read-through?
A: Oddiy xizmatlar uchun - cache-aside. Markazlashtirish va yagona siyosat kerak - read-through.

Q: Optimal TTLni qanday tushunish mumkin?
A: Yo’l qo’yiladigan eskirish, yangilanish chastotasi va maqsadli hit-rate; jitter qo’shing va p95/p99/qiymatini kuzating.

Q: write-back qachon mos keladi?
A: eventual-konsistentlik maqbul bo’lgan va «qo’shimcha yozish» uchun ishonchli navbat/log mavjud bo’lgan yuqori yuklangan oqimlar uchun.

Q: Vakolatli javoblarni keshlash mumkinmi?
A: Ha, lekin’private’va/yoki tenant/user’ni’Vary’kalitiga kiriting. truly-private uchun - mijoz keshi.

Q: Keshni qanday isitish kerak?
A: Mashhur kalitlar ro’yxati, background-vormer, loglardan replay, reliz/cho’qqi oldidan isitish (qora juma va boshqalar).

17) Yakunlar

Samarali keshlash - bu kalitlarning dizayni + oqilona TTL + hodisalar bo’yicha nogironlik, SWR/refresh-ahead va stampede himoyasi bilan mustahkamlangan to’g’ri tanlangan pattern. Keshni darajalarga (mijoz/edge/xizmat) ajrating, kuzatuv va SLOni qo’shing - va barqaror latentlik, oldindan aytib bo’ladigan qiymat va eng yuqori yuklarga chidamlilikni oling.

Contact

Biz bilan bog‘laning

Har qanday savol yoki yordam bo‘yicha bizga murojaat qiling.Doimo yordam berishga tayyormiz.

Integratsiyani boshlash

Email — majburiy. Telegram yoki WhatsApp — ixtiyoriy.

Ismingiz ixtiyoriy
Email ixtiyoriy
Mavzu ixtiyoriy
Xabar ixtiyoriy
Telegram ixtiyoriy
@
Agar Telegram qoldirilgan bo‘lsa — javob Email bilan birga o‘sha yerga ham yuboriladi.
WhatsApp ixtiyoriy
Format: mamlakat kodi va raqam (masalan, +998XXXXXXXX).

Yuborish orqali ma'lumotlaringiz qayta ishlanishiga rozilik bildirasiz.