Texnologiya və infrastruktur → Redis: in-memory-solutions

Redis: in-memory-solutions

1) Redis uyğun harada

• Cache (read-through/aside, TTL, SWR) və sessiyalar.
• Sayğaclar və kvotalar: rate limiting, antifrod, kampaniya limitləri.
• Lider bordları/reytinqləri (ZSet), «top-N» tövsiyələri.
• Hadisə növbələri/şinləri (Streams/PubSub), outbox/inbox, retray.
• İdempotentlik (TTL ilə açarlar), de-dup webhook.
• Geo (ən yaxın nöqtələrin axtarışı), Bitmap (bayraqlar, DAU).
• Təxəllüslər/tokenlər və qısa ömürlü avtorizasiya caches.

2) Data strukturları və nə zaman tətbiq

String: dəyərlər/sayğaclar ('INCRBY'), idempotent açarları.
Hash: profil/konfiqurasiya aqreqatları, «yüngül» obyektlərin saxlanması.
List: sadə növbələr (lakin replay/offset-semantika olmadan).
Set: unikal elementlər, deduplikasiya.
ZSet: sürət sıralaması (liderbordlar, TTL təqvimi - «gecikmiş» hadisələr).
Stream: İstehlak qrupları ilə sabit növbələr, 'XREADGROUP '/replay - vebhuk, CDC, retray üçün.
Geo: 'GEOADD/GEORADIUS' - ən yaxın nöqtə/merchant.
Bitmap/Bitfield: Bayraqlar seriyası (günlük loginlər, DAU/WAU).
HyperLogLog: təxmini unikal (UU) yaddaş ucuz.
Bloom/Cuckoo (modullar): sürətli varlıq yoxlamaları, mənbəyə «MISS» azaldır.

• RedisJSON (JSON sənədləri), RediSearch (indeksasiya/axtarış), RedisBloom (ehtimal strukturları), TimeSeries (metrik/aqreqasiya).

3) Açarlar, TTL və yaddaş siyasəti

tenant:{t}:domain:{d}:{entity}:{id}:v{schema}    region={R}    currency={C}    lang={L}

Version ('vN'), yalnız əhəmiyyətli ölçmələri daxil edin (region/valyuta/dil/tenant).
per-tenant açar sahələrini təcrid edin.

• TTL matrisini (san/dəq/saat) istifadə edin, stampede qarşısını almaq üçün jitter (± 10-20%) əlavə edin.
• Qaynar açarlar üçün - refresh-ahead və single-flight (bir lider yeniləyir).

• 'allkeys-lru/lfu' - TTL asılılığı olmayan ümumi cache.
• 'volatile-lru/lfu' - yalnız TTL açarları.
• 'noeviction' - həddindən artıq (kritik növbələr/sayğaclar üçün daha təhlükəsizdir).
• Ssenari üçün seçin və həmişə izləyin 'evicted _ keys'.

4) Əməliyyatlar, paylaynlar və skriptlər

Payplays: RTT-ni azaltın, 10-100 komandanı qruplaşdırın.
Əməliyyatlar (MULTI/EXEC): oxunuşları təcrid etmir, lakin paketi atom şəklində yerinə yetirir.
Optimistic locking: 'WATCH key' → yoxlama → 'MULTI/EXEC'.
Lua skriptləri: server tərəfində atom məntiqi (rate limit, locks, composite-əməliyyatlar).

5) Növbələr və şinlər: List vs Stream

List + 'BRPOP' - sadə, lakin heç bir consumer groups, offset/replay, zəif düşmə müqaviməti.
Stream: 'HADD → XREADGROUP → XACK', retry-deadletter (N dəqiqədə keçilməz), açar partizanı. PSP/KYC vebhukları, gecikmiş ödənişlər/bildirişlər üçün tövsiyə olunur.

Prioritet növbələr: prioritetlər üzrə bir neçə axın, istehlakçılar ilk növbədə yüksəkdən «sorurlar».
Gecikmiş tapşırıqlar: ZSet harada score = timestamp; periodik 'ZRANGEBYSCORE' ≤ now → Stream transfer.

6) Yüksək mövcudluq və miqyas

Replikasiya: master → replica (read-scale).
Sentinel: avtomatik failover master 'a, aşkarlama, müştəri URI.
Redis Cluster: 16384 slot, üfüqi scale-out. Bir neçə strukturdan istifadə edən açarları '{order: 123}' hash etiketlərinə bükün.

• Keş/seanslar üçün - klaster/replikalar, 'client-side hashing' SDK tərəfindən dəstəklənir.
• Növbələr/axınlar üçün - xaç-slot əməliyyatlarını minimuma endirin; domen açarları ilə partiyalaşdırın.

7) Persistentlik: RDB, AOF və backup

RDB (şəkillər): daha sürətli, daha qənaətli; son saniyə/dəqiqə itkisi riski.
AOF (jurnal): daha az itki; 'everysec/always' rejimləri. AOF sıxılması və periodik yenidən qablaşdırma.
Hibrid: RDB + AOF → sürətli bərpa + orta itki.
Backup: obyektin anbarına snapshotlar və AOF nüsxələri; bərpa mütəmadi yoxlayın.

Kritik növbələr/idempotentlik üçün AOF 'everysec' + replikasiyasını seçin.

8) Təhlükəsizlik və uyğunluq

AUTH/ACL: rolları per-app, «təhlükəli» komandaların qadağan ('FLUSHALL', 'KEYS').
TLS müştəri-server və qovşaqlararası linklərdə; sabit egress-IP.
Şəbəkə seqmentasiyası: xüsusi alt şəbəkələr, SG/NACL; Yalnız lazımi xidmətlərdən/neyspaceslərdən çıxış.
Sirləri qeyd etməyin; Redis-də PAN/PII - yalnız tokenlər/törəmələr.
Açar əmrləri: 'KEYS' -dən çəkinin - 'SCAN' istifadə edin.

9) Müşahidə və SLO

• Latency (P95/P99), `instantaneous_ops_per_sec`, `connected_clients`.
• Hit ratio, evicted_keys, expired_keys.
• Memory: used, fragmentation ratio, RSS, allocator stats.
• Replication lag, AOF/RDB tezlik və ölçüləri, fork time.
• Streams: PEL (pending entries list), delivery latency, retry count.

• Redis P99 əməliyyatları ≤ 5-10 ms.
• Evictions ≤ 1 %/saat (Cash Space).
• Stream delivery P99 ≤ 500 мс, retry rate < 2%.

10) FinOps və resursların planlaşdırılması

Yaddaş bahadır: $/GB-ay RAM ölçün vs origin/DB üçün qənaət sorğular.

LFU daha az həcmdə ən yaxşı hit verə bilər.
Şəkillər/böyük bloblar üçün - Redis deyil: CDN + obyekt saxlama istifadə edin.

11) iGaming/Fintech üçün nümunələr

11. 1 Rate limiting (sürüşmə pəncərəsi, Lua)

Fikir: «INCRBY» pəncərə açarında + TTL; Lua atom limiti yoxlayır və artırır.

lua
-- KEYS[1]=key ARGV[1]=limit ARGV[2]=ttlSec ARGV[3]=inc local cur = redis. call('INCRBY', KEYS[1], ARGV[3])
if cur == tonumber(ARGV[3]) then redis. call('EXPIRE', KEYS[1], ARGV[2]) end if cur > tonumber(ARGV[1]) then return {0, cur} else return {1, cur} end

11. 2 Sorğuların idempotentliyi

Açar 'idemp: {request _ id}' ilə TTL 24h, qiymət - nəticə/status. Əməliyyat etməzdən əvvəl - varlığını yoxlayın.

11. 3 Liderbordlar

`ZINCRBY leaderboard:game:{g} score user:{u}` → `ZREVRANGE... WITHSCORES`.
Bölgə/tenant üzrə Top N üçün - ayrı-ayrı ZSet və ya prefikslər.

11. 4 PSP vebhuk növbəsi

'HADD psp: webhooks...' → istehlakçı qrupları 'XGROUP CREATE psp: webhooks g1 $'.
PEL-scan vasitəsilə «asılı» mesajların retraisi ('XPENDING' → 'XCLAIM').

11. 5 Gecikmiş ödənişlər

ZSet 'payout: due' (score = epoch) → worker vaxtaşırı hazır elementləri Stream 'payout: exec' -ə köçürür.

11. 6 Antifrod sayğacları

'PFADD' (unikal) + 'INCR' (intensivlik) + geo/ASN etiketləri; əl yoxlama üçün tetikleyicilər.

12) Yaddaş və performans ilə iş

Müştəri qoşulma hovuzları; RTT (keep-alive) azaldın.
Bir paket komandaya paylayın.
Böyük keys ('MEMORY USAGE', 'SCAN') - obyektləri parçalamaq daha yaxşıdır.
Az sahəli Hash bir çox fərdi açarlardan daha qənaətlidir.
Profit testlərlə təsdiqlənərsə io-threads (read-heavy) daxil edin.
Prod tez-tez 'FLUSHDB/ALL' çəkinin; təhlükəsiz silmək üçün prefikslər və 'UNLINK' vasitəsilə idarə edin.

13) Multi-tenant və izolyasiya

Ayrı-ayrı klasterlər/instants və ya logical DB per-tenant (yük kiçik olduqda).
Açar/yaddaş kvotaları, ayrı ACL.
namespace açarları və metrik prefikslər.

14) Locking və uyğunluq

SET key val NX PX = ttl - sadə mutex.
Redlock: diqqətlə istifadə edin; paylanmış kritik əməliyyatlar üçün «həqiqət mənbəyinə» (BD/ledger) və idempotent əməliyyatlarına güvənmək daha yaxşıdır.
«Uzun» bloklar əvəzinə atom əməliyyatları və Lua üstünlük.

15) Anti-nümunələr

Böyük blobların/şəkillərin saxlanması - RAM və şəbəkələrin həddindən artıq yüklənməsi.
Maliyyə invariantları (balans) yalnız Redis.
'KEYS' və «dünyanı tarama» prodda.
TTL/Jitter olmaması - sona çatdıqda dogpile.
Kritik növbələrdə 'allkeys-' siyasəti → təzyiq zamanı məlumat itkisi.
Kvota və prioritetlər olmadan bir instansiyada növbələrin, keşlərin və sessiyaların qarışdırılması.
Cluster-də müxtəlif slotların açarları ilə işləyən Lua skriptləri.

16) Giriş çek siyahısı

1. Rolları müəyyənləşdirin: keşlər/sessiyalar, növbələr/axınlar, sayğaclar/limitlər - instansiyalar/klasterlər üzrə paylayın.
2. Tapşırıq üçün maxmemory-policy seçin; Limitləri təyin edin və evictions monitorinqi.
3. Neyminq açarları, sxemlərin versiyaları, TTL matrisi + jitter; üst açarları üçün tək uçuş.
4. Növbələr üçün - Streams (qruplar, retralar, DLQ), təxirə salınanlar üçün - ZSet + transfer.
5. HA: + Sentinel və ya Redis Cluster replikasiyası; müştərinin failover yoxlayın.
6. Persistentlik: RDB/AOF ssenari altında; müntəzəm backup və bərpa testi.
7. Təhlükəsizlik: ACL, TLS, xüsusi şəbəkələr, təhlükəli komandaların qadağan edilməsi.
8. Müşahidə müddəti: latency, ops/sec, memory, evictions, replication lag, stream PEL.
9. FinOps: yaddaş profilləri, böyük açarlar, sıxılma, LFU; böyük blobs üçün Redis çəkinin.
10. Nümunələrin sənədləşdirilməsi (rate-limit, idempotentlik, liderbordlar) və yükləmə testləri.

Yekun

Redis «çoxfunksiyalı İsveçrə bıçağı» sürətidir: cache, növbələr, sayğaclar, liderbordlar, geo və ehtimal strukturları. Onun gücü məlumat strukturlarının düzgün seçilməsində, TTL/əlillik intizamında, əməliyyatların atomarlığında, həmçinin düşünülmüş NA/persistentlik və müşahidə edilməsində olur. Kritik invariantları (pul, mühasibat uçotu) «həqiqət mənbəyinə» buraxarkən, millisaniyələrin və yüksək RPS-in vacib olduğu yerlərdə Redis istifadə edin - beləliklə platforma həm sürətli, həm də etibarlı olaraq qalacaq.