Redis persistence va operatsiya: RDB, AOF, maxmemory va eviction

Qisqacha: Redis ma'lumotni xotirada saqlaydi, diskka ikki usulda nusxa yozadi. RDB — vaqti-vaqti bilan to'liq snapshot: kanonda 50 000 INCR dan keyin keskin o'chirishda kalit umuman yo'qoldi (oxirgi snapshot'dan keyingi hamma narsa). AOF — har yozuv jurnalga: o'sha sinovda 50 000 / 50 000 saqlandi. appendfsync everysec sekundiga ~9 300 yozuv, always — ~115. Xotira to'lsa maxmemory-policy hal qiladi: kesh uchun allkeys-lru (eskisi chiqariladi), navbat (BullMQ) uchun noeviction (yozuv OOM bilan rad etiladi, ma'lumot jim yo'qolmaydi).

Bu darsda

• RDB va AOF farqini va har biri qancha ma'lumot yo'qotishi mumkinligini tushuntirasiz.
• appendfsync sozlamasining tezlik va xavfsizlikka ta'sirini bilasiz.
• maxmemory va eviction siyosatini Redis'ning vazifasiga qarab tanlaysiz.
• INFO memory, --bigkeys bilan xotirani kuzatasiz.
• Replication, Sentinel, Cluster, managed Redis va Valkey haqida tasavvur olasiz.

Oldin bilishingiz kerak: Caching naqshlari va invalidatsiya, Redis nima va ulanish, Backup va restore.

Oldingi darsda qulf va limitlarni qurdik. Redis bo'limining oxirgi savoli: Redis o'chib-yonsa nima qoladi va xotira tugasa nima bo'ladi? Kanon buni vaqtinchalik konteynerlarda keskin o'chirish (SIGKILL) bilan o'lchadi (Redis 8.10.2).

1. Nega bu kerak?

Kesh Redis'da edi. Server qayta ishga tushdi — kesh bo'sh. Zarar yo'q: ma'lumot Postgres'da, kesh asta to'ladi.

Endi boshqa holat: Redis'da BullMQ navbati — 2 000 ta "email yuborish" ishi. Redis qayta ishga tushdi va ishlarning yarmi yo'qoldi. Foydalanuvchilar parolni tiklash xatini olmadi. Yoki: xotira to'ldi va Redis "eski" deb hisoblagan navbat elementlarini jimgina o'chirdi.

Bir xil Redis — ikki xil talab. Kesh yo'qotishga chidaydi, navbat va sessiya — yo'q. Sozlamalar vazifaga qarab tanlanadi.

2. RDB — snapshot

RDB (Redis Database file) — xotiradagi hamma ma'lumotning vaqti-vaqti bilan olinadigan to'liq nusxasi — snapshot (dump.rdb). Atama MVCC: Postgres ichida versiyalar darsidagi snapshot bilan bir xil: ma'lum lahzadagi holat. save 60 1000 — "60 soniyada kamida 1 000 o'zgarish bo'lsa, snapshot ol".

Kanon AOF'ni o'chirib, faqat RDB bilan sinadi: 50 000 INCR, so'ng darhol SIGKILL (elektr o'chgandek keskin to'xtatish). Blokda ikki GET hisob bor: birinchisi o'chirishdan oldin, ikkinchisi qayta ishga tushgandan keyin:

$ [kanon27-redis-rdb] redis-cli GET hisob
50000
rdb_changes_since_last_save:50000
rdb_last_save_time:1792909712
aof_enabled:0
$ [kanon27-redis-rdb] redis-cli GET hisob

O'chirishdan oldin hisob = 50 000, rdb_changes_since_last_save:50000 — oxirgi snapshot'dan keyin 50 000 o'zgarish diskda yo'q. Qayta ishga tushgandan keyin GET hisob — bo'sh. Kalit umuman yo'q: snapshot hali olinmagan edi (60 soniya o'tmagan).

RDB'ning yaxshi tomonlari: fayl ixcham (kanonda dump.rdb 89 bayt), qayta ishga tushish tez, zaxira nusxa sifatida ko'chirish qulay. Snapshot fonda olinadi: Redis o'zidan nusxa jarayon (fork) yaratadi, u diskka yozadi, asosiy jarayon ishlashda davom etadi (BGSAVE — Background saving started). Kamchiligi: oxirgi snapshot'dan keyingi hamma narsa xavf ostida — bir necha daqiqa ma'lumot.

3. AOF — har yozuv jurnali

AOF (Append Only File) — har o'zgartiruvchi buyruq jurnal fayliga yoziladi. Qayta ishga tushganda Redis jurnalni boshidan bajarib, holatni tiklaydi. Postgres'dagi WAL g'oyasiga yaqin (Postgres arxitekturasi).

$ [kanon27-redis-aof] redis-cli GET hisob
50000
$ [kanon27-redis-aof] redis-cli GET hisob
50000

Xuddi shu sinov, AOF yoqiq (appendfsync everysec): SIGKILL dan oldin ham, keyin ham 50 000. Bu sinovda yo'qotish 0.

3.1 appendfsync

Yozuv jurnalga qo'shilishi bilan diskka yetib borishi boshqa narsa. Operatsion tizim faylni avval xotirada ushlab turadi; fsync — "hozir diskka yoz" buyrug'i. Redis uchta rejim beradi:

Kanondagi SIGKILL faqat Redis jarayonini o'ldirdi — operatsion tizim tirik qoldi va xotirasidagi faylni diskka yozib ulgurdi. Butun server (elektr) o'chganda everysec 1 soniyagacha yozuvni yo'qotishi mumkin. Buni kanon sinamagan — hujjat bo'yicha.

Tezlik farqi (redis-benchmark, 10 000 INCR):

always — 80 baravar sekin: har yozuv diskni kutadi (kanonda o'rtacha 8.6 ms). Shuning uchun deyarli hamma joyda everysec.

3.2 Jurnalni qayta yozish

AOF har yozuvni saqlaydi — 50 000 INCR jurnalda 50 000 qator, holat esa bitta son.

1.3M	/data/appendonlydir
$ [kanon27-redis-aof] redis-cli BGREWRITEAOF
Background append only file rewriting started
12K	/data/appendonlydir

BGREWRITEAOF — jurnalni joriy holatdan qayta yozish (fonda): 1.3 MB → 12 KB. Redis buni o'zi ham avtomatik qiladi (fayl ma'lum foizga o'sganda). Redis 7 dan AOF — papka: asosiy fayl (RDB formatida) + qo'shimcha jurnal + manifest.

3.3 Qaysi birini tanlash

• Kesh — RDB yetarli yoki umuman diskka yozmaslik (--save "" --appendonly no): yo'qolsa — Postgres'dan qayta to'ladi.
• Navbat, sessiya — AOF everysec + RDB (zaxira nusxa uchun). Bu kursdagi docker run … --appendonly yes --save 60 1000 aynan shu (Redis nima va ulanish).
• Pul va asosiy ma'lumot — Redis emas, Postgres. AOF ham "1 soniyagacha" yo'qotishi mumkin.

Tekshirib ko'ring: Kesh Redis'iga appendfsync always qo'ysak nima yutamiz va nima yo'qotamiz?

4. Xotira to'lganda: maxmemory va eviction

4.1 Sozlamalar

• maxmemory — Redis ishlatadigan eng ko'p xotira. Sukut — 0 (chegara yo'q): Redis kompyuterning hamma xotirasini olib, operatsion tizim uni o'ldirishi mumkin (Caching naqshlari da maxmemory_human:0B ni ko'rdik).
• maxmemory-policy — chegaraga yetganda nima qilish. Asosiylari:

Eviction (chiqarib tashlash) — joy ochish uchun kalitlarni o'chirish. LRU (Least Recently Used — eng uzoq ishlatilmagan) — Memoization darsidagi LRU kesh g'oyasi. Redis aniq LRU emas, taxminiy ishlaydi: bir nechta tasodifiy kalitni olib, ularning eng eskisini o'chiradi (maxmemory-samples).

4.2 allkeys-lru: kesh

Kanon maxmemory 5mb bilan 100 000 kalit yozdi. Chiqishda kalitlar soniga (DBSIZE), chiqarilganlarga (evicted_keys) va eng birinchi hamda eng oxirgi kalitga qarang:

$ [kanon27-redis-mem] redis-cli DBSIZE
46016
evicted_keys:54662
used_memory_human:5.00M
maxmemory_human:5.00M
maxmemory_policy:allkeys-lru
mem_fragmentation_ratio:5.47
$ [kanon27-redis-mem] redis-cli GET kesh:1

$ [kanon27-redis-mem] redis-cli GET kesh:100000
qiymat-100000-uzunroq-matn-bilan

• 100 000 dan 46 016 kalit qoldi, evicted_keys — 54 662 ta chiqarish. Bu son 100 000 − 46 016 dan biroz ko'p; kanon farq sababini tekshirmagan, muhimi — tartib.
• Eng birinchi kesh:1 — yo'q, oxirgi kesh:100000 — bor. Eski kalitlar joy bo'shatdi.
• Hech qanday xato yo'q: yozuvlar o'tdi, eskilari jim ketdi. Kesh uchun aynan shu kerak.

mem_fragmentation_ratio:5.47 — operatsion tizim Redis'ga bergan xotira Redis'ning o'zi hisoblaganidan 5.47 baravar ko'p. Ko'p kalit o'chirilganda xotira "teshikli" bo'lib qoladi. 1.0–1.5 — normal; bu yerda kichik maxmemory va kuchli eviction sababli katta. Redis 4 dan buni tuzatadigan activedefrag sozlamasi bor.

4.3 noeviction: navbat

$ [kanon27-redis-mem] redis-cli CONFIG SET maxmemory-policy noeviction
OK
$ [kanon27-redis-mem] redis-cli SET yangi qiymat
OOM command not allowed when used memory > 'maxmemory'.

$ [kanon27-redis-mem] redis-cli GET kesh:99999
qiymat-99999-uzunroq-matn-bilan

noeviction bilan yozuv rad etildi: "OOM — xotira maxmemory dan oshganda buyruqqa ruxsat yo'q". O'qish ishlayveradi. Ilova xatoni ko'radi va log/alert chiqaradi — ma'lumot jim yo'qolmaydi.

BullMQ hujjati aynan shuni talab qiladi: navbat Redis'ida maxmemory-policy noeviction. allkeys-lru bilan Redis navbatdagi ishni "eski kalit" deb o'chirib yuborishi mumkin — ish bajarilmay yo'qoladi va hech kim bilmaydi. Shuning uchun kesh va navbat uchun ko'pincha alohida Redis instansi ishlatiladi.

5. Kuzatish: INFO, --bigkeys, SLOWLOG

[00.00%] Biggest list   found so far "t61:katta-royxat" with 20000 items
[00.00%] Biggest string found so far "t61:kichik:467" with 1 bytes
Biggest   list found "t61:katta-royxat" has 20000 items
Biggest string found "t61:kichik:467" has 1 bytes
$ [kanon27-redis] redis-cli MEMORY USAGE t61:katta-royxat
290669
used_memory_human:3.73M
maxmemory_policy:noeviction

• redis-cli --bigkeys — har turdagi eng katta kalitni topadi (ichida SCAN — serverni bloklamaydi). Bu yerda 20 000 elementli ro'yxat.
• MEMORY USAGE — kalit egallagan baytlar: 290 669 (≈ 284 KB). Bitta katta kalit — bitta oqimni uzoq band qiladigan potensial muammo: uni o'chirish yoki to'liq o'qish (LRANGE 0 -1) sekin.
• INFO memory — used_memory_human, maxmemory_policy, fragmentatsiya. INFO persistence — rdb_changes_since_last_save, aof_enabled, oxirgi saqlash holati.
• SLOWLOG GET — sekin buyruqlar (String, TTL va kalit nomlash da KEYS 42.9 ms).

Production uchun qo'shimcha xavfsizlik (hujjat): parol yoki ACL foydalanuvchilari (requirepass, ACL SETUSER), xavfli buyruqlarni o'chirish (KEYS, FLUSHALL, CONFIG), port faqat ichki tarmoqda, TLS.

6. Bitta Redis yetmasa

Kanonda bular sinalmagan — hujjat bo'yicha (redis.io, 2026-10-25):

• Replication — asosiy (master) Redis'ning nusxalari (replica). O'qishlarni bo'lish va zaxira uchun. Replikatsiya asinxron: master o'chsa, oxirgi yozuvlar replica'ga yetmagan bo'lishi mumkin.
• Sentinel — master o'chganini aniqlab, replica'lardan birini avtomatik master qiladigan kuzatuvchilar (kamida 3 ta).
• Cluster — ma'lumotni 16 384 ta slot bo'yicha bir nechta master'ga bo'lish (sharding). Bitta serverga sig'maydigan ma'lumot uchun. Cheklov: bir buyruq yoki Lua skriptdagi kalitlar bitta slotda bo'lishi kerak ({vz:1}:a kabi hash tag bilan).
• Managed Redis — AWS ElastiCache, Redis Cloud, Upstash (HTTP orqali, serverless uchun). Server yuritish, zaxira va failover provayderda. Upstash va boshqalarning limitlari va narxlarini ularning hujjatidan tekshiring.

6.1 Valkey: bir xil buyruqlar, modullarsiz

Valkey — Redis 7.2 dan ayrilgan, Linux Foundation boshqaradigan BSD-3 litsenziyali fork (litsenziyalar jadvali — Redis nima va ulanish darsida). Kanon Valkey 8.1.10 da xuddi shu buyruqlarni berdi (chiqishdan tanlangan qatorlar):

$ valkey-cli INFO server
redis_version:7.2.4
server_name:valkey
valkey_version:8.1.10
$ valkey-cli SET vz:a 1 EX 60
OK
$ valkey-cli INCR vz:a
2
$ valkey-cli JSON.SET vz:j $ {"a":1}
ERR unknown command 'JSON.SET', with args beginning with: 'vz:j' '$' '{a:1}' 

$ valkey-cli BF.ADD vz:b x
ERR unknown command 'BF.ADD', with args beginning with: 'vz:b' 'x' 

$ valkey-cli VADD vz:v VALUES 2 0.1 0.2 e1
ERR unknown command 'VADD', with args beginning with: 'vz:v' 'VALUES' '2' '0.1' '0.2' 'e1' 

Asosiy turlar (String, TTL, Sorted Set, Streams) — bir xil. redis_version:7.2.4 — Valkey moslik uchun o'zini Redis 7.2.4 deb ko'rsatadi (shu versiyadan ayrilgan). Redis 8 modullari (JSON, Bloom, vector set) yo'q — ERR unknown command. Kursdagi vazifalar-api keshi faqat GET, SET, INCR ishlatadi — Valkey bilan ham ishlaydi. Ba'zi bulut provayderlari endi Redis o'rniga Valkey taklif qiladi.

7. Ko'p uchraydigan xatolar

8. Mashqlar

Mashqlar kurs/mashqlar/27/61-persistence/ da.

1-mashq (oson): sozlamani tanlang

• Faqat kesh, yo'qolsa muammo yo'q: maxmemory-policy —
• BullMQ navbati: maxmemory-policy —
• Sessiyalar uchun persistence —
• Tezlik va xavfsizlik muvozanati: appendfsync —
• Har turdagi eng katta kalitni topish: redis-cli

2-mashq (o'rta): LRU eviction

LruKesh klassini Map bilan yozing (Redis'ning allkeys-lru siyosatini soddalashtirib): set(k, v) — sig'imdan oshsa eng uzoq ishlatilmagan kalitni chiqarib tashlaydi va evicted hisoblagichini oshiradi; get(k) — kalitni "yangi ishlatilgan" qiladi. Sig'im 4: kesh:1 … kesh:6 ni yozing, lekin kesh:3 yozilgach kesh:1 ni bir marta o'qing. Qaysi kalitlar qoldi va nechta chiqarildi?

class LruKesh {
  #m = new Map();
  evicted = 0;
  constructor(sigim) {
    this.sigim = sigim;
  }
  get(k) {
    if (!this.#m.has(k)) return null;
    const v = this.#m.get(k);
    this.#m.delete(k); // oxiriga ko'chiramiz — "yangi"
    this.#m.set(k, v);
    return v;
  }
  set(k, v) {
    this.#m.delete(k);
    this.#m.set(k, v);
    if (this.#m.size > this.sigim) {
      const eng_eski = this.#m.keys().next().value;
      this.#m.delete(eng_eski);
      this.evicted++;
    }
  }
  kalitlar() {
    return [...this.#m.keys()];
  }
}

const k = new LruKesh(4);
for (let i = 1; i <= 6; i++) {
  k.set(`kesh:${i}`, `qiymat-${i}`);
  if (i === 3) k.get("kesh:1");
}
console.log(k.kalitlar(), "evicted:", k.evicted);

[ 'kesh:1', 'kesh:4', 'kesh:5', 'kesh:6' ] evicted: 2

3-mashq (qiyin): xotira tekshiruvchisi

xotiraniTekshir(info, rol) funksiyasini yozing. info — INFO memory matni (kalit:qiymat qatorlari), rol — "kesh" yoki "navbat". Ogohlantirishlar massivini qaytarsin: maxmemory_human 0B bo'lsa — "chegara yo'q"; rol navbat va siyosat noeviction emas — "navbat jim yo'qolishi mumkin"; rol kesh va siyosat noeviction — "kesh to'lsa yozuvlar rad etiladi"; mem_fragmentation_ratio > 1.5 — "fragmentatsiya X". Kanon qiymatlari bilan sinang: kesh darsidagi Redis (4.23M, 0B, noeviction, fragmentatsiya yo'q) kesh sifatida va shu darsdagi maxmemory tajribasi (5.00M, 5.00M, allkeys-lru, 5.47) navbat sifatida.

function xotiraniTekshir(info, rol) {
  const q = Object.fromEntries(
    info.split("\n").filter((s) => s.includes(":"))
      .map((s) => s.split(":")),
  );
  const ogoh = [];
  if (q.maxmemory_human === "0B") ogoh.push("chegara yo'q");
  const siyosat = q.maxmemory_policy;
  if (rol === "navbat" && siyosat !== "noeviction") {
    ogoh.push("navbat jim yo'qolishi mumkin");
  }
  if (rol === "kesh" && siyosat === "noeviction") {
    ogoh.push("kesh to'lsa yozuvlar rad etiladi");
  }
  const frag = Number(q.mem_fragmentation_ratio ?? 1);
  if (frag > 1.5) ogoh.push(`fragmentatsiya ${frag}`);
  return ogoh;
}

const keshRedis = [
  "used_memory_human:4.23M",
  "maxmemory_human:0B",
  "maxmemory_policy:noeviction",
].join("\n");
const tajribaRedis = [
  "used_memory_human:5.00M",
  "maxmemory_human:5.00M",
  "maxmemory_policy:allkeys-lru",
  "mem_fragmentation_ratio:5.47",
].join("\n");
console.log(xotiraniTekshir(keshRedis, "kesh"));
console.log(xotiraniTekshir(tajribaRedis, "navbat"));

[ "chegara yo'q", "kesh to'lsa yozuvlar rad etiladi" ]
[ "navbat jim yo'qolishi mumkin", 'fragmentatsiya 5.47' ]

9. Loyiha qadami: kanon tajribasi, loyihaga kirmaydi

vazifalar-api kodi bu darsda o'zgarmaydi. Kesh uchun persistence muhim emas: Redis bo'sh qaytsa, KeshliOmbor bazadan to'ldiradi. Lekin bir kanon topilmasini eslang (Caching naqshlari): Redis saqlanib, baza qayta qurilsa, eski avlod raqami va kesh qoladi — teskari holat ham xavfli. Production'da (33-qism, Docker Compose) kesh Redis'iga maxmemory va allkeys-lru qo'yamiz; 29-qismdagi BullMQ uchun — alohida noeviction instans. O'zingiz sinab ko'ring: o'z konteyneringizda CONFIG GET maxmemory-policy va INFO persistence ni o'qing.

10. Real ishda

• DevOps — Redis sozlamasini vazifaga qarab tanlash (kesh / navbat / sessiya), maxmemory va alert'lar.
• Hodisalar — "Redis qayta ishga tushdi — sessiyalar yo'qoldi, hamma tizimdan chiqdi" klassik voqea; sababi — persistence o'chiq.
• Bulut — ElastiCache yoki Valkey asosidagi xizmatlar; Upstash — serverless (Vercel) loyihalarda.
• Intervyuda: "RDB va AOF farqi?", "Redis'da ma'lumot yo'qolishi mumkinmi?", "maxmemory-policy qaysilari bor va BullMQ uchun qaysi?", "Redis Cluster qanday bo'ladi?"

Xulosa

• RDB — snapshot: keskin o'chishda oxirgi snapshot'dan keyingisi yo'qoladi (kanon: 50 000 → kalit yo'q).
• AOF — jurnal: everysec kanonda 50 000 / 50 000; always 80 baravar sekin (115 vs 9 275 so'rov/s).
• maxmemory qo'ying; kesh — allkeys-lru (eski jim chiqadi), navbat — noeviction (OOM xatosi).
• INFO memory, --bigkeys, MEMORY USAGE, SLOWLOG — kuzatish vositalari.
• Replication, Sentinel, Cluster, managed Redis — kattaroq tizimlar uchun; Valkey — bir xil asosiy buyruqlar, modullarsiz.

Keyingi dars: Test DB strategiyalari — integration testlar haqiqiy bazada, lekin bir-biriga xalaqit bermasdan: alohida baza, ROLLBACK, TRUNCATE va template baza.

Manbalar

• Redis hujjati — Persistence (RDB, AOF, appendfsync): https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/
• Eviction siyosatlari va taxminiy LRU: https://redis.io/docs/latest/develop/reference/eviction/
• Replication, Sentinel, Cluster: https://redis.io/docs/latest/operate/oss_and_stack/management/replication/, https://redis.io/docs/latest/operate/oss_and_stack/management/sentinel/, https://redis.io/docs/latest/operate/oss_and_stack/management/scaling/
• BullMQ — maxmemory-policy noeviction talabi: https://docs.bullmq.io/guide/going-to-production
• Valkey: https://valkey.io/
• Chiqishlar — kanon o'lchovi (IlmHamroh, 2026-10): Redis 8.10.2, Valkey 8.1.10, vaqtinchalik konteynerlar.