GH GambleHub

Kesh arxitekturasi: Redis, Memcached

Kesh arxitekturasi: Redis, Memcached

1) Kesh qachon va nima uchun

Maqsadlar: yashirlikni kamaytirish, DB/PSP/tashqi APIlarni tushirish va cho’qqilarni yumshatish.
Kesh qatlamlari ko’pincha ko’p darajali: in-process (L1) → service-level (Redis/Memcached L2) → edge/CDN. Ichki kesh «issiq» oʻqishni tezlashtiradi, L2 - xizmatlar uchun umumiy, edge - ommaviy kontent uchun.

2) Redis vs Memcached - qisqacha

MezonRedisMemcached
Maʼlumot turlariSatrlar, xeshlar, roʻyxatlar, toʻplamlar, zset, bitmaplar, HyperLogLog, Streams, Bloom/CF (modullar orqali)Kalit-qiymat (satr)
PersistentlikMoslashda AOF/RDB, no-fsync-lossYoʻq
KlasterRedis Cluster (sharding, failover )/SentinelMijoz shard, native failover
Bitimlar/skriptlarMULTI/EXEC, EVAL (Lua), atom operatsiyalariYoʻq
TTL/evictionSiyosatni nozik moslashBazaviy
Yashirlik/xotiraBiroz koʻproq overheadJuda engil, oldindan aytib bo’ladigan

Qoida: Agar murakkab maʼlumot tuzilishi, persistentlik, pub/sub/oqim/skriptlar kerak boʻlsa, Redisni oling. Agar durability bo’lmagan juda oddiy, tez, arzon KV kesh qatlami - Memcached.

3) Keshlash namunalari

3. 1 Cache-aside (lazy)

Dastur keshdan oʻqiydi → xato → DBdan oʻqiydi → TTL keshiga qoʻyadi.

Oddiy TTL nazorati, keshdan mustaqillik. − Xatolarda «boʻron» boʻlishi mumkin.

3. 2 Read-through

Mijoz/proksining oʻzi xato roʻy berganda originni tortadi va keshga qoʻyadi.

Markazlashtirilgan mantiq. − Murakkab infratuzilma.

3. 3 Write-through / Write-behind

Write-through: avval keshga, keyin DBga yozish.
Write-behind: navbatga yozish, DBdagi asinxron flash (goʻzallashganda potentsial yoʻqotish - jurnal kerak).

3. 4 Two-tier (L1+L2)

L1 (in-process) qisqa TTL va soft TTL, L2 (Redis/Memcached) - «kesh haqiqati». pub/sub orqali nogironlik.

4) TTL, bo’ronlar va konsistentlik

TTL: Maʼlumotlarni oʻzgartirish chastotasiga yaqinlashtiring. TTL (jitter):’ttl = base ± rand (0.. base0. 1)’- sinxron tugashlarni olib tashlaydi.

Dogpile (thundering herd): xatolarni himoya qiling:
  • Singleflight: faqat bitta jarayon qiymatni qayta ishlab chiqadi (Lua namunasiga qarang).
  • Soft-TTL + background refresh:’soft _ ttl’dan keyin eskirgan (stale) ni bering va orqa fon bilan yangilang.
  • Semaphore/lock: `SET key:lock value NX PX=2000`.
  • API javoblari uchun Near-stale:’stale-while-revalidate’(8-bo’limga qarang).

5) Kalitlar, neyspeyslar, serializatsiya

5. 1 Kalitlarni nomlash

Namuna: ’{domain}: {entity}: {id}: {field} ’

Misollar:
  • `user:profile:42` `catalog:product:1001:v2` `psp:rates:2025-11-03`

Sxemaning versiyasini qoʻshing (’: v2’) - bu ommaviy nogironlikni osonlashtiradi.

5. 2 «Fazo versiyasi» orqali neyspeyslar

Kalit’ns: catalog = 17’tuting. Haqiqiy kalitlar:’catalog: 17: product: 1001’. Katalog global nogironligi uchun shunchaki’ns: catalog’ni kiriting.

5. 3 Seriallashtirish/siqish

JSON - qulay, ammo og’ir. MessagePack/CBOR’dan foydalaning.
Katta LZ4/ZSTD (> 1-2 KB) uchun siqishni yoqing. Redisda - mijoz tomonida.

6) Issiq kalitlar va shardalashtirish

Hot-keys: top-N’ni hit/miss/byte orqali kuzating. Oʻta issiq kalitlar uchun:
  • Replicated read pattern: bir nechta shard-kalitlar’hot: k: 1.. N’qiymatini takrorlang, oʻqishda tasodifiy tanlang.
  • Local L1: nogironlikka obuna boʻlgan jarayonni xotirangizda saqlang.
Chardlash:
  • Redis Cluster - nativ (16384 hash-slot).
  • Memcached - mijoz konsistent xeshi.
  • Hash-tag Redis’{...}’da’user: {42}: profile’va’user: {42}: limits’tugmalarini oʻrnatadi.

7) Siqib chiqarish siyosati va

Redis `maxmemory-policy`: `allkeys-lru`, `volatile-lru`, `allkeys-lfu`, `noeviction` и т. д. Kesh uchun odatda’allkeys-lru ’/’ allkeys-lfu’.
Memcached — LRU на item-slab.
Kalit oʻlchami va value: max item size (Memcached andoza 1 MB, tyuning slab).
Xotiraning oshib ketishi oldindan aytib boʻlmaydigan darajada buzilishi kerak: aktiv yoʻlda’noeviction’emas.

Redis (parcha):

maxmemory 32gb maxmemory-policy allkeys-lfu hz 50 tcp-keepalive 60

8) Bo’rondan himoya patternlari - kod

8. 1 Redis Lua singleflight (psevdo)

lua
-- KEYS[1] = data_key, KEYS[2] = lock_key
-- ARGV[1] = now_ms, ARGV[2] = soft_ttl_ms, ARGV[3] = hard_ttl_ms, ARGV[4] = lock_ttl_ms local payload = redis. call("GET", KEYS[1])
if payload then local meta = redis. call("HGETALL", KEYS[1].. ":meta")
local last = tonumber(meta[2] or "0")
if tonumber(ARGV[1]) - last < tonumber(ARGV[2]) then return { "HIT", payload }
end if redis. call ("SET," KEYS [2], "1," "NX," "PX," ARGV [4]) then return {"REFRESH," payload} - one worker updates, the rest give stale end return {"STALE," payload}
end if redis. call("SET", KEYS[2], "1", "NX", "PX", ARGV[4]) then return { "MISS", nil }
end return { "BUSY", nil }

8. 2 Node. js cache-aside (soddalashtirilgan)

js const v = await redis. get(key);
if (v) return decode(v);
const lock = await redis. setNX(key+":lock", "1", { PX: 1500 });
if (lock) {
const fresh = await loadFromDB(id);
await redis. set(key, encode(fresh), { EX: ttl, NX: false });
await redis. del(key+":lock");
return fresh;
} else {
await sleep(60);           // short backoff const retry = await redis. get (key) ;//give someone's already filled return decode (retry);
}

9) Nogironlik va kelishuv

Hodisa boʻyicha: DBga oʻzgartirish kiritilganda’pub/sub’hodisani’invalidate: {ns}: {id}’→ obunachilar kalitlarni olib tashlaydilar.
Taymer boʻyicha: Tez-tez oʻzgaradigan maʼlumotlar uchun qisqa TTL.
Version:’ns:’kalitlariga qarang.
Outbox: nogironlikni yetkazib berish kafolati (log/topik, retrajdagi voqea).
Kesh operatsiyalarining idempotentligi:’SETXX/SETNX’, versiyalar (’etag’) va inkrement uchun xesh maydonlaridan foydalaning.

10) Replikatsiya, klaster, failover

10. 1 Redis

Sentinel: avtomatik failover master-replica (steytFUL IP/nomi).
Cluster: shardlash + avtomatik failover; mijozlar’MOVED/ASK’tahririyatlarini qo’llab-quvvatlashlari kerak.
AOF/RDB: kesh uchun odatda’appendfsync everysec’, persistentsiz (toza kesh sifatida).

10. 2 Memcached

Qutidan nusxa olish mumkin emas. Ishonchlilik - ko’p eshikli shard + n’(client-side) takrorlash orqali.
Nod tushganda - xatolarning ko’payishi va keshni «qayta o’rganish».

10. 3 K8s va tarmoq jihatlari

Redis/Memcached pod’larni tez-tez qayta yetkazib berishni yoqtirmaydi; StatefulSet + AZ antipodlaridan foydalaning, oʻrnatilgan PVC/POD IP.
PodDisruptionBudget va TopologySpreadConstraints.

11) Tranzaksiyalar, skriptlar va atomarlik (Redis)

INCR/DECR, HINCRBY - hisoblagichlar, kvotalar, rate-limits (faqat persist hisobga oling).
MULTI/EXEC - atom buyruqlari paketi.
Lua (EVAL) - poygasiz read-modify-write.
Pipeline - RTTni kamaytiradi (ayniqsa tarmoq xopida).

Misol rate-limit (token bucket, soddalashtirilgan):
lua
-- KEYS[1]=bucket, ARGV[1]=capacity, ARGV[2]=refill_rate_per_sec, ARGV[3]=now_ms
-- Returns 1 if the token is issued, otherwise 0

12) Navbatlar, pub/sub va Streams (Redis)

Pub/Sub: nogironlik, signallar. Faqat onlayn tinglovchilar.
Streams: tasdiqlangan voqealar navbati (ACK), iste’molchilar guruhi, retralar - write-behind/fan-autlar uchun qulay.
Lists (’BRPOP’): oddiy navbatlar.
Redisni «hamma narsaning yagona shinasi» sifatida ishlatmang - bu Kafka emas, kesh/tezkor shinadir.

13) Xavfsizlik va foydalanish

Tarmoqlarni izolyatsiya qilish/VPC, mTLS ingress darajasida, ACL/parollar (’requirepass ’/ACL Redisda 6 +).
Disable dangerous buyruqlari Redisda (’CONFIG’,’FLUSHALL’,’KEYS’) ACL orqali.
Memcached uchun - ommaviy interfeyslarni tinglamang,’-U 0’(UDPsiz), faqat shaxsiy tarmoqlar.
PII saqlanmasligi; agar kerak bo’lsa - dastur darajasida qisqa TTL + shifrlash.

14) Kuzatish va xizmat ko’rsatish

Asosiy metriklar:
  • Hit ratio/Miss ratio (namespace/marshrut boʻyicha).
  • Latency p95/p99 jamoalar’GET/SET/MGET’, timeouts.
  • Evictions и OOM errors.
  • Replication lag (Redis), cluster state, migrate/rehash events.
  • Top-N keys trafik/bayt (sampling) bo’yicha.
  • Loglar: sekin buyruqlar (’slowlog’), tarmoq xatolari.
  • Dashbordlar: umumiy (CPU/RAM/connections), jamoalar, klaster slotlari, sentinels, Prometheus eksportchilari orqali.

15) Konfigi va tarqatish - misol

15. 1 Redis Sentinel (parcha)


port 6379 protected-mode yes appendonly yes appendfsync everysec maxmemory-policy allkeys-lfu
`sentinel. conf`:

sentinel monitor m1 10. 0. 0. 11 6379 2 sentinel auth-pass m1 sentinel down-after-milliseconds m1 5000 sentinel failover-timeout m1 60000

15. 2 Redis Cluster (helm values, soddalashtirilgan)

yaml cluster:
enabled: true nodes: 6  # 3 masters + 3 replicas persistence:
size: 100Gi resources:
requests: { cpu: "500m", memory: "2Gi" }

15. 3 Memcached (deployment)

yaml containers:
- image: memcached:1. 6 args: ["-m", "32768", "-I", "2m", "-v", "-t", "8", "-o", "modern"]
ports: [{ containerPort: 11211 }]

15. 4 NGINX read-through proxy sifatida (API konturi)

nginx proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=api:100m max_size=10g inactive=10m;
map $request_uri $cache_key { default "api:$request_uri"; }
location /api/ {
proxy_cache api;
proxy_cache_valid 200 1m;
proxy_cache_use_stale updating error timeout http_500 http_502 http_503 http_504;
proxy_cache_lock on;      # singleflight на уровне NGINX proxy_cache_key $cache_key;
proxy_pass http://backend;
}

16) Test va geytlar

«Sovuq/issiq/issiq kesh» yuklash profillari.
Inyeksiya (purge ommaviy) - origin «qayta o’rganishga» bardosh berishi kerak.
Alertlar: hit-ratio keskin pasayishi, miss latency o’sishi, evictions ko’chkisi, timeouts o’sishi.

17) Anti-patternlar

«Haqiqatni» Redisda AOF/RDBsiz va zaxirasiz saqlash.
Oʻzgaruvchan maʼlumotlar uchun TTL = 0 (muddatsiz) → abadiy nomutanosiblik.
Ommaviy’KEYS’prodda.
Jitter/soft-TTL → sinxron tugash va bo’ron yo’qligi.
Barcha buyruqlar uchun bir instant shardlash/replikasiz.
Yadro/skriptlarni talab qiladigan vazifalar uchun Memcacheddan foydalanish.

18) Joriy etish chek-varaqasi (0-45 kun)

0-10 kun

Namunani tanlash (cache-aside + L1/L2), kalitlarni, TTL, neyspeyslarni tasvirlash.
Jitter/soft-TTL, singleflight ni yoqish; bazaviy alertlar/dashbordlar.
Redis uchun - ACL, protected-mode, slowlog, maxmemory-policy moslamalari.

11-25 kun

Shardga oʻtish (Redis Cluster yoki mijoz xeshi), replikalar.
pub/sub yoki neyspeys versiyasi orqali nogironlik; DBda outbox.
Keshni «qayta o’qitish» yuklama testlari; limiting origin.

26-45 kun

Avtosanoat/kanareya TTL, reliz oldidan isitish.
Streams write-behind/fon urish uchun.
Hit-ratio, top-kalitlar, xotira qiymati bo’yicha haftalik hisobotlar.

19) Etuklik metrikasi

Hit-ratio L2 ≥ 80% (yo’nalishlar/neyspeyslar bo’yicha statistika).
P95 GET <2-3 ms (in-DC), xatolar <SLO origin.
0 ommaviy nogironlikda bo’ron (testlar bilan isbotlangan).
Neyspeyslarni avtomatik tarzda nogironlashtirish va versiyalash.
Shardlash/replikatsiya 1 tugunning buzilishini sezilarli tanazzulsiz qoplaydi.

20) Xulosa

Keshning kuchli arxitekturasi - bu kalitlar va TTL intizomi, bo’rondan himoya qilish, to’g’ri shardallash va oldindan aytib bo’ladigan siqib chiqarishdir. Redis boy semantika, persistentlik va atomarlik beradi; Memcached - maksimal soddalik va tezlik. Kuzatuvchanlikni, hodisalar bo’yicha nogironlikni qo’shing, L1 + L2 va kesh tasodifiy yiqilish va «mistik» xatolar manbai emas, balki platformaning tezlashtiruvchisiga aylanadi.

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.