Logo GH

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.

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.