Texnologiyalar va infratuzilma → Kesh darajalari va ma’lumotlarni saqlash

Kesh darajalari va maʼlumotlarni saqlash

1) Nega ko’p qatlamli kesh kerak

Kesh - bu «qimmat» quyi tizimlarga (DB, tashqi API, tarmoqlar) bormasdan javobga qisqa yo’l. Ko’p qatlamlilik yukni taqsimlaydi: brauzer → CDN/edge → amaliy qatlam → taqsimlangan kesh → DB/saqlash. Maqsad: P95/P99 kamaytirish, originni tushirish, cho’qqilarga chidash va baytni arzonlashtirish.

2) Kesh darajalari xaritasi

1. Браузер: `Cache-Control`, `ETag`, `Last-Modified`, `stale-while-revalidate`.
2. CDN/Edge: TTL/ключ, Vary, Signed URLs, image-resize; tiered/shield.
3. API Gateway/Service Mesh: xavfsiz GET uchun qisqa saqlanadigan javob keshi.
4. Ilova (in-process): LRU/LFU, «issiq» kalitlar uchun near-cache, millisekundlar.
5. Taqsimlangan kesh (Redis/Memcached): dinamika uchun asosiy qatlam.
6. DB keshlari: Pg/Innodb buferlari, PgBouncer multiplexing, materialized views.
7. Disk/obyekt storlari: precomputed snapshots, blob-kesh (masalan, S3 + CDN).

Printsip: "Foydalanuvchiga qanchalik yaqin bo’lsa, TTL shunchalik qisqa va shaxsiylashtirish kamroq bo’ladi; ma’lumotlarga qanchalik yaqin bo’lsa, konsistentlik siyosati shunchalik boy bo’ladi".

3) Keshlash patternlari

Cache-Aside (Lazy): o’qish → MISSda manbadan yuklash → keshga qo’yish. Oddiy, TTL nazoratini beradi.
Read-Through: ilova o’zini manbadan tortib oladigan kesh orqali o’qiydi. Siyosatni markazlashtirish qulay.
Write-Through: yozuv darhol keshga va manbaga oʻtadi. Ko’proq, lekin yozuv bo’yicha qimmatroq.
Write-Back (Write-Behind): keshga yozyapmiz, manba asinxron (navbat) yangilanadi. Yuqori tezlik, yetkazib berish kafolati va idempotentlik talab etiladi.
Refresh-Ahead: «yuqori» kalitlar uchun TTL tugagunga qadar yangilanadi.

Qayerda: o’yin kartochkalari/kataloglar - cache-aside/read-through; hisoblagichlar/liderbordlar - write-back + CRDT/agregatsiyalar; valyuta/limitlar ma’lumotnomalari - nazorat qilinadigan TTL bilan read-through.

4) Kalitlar, segmentatsiya va neyming

Шаблон: `domain:entity:{id}:v{schema}|region={R}|currency={C}|lang={L}`.
Faqat javobni oʻzgartiradigan narsalarni (mintaqa, valyuta, til, sxema versiyasi) kiriting.
Sxemalarni versiya qilish: mos kelmaydigan o’zgarishlarda, ommaviy purge’dan qochib, kalitda’vN’ni oshiring.
Mahsulot/tenant boʻyicha Namespacing:’tenant: {t}:...’- multi-tenant uchun juda muhim.
Bloom filtri «kalitning mavjudligi» manbaga sayohatni kamaytirishi mumkin.

5) TTL, tazelik va nogironlik

• statika (xeshlangan fayllar): 30-365 kun +’immutable’;
• kataloglar/bannerlar: 5-60 daqiqa +’stale-while-revalidate’;
• yetakchi bordlar/kotirovkalar: 2-15 soniya;
• ma’lumotnomalar (valyutalar/limitlar): 1-10 daqiqa.
• Hodisalar bilan nogironlik:’product. updated’→ nuqta kaliti/prefiksni nogironlashtirish.
• Tag-based purge: guruhli tozalash (reklama/katalog chiqarilishi).
• Soft-Expiry: TTL tugagandan so’ng eskirganini’stale’deb beramiz, bir vaqtning o’zida yangilaymiz (SWR/SIE).
• Versioned Keys> ommaviy purge: arzonroq va xavfsiz.

6) Stampede, «issiq» kalitlar va raqobat

• Single-flight (request coalescing): bitta rahbar kalitni yangilaydi, qolganlari kutmoqda.
• TTL jitter: bir vaqtning o’zida qulashdan qochib, oqimlarni yuvamiz.
• SWR lokal: muddati oʻtgan qiymatni foydalanuvchiga beramiz, fonda yangilaymiz.

• «issiq» kalitni o’qish orqali taqsimlangan bir nechta’key # 1.. N’slotlariga replikatsiya qilish;
• jarayon xotirasida near-cache;
• prewarm/refresh-ahead cho’qqilar oldidan (turnirlar/o’yinlar).
• Og’ir kalitlar uchun konkarrensi yangilanish limitlari.

7) Konsistentlik va kross-qatlamlar

Write-invalidate: manbaga yozilganda - tegishli kalitlarni (pub/sub) sinxron ravishda nogironlashtiring.
Read-repair: Agar tafovut boʻlsa, keshni toʻgʻri qiymat bilan yangilang.
Eventual vs Strong: tanqidiy pul operatsiyalarini to’g «ridan to’g» ri/qisqa TTL bilan o’qiymiz; UI-vitrinalar va statistika - eventual.
CRDT/agregatorlar: taqsimlangan hisoblagichlar/reytinglar uchun - «merge-safe» (G-Counter, oqimlarda Top-K) tuzilmasi.
Kaskadli nogironlik: «o’yin» ning yangilanishi kartochka + ro’yxat + foydalanuvchi tavsiyalari keshini nogironlashtiradi.

8) Seriallashtirish, siqish va formatlash

Formatlar: Protobuf/MessagePack JSON tezroq; CDN/brauzer uchun - JSON bilan Brotli.
Redis kompresssiyasi:> 1-2 KB ob’ektlar uchun foydalidir, lekin CPUni kuzatib boring.
Partial responses/talab bo’yicha maydonlar: kamroq bayt → kamroq TTFB va RAM.

9) Siqib chiqarish siyosati va

LRU (andoza) - xavfsiz; LFU - «mashhur» kontent uchun yaxshiroqdir.
Kalit/qiymatlar oʻlchami: nazoratga oling (metriklar’avg value size’,’max’).
Bitta mahsulot butun keshni yemasligi uchun namespace/tenant kvotalari.

10) Xavfsizlik va PII/PCI

Shaxsiy/moliyaviy ma’lumotlarni CDN/edge va umumiy qatlamlarda keshlamaslik; tokenlar/proyeksiyalardan foydalaning.
Client-side crypto orqali Redisdagi sezgir qiymatlarni shifrlash (TTL nazoratini yoʻqotishga ehtiyotkorlik bilan).
Qattiq ACL va tarmoqlarni izolyatsiya qilish; provayderlarga egress uchun belgilangan NAT/IP.

11) Kuzatuv va SLO kesha

• Hit Ratio (qatlamlar va prefikslar boʻyicha), Origin Offload.
• keshdan oldin/keyin TTFB/P95/P99, Latency Redis.
• Evictions, OOM, keyspace hits/misses.
• Stampede rate (parallel yangilanishlar ulushi), refresh time.
• Stale served % и Freshness lag.

• Oʻyin katalogi: Hit Ratio ≥ 85%, TTFB P95 ≤ 150 ms (edge).
• API-ma’lumotnomalar: Revalidation-hit ≥ 60%, P95 ≤ 200 ms.
• Redis: P99 operatsiyasi ≤ 5 ms, evictions soatiga 1% dan oshmaydi.

12) FinOps: kesh qiymati

$/GB-oy RAM vs $/RPS origin: qaytarish nuqtasini hisoblang.
Offload va egress: CDN + Redis mintaqa originidan chiqadigan trafikni kamaytiradi.
Image/WebP/AVIF va denormalizatsiya eng katta bayt tejamkorligini beradi.
«Qimmatbaho MISS»: «Bayt × MISS × mintaqa» tahlilini cheklang.

13) Misollar (parchalar)

13. 1 Cache-Aside single-flight (psevdokod)

python def get(key, ttl, loader):
val = redis. get(key)
if val: return val with single_flight (key): # only one updates val = redis. get (key) # double check if val: return val data = loader () # request to source redis. setex(key, ttl_with_jitter(ttl), serialize(data))
return data

13. 2. Hodisa bo’yicha nogironlikni e’lon qilish

json
{
"event": "game. updated",
"game_id": "g123",
"affected": ["catalog:list:region=TR", "game:card:g123:"]
}

Konsumer kanalga obuna bo’lib,’DEL ’/’ PUBLISH’ni kalitlar/teglarga mos qiladi.

13. 3 Sxema versiyasi va lokalli kalit

game:card:v2:id=g123    region=BR    currency=BRL    lang=pt-BR

14) Joriy etish chek-varaqasi

1. Kesh darajalari xaritasi va TTL matritsasi (statik/yarim statik/API).
2. Kalitlar neymingi: domen, sxema versiyasi, lokal/mintaqa/valyuta, tenant.
3. Pattern per-endpoint (aside/read-through/write-through/back) ni tanlash.
4. SWR/SIE, single-flight va TTL-jitter vs stampede.
5. Nogironlik (pub/sub), guruhlar uchun tag-purge.
6. «Issiq» kalitlar va cho’qqilardan oldin prewarm uchun Near-cache.
7. Formatlar va siqish (protobuf/MsgPack, Brotli), o’lchamni nazorat qilish.
8. LRU/LFU siyosati, namespace/tenant kvotalari.
9. SLO/метрики: hit ratio, latency, evictions, stale %, freshness lag.
10. Xavfsizlik: no-store uchun shaxsiy, tokenizatsiya, tarmoq/ACL.

15) Anti-patternlar

’no-cache’ ", va TTLdan voz kechish - nol offload.
Kalit barcha query/sarlavhalarni oʻz ichiga oladi → kardinallik portlashi.
Har bir chiqishda «butun CDN/Redis» ning ommaviy purge.
Stampede himoyasi yo’qligi va «top-kalitlar» ning bir martalik tugashi.
Yagona umumiy Redis kvotasiz/izolyatsiyasiz; «issiq» tenant butun keshni yeydi.
edge/CDN ga shaxsiy javoblarni keshlash.
Freshness/evictions → koʻr boshqaruv telemetriyasi yoʻq.

16) iGaming/fintech konteksti: amaliy notalar

Yetakchi bordlar/reytinglar: TTL 2-10 s, aggregate-oqimlar + CRDT, SWR nosozliklarda.
O’yinlar/bannerlar katalogi: CDN + Redis; kalit: mintaqa/valyuta/til; «promo: update» teglari bo’yicha nogironlik.
To’lov maqomlari: yozuv yo’lida keshsiz; o’qish - qisqa TTL (3-5 s ≤) yoki to’g «ridan to’g» ri so’rov.
KYC/AML javoblari: noto-PII turlarini kesh qiling, rasm/hujjatlarni Redisda saqlamang.
VIP-yo’l: alohida namespace/pool Redis, ustuvor xizmat.

Jami

Kuchli kesh strategiyasi - bu darajalar arxitekturasi, to’g’ri yangilanish namunalari, o’ylangan TTL/nogironlik, stampedaga chidamlilik, ehtiyotkor kalitlar va versiyalar, shuningdek, kuzatish va FinOps. Ushbu printsiplarga amal qilib, siz P95/P99 quyruqlarini barqarorlashtirasiz, manbalarga tushadigan yukni kamaytirasiz va millisekundning taxminiy qiymatini olasiz - bu mahsulot va biznes uchun eng muhimi.