Redis և caching

01Ինչ է իրականում Redis-ը

Պատկերացրեք Redis-ը որպես RAM-ում ապրող հսկա ընդհանուր բառարան։ Հիշողությունից կարդալը միկրովայրկյաններ է տևում, իսկ տիպիկ database query-ն՝ միլիվայրկյաններ, ուստի պարզ որոնումների համար Redis-ը հաճախ 100 անգամ ավելի արագ է։ Բայց Redis-ը key → string-ից ավելին է։ Այն առաջարկում է տվյալների կառուցվածքներ՝ string-ներ (և counter-ներ), hash-եր (դաշտերով օբյեկտ), list-եր (queue-ներ), set-եր (եզակի անդամներ), sorted set-եր (leaderboard-ներ, ժամանակով դասավորված տարրեր), stream-ներ (append-only log՝ consumer group-երով), ինչպես նաև bitmap-ներ, HyperLogLog և geo ինդեքսներ։ Յուրաքանչյուր հրաման ատոմար կատարվում է մեկ հիմնական thread-ի վրա, ահա թե ինչու counter-ի վրա INCR-ն անվտանգ է նույնիսկ շատ client-ների դեպքում։ Լիցենզիայի մասին՝ 2026-ի դրությամբ Redis 8-ը հասանելի է AGPLv3-ով (իր source-available լիցենզիաների կողքին), իսկ Valkey-ն BSD լիցենզիայով, Linux Foundation-ի fork է, որը cloud-երի մեծ մասն առաջարկում է որպես drop-in փոխարինող։

• String՝ cache-ավորված JSON, counter-ներ, դրոշակներ
• Hash՝ օգտատիրոջ session կամ կարգավորումների օբյեկտ
• List / Stream՝ job queue-ներ և event log-եր
• Sorted set՝ վարկանիշներ, պլանավորված տարրեր, sliding-window rate limit-ներ

1SET product:42 '{"name":"Latte","price":1500}' EX 300
2GET product:42
3INCR rate:203.0.113.10:2026-11-05T10:01
4HSET session:abc user_id 7 role cashier
5EXPIRE session:abc 1800
6ZADD leaderboard 980 player:1 1200 player:2
7ZREVRANGE leaderboard 0 9 WITHSCORES
8TTL product:42

02Caching pattern-ներ՝ cache-aside, write-through, write-behind

Cache-aside-ը (lazy loading) default-ն է․ հավելվածը նախ հարցնում է Redis-ին, miss-ի դեպքում կարդում է տվյալների բազան, պահում արդյունքը TTL-ով և վերադարձնում այն։ Cache է արվում միայն այն տվյալը, որն իրականում հարցվում է, և եթե Redis-ը ընկնի, հավելվածը դեռ աշխատում է, պարզապես ավելի դանդաղ։ Write-through-ը նշանակում է, որ յուրաքանչյուր գրառում միաժամանակ գնում է տվյալների բազա և cache, այնպես որ ընթերցումները միշտ «տաք» են․ լավ է փոքր, շատ կարդացվող տվյալների համար, ինչպիսիք են կարգավորումները։ Write-behind-ը նախ գրում է cache-ում և ավելի ուշ flush անում տվյալների բազա․ արագ է, բայց կարող է տվյալներ կորցնել, ուստի ես խուսափում եմ դրանից ցանկացած ֆինանսական բանի համար։ Ինչ pattern էլ լինի, տվյալների բազան մնում է ճշմարտության աղբյուրը։ Cache-ը պատճեն է, և դուք պետք է կարողանաք ջնջել այն ամբողջությամբ՝ առանց որևէ բան կորցնելու։

1async function getMenu(branchId: string) {
2  const key = `menu:v3:${branchId}`;
3  const hit = await redis.get(key);
4  if (hit) return JSON.parse(hit);
5 
6  const menu = await db.menu.findForBranch(branchId);
7  // TTL with jitter so many keys do not expire at the same moment
8  const ttl = 600 + Math.floor(Math.random() * 60);
9  await redis.set(key, JSON.stringify(menu), "EX", ttl);
10  return menu;
11}
12 
13async function updateMenu(branchId: string, data: MenuInput) {
14  await db.menu.update(branchId, data);
15  await redis.del(`menu:v3:${branchId}`); // invalidate after the write commits
16}

03TTL, invalidation և cache stampede

Cache-ավորված տվյալը երկու ձևով է անհետանում՝ այն սպառվում է (TTL) կամ դուք այն դիտմամբ ջնջում եք (invalidation)։ Օգտագործեք երկուսն էլ՝ invalidate արեք այն գրառումների ժամանակ, որոնք դուք եք վերահսկում, և TTL պահեք որպես անվտանգության ցանց այն գրառումների համար, որոնք մոռացել եք։ Key-երի անուններում դրեք տարբերակ (menu:v3:…), որպեսզի տվյալների ձևի փոփոխությունը երբեք հին blob-եր չկարդա։ Ջնջեք տվյալների բազայի transaction-ի commit-ից հետո, ոչ թե առաջ, այլապես զուգահեռ ընթերցողը կարող է cache-ը նորից լցնել հնացած տվյալներով։ Cache stampede-ը (thundering herd) տեղի է ունենում, երբ hot key-ը սպառվում է, և հարյուրավոր հարցումներ միաժամանակ miss են անում ու բոլորը դիպչում տվյալների բազային։ Լուծումներ՝ TTL-ներին ավելացրեք պատահական jitter, թույլ տվեք միայն մեկ հարցման վերակառուցել արժեքը՝ կարճ lock-ով (SET key NX EX), մատուցեք հնացած արժեքը, մինչ մեկ worker-ը թարմացնում է այն, կամ հայտնի key-երը թարմացրեք background-ում՝ մինչև սպառվելը։

1// One rebuilder per key; others wait briefly or serve stale data
2const lock = await redis.set(`lock:${key}`, "1", "NX", "EX", 10);
3if (lock === "OK") {
4  try {
5    const fresh = await loadFromDb();
6    await redis.set(key, JSON.stringify(fresh), "EX", 600);
7  } finally {
8    await redis.del(`lock:${key}`);
9  }
10}

04Session-ներ, rate limiting և lock-եր

Redis-ը բնական տուն է կարճաժամկետ ընդհանուր վիճակի համար։ Session-ներ՝ session-ը պահեք hash-ում TTL-ով, որպեսզի հավելվածի ցանկացած սերվեր կարողանա կարդալ այն, իսկ logout-ը լինի մեկ DEL։ Rate limiting՝ fixed window-ը INCR է rate:{ip}:{minute}-ի նման key-ի վրա EXPIRE-ով․ պարզ է, բայց թույլ է տալիս burst-եր պատուհանների եզրերին։ Sliding window-ն օգտագործում է timestamp-ների sorted set կամ token bucket փոքր Lua script-ում՝ ավելի հարթ սահմանափակումների համար։ Նույն գաղափարն օգտագործեք OTP փորձերը և login-ի ձախողումները սահմանափակելու համար՝ ըստ հեռախոսի կամ հաշվի, ոչ միայն ըստ IP-ի։ Lock-եր՝ SET lock:order:42 token NX EX 30-ը մեկ worker-ին տալիս է բացառիկ աշխատանք 30 վայրկյանով․ ազատեք այն միայն այն դեպքում, եթե token-ը դեռ համընկնում է, այլապես կարող եք ջնջել ուրիշի lock-ը։ Իրական գումարի համար database constraint-ը կամ idempotency key-ը դեռ վերջնական պաշտպանությունն է։

1-- Fixed-window limit: 100 requests per 60 s, atomic in one call
2-- KEYS[1] = rate key, ARGV[1] = limit, ARGV[2] = window seconds
3local n = redis.call("INCR", KEYS[1])
4if n == 1 then
5  redis.call("EXPIRE", KEYS[1], ARGV[2])
6end
7if n > tonumber(ARGV[1]) then
8  return 0
9end
10return 1

05Queue-ներ և pub/sub

List-երն ու stream-երը Redis-ը դարձնում են ընդունակ job broker։ BullMQ (Node) և Laravel queues (PHP) գրադարանները job-երը պահում են Redis-ում և տալիս են retry-ներ backoff-ով, ուշացումներ, առաջնահերթություններ և dead-letter մշակում։ Վեբ հարցումը մնում է արագ, որովհետև email ուղարկելը կամ ERP-ի հետ sync անելը տեղի է ունենում worker-ում։ Pub/sub-ն այլ է․ հաղորդագրությունը broadcast է արվում բոլոր նրանց, ովքեր հենց այս պահին subscribe են արած, և չի պահվում։ Այն կատարյալ է real-time event-ների fan-out-ի համար մի քանի WebSocket սերվերների միջև (socket.io-ի Redis adapter-ը հենց դա է անում), բայց եթե ոչ ոք չի լսում, հաղորդագրությունը կորչում է։ Երբ ձեզ պետք են առաքման երաշխիքներ կամ replay, օգտագործեք Streams՝ consumer group-երով, կամ իսկական queue։ Պարզ կանոն՝ pub/sub՝ «հիմա ասա բոլորին», queue-ներ՝ «համոզվիր, որ սա կկատարվի»։

06Persistence, հիշողություն և eviction

Redis-ը տվյալները պահում է RAM-ում, բայց կարող է դրանք պահպանել դիսկի վրա։ RDB-ն պարբերական snapshot-ներ է գրում՝ կոմպակտ և արագ վերականգնվող, բայց կորցնում եք վերջին snapshot-ից հետո կատարված գրառումները։ AOF-ը (append-only file) log է անում յուրաքանչյուր գրառում․ appendfsync everysec-ով կորցնում եք առավելագույնը մոտ մեկ վայրկյան։ Շատ setup-ներ օգտագործում են երկուսն էլ։ Մաքուր cache-ի համար persistence-ը կարող է անջատված լինել։ Queue-ների և session-ների համար միացրեք AOF-ը։ Միշտ սահմանեք maxmemory և eviction policy՝ allkeys-lru կամ allkeys-lfu cache-ի համար, noeviction՝ queue-ի համար (ուզում եք սխալներ, ոչ թե լուռ ջնջված job-եր)։ Իդեալում cache-ը և queue-ն պահեք առանձին instance-ներում կամ տվյալների բազաներում՝ տարբեր policy-ներով։ Երբեք 6379 port-ը մի բացեք ինտերնետին․ bind արեք localhost-ին կամ private ցանցին, պահանջեք գաղտնաբառ կամ ACL օգտատերեր և ցանցերի միջև օգտագործեք TLS։

1# /etc/redis/redis.conf (cache + small queue on a private host)
2bind 127.0.0.1
3protected-mode yes
4requirepass change_me_long_random
5maxmemory 1gb
6maxmemory-policy allkeys-lfu
7appendonly yes
8appendfsync everysec
9save 900 1

07Երբ չպետք է cache անել

Caching-ը ճշմարտության երկրորդ պատճեն է ավելացնում, և յուրաքանչյուր պատճեն կարող է սխալ լինել։ Մի cache արեք նախքան չափելը․ հաճախ ինդեքսը կամ ուղղված N+1 query-ն լուծում է խնդիրը՝ առանց նոր շարժվող մասերի։ Խուսափեք այն տվյալների cache-ից, որոնք պետք է ճշգրիտ լինեն կարդալու պահին՝ մնացորդը checkout-ում, wallet-ի մնացորդները, վճարման կարգավիճակը, կամ cache արեք դրանք միայն ցուցադրման համար և transaction-ի ներսում նորից ստուգեք տվյալների բազայից։ Մի cache արեք օգտատիրոջ անձնական պատասխանները ընդհանուր key-ի տակ (մի հաճախորդի տվյալների դասական արտահոսք մյուսին)։ Զգույշ եղեք այն բաների cache-ի հետ, որոնք փոխվում են գրեթե յուրաքանչյուր հարցման ժամանակ․ hit rate-ը մոտ կլինի զրոյի, իսկ գրառումների համար դուք վճարում եք։ Վերջապես, եթե տվյալների ծավալը փոքր է, և տվյալների բազան պարապ է, in-process memory cache-ը կամ HTTP caching header-ները կարող են լինել այն ամենը, ինչ ձեզ պետք է։

08Մեկ thread․ ինչու է մեկ դանդաղ հրամանը վնասում բոլորին

Redis-ը հրամանները կատարում է հերթով՝ իր main thread-ում։ Redis 6-ից սկսած՝ ըստ ցանկության միացվող I/O thread-երը (io-threads) զուգահեռ կարդում և գրում են network socket-ները, բայց հրամաններն իրենք դեռ կատարվում են հաջորդաբար։ Այդ դիզայնի շնորհիվ է յուրաքանչյուր հրաման ատոմար, և հենց դրա պատճառով էլ մեկ O(N) հրամանը կանգնեցնում է մնացած բոլոր client-ներին։ KEYS *-ը տասը միլիոն key-ի վրա, SMEMBERS-ը հսկայական set-ի վրա, LRANGE 0 -1-ը երկար list-ի վրա կամ DEL-ը մեծ hash-ի վրա կարող են արգելափակել հարյուրավոր միլիվայրկյաններ, իսկ հավելվածի համար դա նման է Redis-ի outage-ի։ Անցեք key-երի վրայով SCAN-ով, HSCAN-ով և SSCAN-ով՝ փոքր batch-երով։ Մեծ key-երը ջնջեք UNLINK-ով, որը հիշողությունն ազատում է background thread-ում։ Գտեք խնդրահարույց հրամանները նախքան դրանք կվնասեն․ SLOWLOG-ը գրանցում է շեմից դանդաղ հրամանները, LATENCY DOCTOR-ը բացատրում է spike-երը, իսկ redis-cli --bigkeys-ը և --memkeys-ը նմուշառում են keyspace-ը՝ առանց այն արգելափակելու։

1# Find big keys and memory hogs (samples with SCAN, safe in production)
2redis-cli --bigkeys
3redis-cli --memkeys
4 
5# Commands slower than slowlog-log-slower-than (microseconds)
6redis-cli SLOWLOG GET 10
7redis-cli LATENCY DOCTOR
8 
9# Memory health and cache efficiency
10redis-cli INFO memory | grep -E 'used_memory_human|mem_fragmentation_ratio'
11redis-cli INFO stats  | grep -E 'keyspace_hits|keyspace_misses|evicted_keys'
12 
13# Remove one big key without blocking the main thread
14redis-cli UNLINK report:2026:full

09Replication, Sentinel և Cluster

Replica-ն primary-ն պատճենում է ասինխրոն՝ primary-ն նախ պատասխանում է client-ին, իսկ գրառումն ուղարկում է հետո։ Եթե primary-ն մահանում է գրառումը հաստատելուց անմիջապես հետո, failover-ը կարող է առաջ քաշել մի replica, որը երբեք չի տեսել այդ գրառումը։ WAIT հրամանն արգելափակում է, մինչև N replica-ներ հաստատեն, ինչը նեղացնում է այդ պատուհանը, բայց Redis-ը չի դարձնում strongly consistent տվյալների բազա։ Sentinel-ը հետևում է primary-ին և նրա replica-ներին, քվեարկում է խափանման մասին և առաջ է քաշում replica-ն․ client-ները Sentinel-ին են հարցնում, թե որտեղ է ընթացիկ primary-ն։ Cluster-ը լուծում է այլ խնդիր՝ մեկ մեքենայից մեծ տվյալներ՝ keyspace-ը բաժանելով 16,384 hash slot-ի, որոնք բաշխված են մի քանի primary-ների վրա։ Multi-key հրամանները, transaction-ները և Lua script-երն աշխատում են միայն այն դեպքում, երբ բոլոր key-երը hash են լինում նույն slot-ում, հակառակ դեպքում ստանում եք CROSSSLOT սխալ։ Hash tag-երը լուծում են դա․ hash է արվում միայն {ձևավոր փակագծերի} ներսի մասը, ուստի կապված key-երը հայտնվում են միասին։

1# Only "user:42" inside the braces is hashed -> same slot
2SET {user:42}:profile '{"name":"Ana"}'
3SET {user:42}:cart '{"items":3}'
4MGET {user:42}:profile {user:42}:cart
5 
6CLUSTER KEYSLOT {user:42}:cart
7# Without a shared hash tag, MGET across slots returns CROSSSLOT

10Race condition, որն ունի ամեն cache-aside համակարգ

Cache-aside-ն ունի դասական race։ A ընթերցողը miss է ստանում cache-ում և կարդում է հին տողը։ B գրողը թարմացնում է տողը և ջնջում key-ը։ A ընթերցողը, մի փոքր ուշացած, հիմա հին արժեքը հետ է գրում cache, որտեղ այն մնում է մինչև TTL-ի ավարտը։ Commit-ից հետո ջնջելը պատուհանը փոքրացնում է, բայց զրո չի դարձնում։ Մի քանի պաշտպանություն՝ էժանից ուժեղ․ կարճ պահեք TTL-ները այն տվյալների համար, որտեղ հնացածությունը կարևոր է․ մի պահ անց նորից ջնջեք (delayed double delete) queue-ի job-ից․ cache-ված արժեքի հետ պահեք version կամ updated_at և փոքր Lua script-ով հրաժարվեք ավելի նորը վերագրելուց․ կամ invalidation-ը ղեկավարեք հենց տվյալների բազայից՝ transactional outbox-ով կամ change data capture-ով, որպեսզի ոչ մի code path չկարողանա մոռանալ այն։ Շատ hot ընթերցումների համար Redis-ի client-side caching-ը (CLIENT TRACKING, Redis 6-ից) թույլ է տալիս սերվերին invalidation հաղորդագրություններ ուղարկել հավելվածի մակարդակի near cache-երին։

11Հիշողության ներքին կառուցվածքը․ eviction, encoding-ներ և դաշտային TTL

Eviction-ը մոտավոր է։ Կատարյալ LRU հերթականությանը հետևելու փոխարեն Redis-ը նմուշառում է մի քանի key (maxmemory-samples, default-ով 5) և հեռացնում լավագույն թեկնածուին․ նմուշի չափը մեծացնելը մոտեցնում է իրական LRU-ին՝ որոշակի CPU-ի գնով։ LFU-ն յուրաքանչյուր key-ի համար պահում է փոքր լոգարիթմական հասանելիության հաշվիչ, որը ժամանակի ընթացքում նվազում է, ուստի երեկ հայտնի key-ը ի վերջո դառնում է eviction-ի ենթակա։ Փոքր hash-երը, list-երը, set-երը և sorted set-երը պահվում են կոմպակտ listpack encoding-ներով, և դրա համար էլ շատ փոքր hash-եր հաճախ ավելի քիչ հիշողություն են զբաղեցնում, քան շատ առանձին string key-եր։ Մեկ key-ը ստուգեք MEMORY USAGE-ով և հետևեք mem_fragmentation_ratio-ին․ active defragmentation-ը (activedefrag yes) կարող է online վերադարձնել ֆրագմենտացված հիշողությունը։ Redis 7.4-ից hash-ի դաշտերը կարող են առանձին expire լինել HEXPIRE-ով, ինչը հարմար է session-ների համար, որտեղ OTP դաշտը պետք է անհետանա 60 վայրկյան հետո, իսկ session-ն ինքը շարունակի ապրել։ Key-ի մակարդակի TTL-ը միևնույն է ջնջում է ամբողջ hash-ը՝ անկախ դաշտերի TTL-ներից։