GH GambleHub

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.

Telegram
@Gamble_GC
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.