Tehnologie și infrastructură → Redis: soluții în memorie

Redis: soluții de memorie

1) În cazul în care Redis este adecvat

• Cache (read-through/deoparte, TTL, SWR) și sesiuni.
• Contoare și cote: limitarea ratei, anti-fraudă, limitele campaniei.
• Clasamente/evaluări (ZSet), „top N” recomandări.
• Cozi de evenimente/autobuze (Streams/PubSub), outbox/inbox, retroys.
• Idempotence (chei cu TTL), de-dup webhooks.
• Geo (caută cele mai apropiate puncte), Bitmap (steaguri, DA).
• Aliasuri/jetoane și cache-uri de autorizare de scurtă durată.

2) Structuri de date și când să le aplice

String: valori/contoare ('INCRBY'), chei idempotente.
Hash: agregate de profile/configurații, stocarea obiectelor „ușoare”.
Listă: cozi simple (dar fără semantică de reluare/offset).
Set: elemente unice, deduplicare.
ZSet: sortare după viteză (clasamente, calendar TTL - evenimente „amânate”).
Stream: cozi stabile cu grupuri de consumatori, 'XREADGROUP '/reluare - pentru webhooks, CDC, retrays.
Geo: „GEOADD/GEORGADIUS” - cele mai apropiate puncte/comercianți.
Bitmap/Bitfield: serie de steaguri (login-uri de zi, DA/WAU).
HyperLogLog: Aproximative Unique (UU) este ieftin pe memorie.
Bloom/Cuckoo (module): verificări rapide ale disponibilității, reducerea „MISS” la sursă.

• RedisJSON (documente JSON), RediSearch (indexare/căutare), RedisBloom (structuri probabilistice), TimeSeries (metrici/agregări).

3) Chei, TTL și politici de memorie

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

Versioning („vN”), include numai dimensiuni semnificative (regiune/monedă/limbă/chiriaș).
Izolați spațiile cheie per-chiriaș.

• Utilizați o matrice TTL (sec/min/h), adăugați jitter (± 10-20%) pentru a evita busculada.
• Pentru tastele fierbinți - reîmprospătare înainte și un singur zbor (actualizări de un lider).

• 'allkeys-lru/lfu' este o memorie cache partajată fără dependență TTL.
• „volatile-lru/lfu” - numai cheile cu TTL.
• „nuevicție” - scrieți eșecul la depășire (mai sigur pentru cozile/contoarele critice).
• Selectați pentru script și monitorizați întotdeauna 'evited _ keys'.

4) Tranzacții, conducte și scripturi

Conducte: reduce RTT, grupa 10-100 echipe.
Tranzacţii (MULTI/Ï) - Nu izolaţi citirile, ci executaţi lotul atomic.
Blocare optimă: „CHEIE DE SUPRAVEGHERE” → verificare → MULTIFUNCŢIONALĂ.
Scripturi Lua: logica atomică pe partea serverului (limita ratei, încuietori, operații compozite).

5) Cozi și autobuze: Lista vs Stream

Lista + „BRPOP” - simplu, dar fără grupuri de consumatori, offset/reluare, rezistență slabă la picături.
Stream: 'XADD → XREADGROUP → XACK', retry-deadletter (nu este luat în N minute), partiționarea prin cheie. Recomandat pentru webhook-uri PSP/KYC, plăți/notificări amânate.

Cozi prioritare: mai multe fluxuri de prioritate, consumatorii „suge” din mare, în primul rând.
Sarcini amânate: ZSet unde scorul = marcaj temporal; periodic „ZRANGEBYSCORE” ≤ acum → transferat la Stream.

6) disponibilitate ridicată și scalabilitate

Replicare: master→replica (read-scale).
Sentinel: automat failover master, descoperire, URI client.
Redis Cluster: 16384-slot sharding, orizontală scară-out. Înfășurați tastele care utilizează mai multe structuri în etichetele hash '{order: 123}'.

• Pentru cache/sesiuni - cluster/replica, „client-side hashing” SDK acceptat.
• Pentru cozi/fluxuri - minimizați operațiunile de tip cross-slot; partiție după chei de domeniu.

7) Persistență: RDB, AOF și copii de rezervă

RDB (instantanee): mai rapid, mai economic; riscul pierderii ultimelor secunde/minute.
AOF (jurnal): mai puține pierderi; moduri "everysec/always'. Compresie AOF și reambalare periodică.
Hibrid: RDB + AOF → recuperare rapidă + pierderi moderate.
Backup-uri: instantanee și copii ale AOF pentru a obiecta de stocare; verificați în mod regulat recuperarea.

Pentru cozi critice/idempotență, selectați replicarea AOF 'everysec' +.

8) Siguranță și conformitate

AUTH/ACL: roluri per aplicație, interzicerea comenzilor „periculoase” ('FLUSHALL,' KEYS').
TLS la client-server și link-uri inter-nod; IP de ieșire fixă.
Segmentarea rețelei: subrețele private, SG/NACL; acces numai de la serviciile/namespace-urile necesare.
Nu înregistrați secrete; PAN/PII în Redis - numai jetoane/derivate.
Comenzi cheie: evitaţi 'KEYS' - utilizaţi' SCAN '.

9) Observabilitate și SLO

• Latență (P95/P99), 'instantanee _ ops _ per _ sec', 'connected _ clients'.
• Raportul de succes, evicted_keys, expired_keys.
• Memorie: folosit, raportul de fragmentare, RSS, statistici de alocare.
• Decalaj replicare, frecvențe și dimensiuni AOF/RDB, timp furculiță.
• Fluxuri: PEL (lista de intrări în așteptare), latență de livrare, încercați din nou numărul.

• Operațiunile Redis P99 ≤ 5-10 ms.
• Evacuări ≤ 1 %/oră (spațiu cache).
• Flux de livrare P99 ≤ 500 мс, rata de încercare din nou <2%.

10) FinOps și planificarea resurselor

Memoria este scumpă: măsoară $/GB-lună RAM vs cereri de salvare la origine/DB.
Activați compresia valorii> 1-2 KB (a se vedea CPU).
LFU poate da un hit mai bun cu mai puțin volum.
Pentru imagini/pete mari - nu Redis: utilizați stocarea obiectelor CDN +.

11) Modele pentru iGaming/fintech

11. 1 Limitarea ratei (Lua)

Idea: 'INCRBY' în fereastră + TTL; Lua verifică atomic limita și crește.

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 Solicită idempotență

Key 'idemp: {request _ id}' cu TTL 24h, valoare - rezultat/stare. Înainte de operaţie, verificăm prezenţa.

11. 3 Clasamente

'ZINCRBY clasament: joc: {g} scor utilizator: {u}' → 'ZREVRANGE... WITHSCORES ".
Pentru partea de sus N de regiune/chiriaș - ZSet individuale sau prefixe.

11. 4 PSP Webhooks coadă

"XADD psp: webhooks... '→ consumer group' XGROUP CREATE psp: webhooks g1 $ '.
Retrage mesajele „blocate” prin scanarea PEL ('XPENDING' → 'XCLAIM').

11. 5 Plăți amânate

ZSet 'payout: due' (scor = epocă) → lucrătorul transferă periodic elemente finite în Stream 'payout:' cu eliminare a duplicatelor.

11. 6 Contoare antifraudă

Combinație de „PFADD” (unic) + „INCR” (intensitate) + etichete geo/ASN; declanșatoare pentru validare manuală.

12) Lucrul cu memoria și performanța

Piscine de conexiune client; reduceți RTT (păstrați în viață).
Prefera conducte la un pachet de comenzi.
Uita-te pentru chei mari ('MEMORY USAGE', 'SCAN') - este mai bine pentru a împărți obiecte.
Hash cu un număr mic de câmpuri este mai economic decât multe chei individuale.
Activați io-threads (read-heavy) dacă profitul este confirmat de teste.
Evitați frecvent "FLUSHDB/ALL' în prod; gestionați prin prefixe și „UNLINK” pentru ștergerea în siguranță.

13) Multi-chiriaș și izolare

Clustere/instanțe individuale sau DB logic per chiriaș (dacă sarcina este mică).
Cote cheie/memorie, ACL-uri divizate.
Prefixe în taste și valori după namespace.

14) Blocarea și consistența

SET cheie val NX PX = ttl - mutex simplu.
Redlock: utilizați cu atenție; pentru tranzacțiile critice distribuite, este mai bine să se bazeze pe „sursa adevărului” (DB/registru) și operațiunile idempotente.
Preferați operațiile atomice și Lua în loc de încuietori „lungi”.

15) Anti-modele

Stocarea de pete mari/imagini - supraîncărcare de memorie RAM și rețele.
Invarianți financiari (bilanț) numai în Redis.
„KEYS' și” scanare lumea 'în prod.
Fără TTL/jitter - dogpile la expirare.
Politica „allkeys-” privind cozile critice → pierderea datelor la presiuni.
Amestecarea cozilor, a memoriei cache și a sesiunilor într-o singură instanță fără cote și priorități.
Scripturi Lua care funcționează pe tastele diferitelor sloturi din Cluster.

16) Lista de verificare a implementării

1. Definiți roluri: cache/sesiuni, cozi/fluxuri, contoare/limite - post la instanțe/clustere.
2. Selectați politica maxmemory pentru sarcină; să stabilească limite și să monitorizeze evacuările.
3. Denumire cheie, versiuni de circuit, matrice TTL + jitter; Un singur zbor pentru cheile de sus.
4. Pentru cozi - Fluxuri (grupuri, retroactive, DLQ), pentru amânare - ZSet + transfer.
5. HA: replicare + Sentinel sau Redis Cluster; verificați eșecul clientului.
6. Persistență: RDB/AOF sub script; backup-uri regulate și un test de recuperare.
7. Securitate: ACL, TLS, rețele private, interzicerea comenzilor periculoase.
8. Observabilitate: latență, ops/sec, memorie, evacuări, decalaj replicare, curent PEL.
9. FinOps: profile de memorie, chei mari, compresie, LFU; evita Redis pentru pete mari.
10. Documentație de model (limită de rată, idempotență, leadboard-uri) și teste de sarcină.

Rezultat

Redis este un „cuțit elvețian multifuncțional” de viteză: cache, cozi, contoare, plumb, structuri geo și probabilistice. Puterea sa constă în alegerea corectă a structurilor de date, disciplina TTL/handicap, atomicitatea operațiunilor și HA/persistența și observabilitatea bine gândite. Utilizați Redis în cazul în care milisecunde și SPR ridicat sunt importante, lăsând în același timp invarianți critice (bani, contabilitate) la „sursa de adevăr” - în acest fel platforma va rămâne atât de rapid și de încredere.