Tecnologia e infrastruttura di Redis: soluzioni in-memory

Redis: soluzioni in-memory

1) Dove Redis è appropriato

• Kesh (read-through/aside, TTL, SWR) e sessioni.
• Contatori e quote: rate limiting, antifrode, limiti di campagna.
• Liderboard/rating (ZSET), raccomandazioni «top-N».
• Code/pneumatici eventi (Streams/PubSub), outbox/inbox, retrai.
• Idempotenza (chiavi con TTL), de-dup webhook.
• Geo (ricerca dei punti più vicini), Bitmap (flag, DAU).
• Alias/token e cache di autorizzazione a breve vita.

2) Strutture dei dati e quando applicarli

String: valori/contatori ('INCRBY'), chiavi idipotenti.
Aggregazioni di profili/configure, memorizzazione di oggetti leggeri.
List: code semplici (ma senza replay/offset-semantic).
Elementi univoci, deduplicazione.
ZSet: ordinamento per scorrimento (liderboard, calendario TTL - Eventi ritardati).
Stream: code sostenibili con gruppi di consumatori, «XREADGROUP »/replay - per webhoop, CDC, retrai.
GEO: 'GEOADD/GEORADIUS' - punti/merchant più vicini.
Bitmap/Bitfield: serie di bandiere (login giornalieri, DAU/WAU).
HyperLogLog - Unici approssimativi (UU) a basso costo di memoria.
Bloom/Cuckoo (moduli) - Controlli rapidi della presenza, riduce MISS all'origine.

• RedisJSON (documenti JSON), RediSearch (indicizzazione/ricerca), RedisBloom (strutture probabilistiche), TimeSeries (metriche/aggregazioni).

3) Chiavi, TTL e criteri di memoria

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

Versionare ('vN'), includere solo misure significative (regione/valuta/lingua/tenante).
Isolare gli spazi delle chiavi per-tenant.

• Utilizzare la matrice TTL (secondi/minuti/ora), aggiungere un jitter (© 10-20%) per evitare stampede.
• Per le chiavi hot - refresh-ahead e single-flight (un leader aggiorna).

• «allkeys-lru/lfu» è una cache condivisa senza TTL.
• «volatile-lru/lfu» è solo una chiave TTL.
• «noeviction» è un errore di scrittura in caso di sovraccarico (sicuro per le code/contatori critici).
• Seleziona sotto lo script e monitora sempre «evicted _ keys».

4) Transazioni, pipline e script

Pipline: riduce RTT, raggruppa 10-100 comandi.
Transazioni (MULTI/EXEC) - Non isolano la lettura, ma eseguono atomicamente il pacchetto.
Ottimistic locking: 'WATCH key'controllo MULTI/EXEC'.
Script Lua: logica atomica sul lato server (rate limit, locks, composite-operazione).

5) Code e pneumatici: List vs Stream

List + «BRPOP» è semplice, ma nessun consumer groups, offset/replay, debole resistenza ai cali.
STREAM: 'XADD' XREADGROUP 'XACK', retry-deadletter '(non in N minuti), partizionamento su chiave. Consigliato per siti PSP/KYC, pagamenti/notifiche posticipati.

Le code prioritarie sono diverse per priorità, i consumatori «succhiano» da alto in primo luogo.
Attività posticipate: ZSet dove score = timestamp; il periodico «ZRANGEBYSCORE» viene trasferito in Stream.

6) Elevata disponibilità e scalabilità

Replica master→replica (read-scale).
Sentinel: failover master automatico, rilevamento, URI client.
Redis Cluster: Scale-out orizzontale per 16384 slot. Le chiavi che utilizzano più strutture sono avvolte nei tag hash «{order: 123}».

• Per cache/sessione - cluster/repliche, 'client-side hasing'supportato da SDK.
• Per code/striam: minimizza le operazioni di cross-slot; Partizionare le chiavi del dominio.

7) Perseveranza: RDB, AOF e bacap

RDB (snapshot): più veloce, più economico Rischio di perdita degli ultimi secondi/minuti.
AOF (registro) - Meno perdite; modalità «everysec/always». Compressione AOF e rielaborazione periodica.
RDB + AOF: ripristino rapido + perdita moderata.
Backup: snapshot e copie di AOF nel deposito oggetti; Verificare regolarmente il ripristino.

Per le code critiche/idampotenza, selezionare AOF «everysec» + replica.

8) Sicurezza e compliance

AUTH/ACL: ruoli per-applicazione, non comandi «pericolosi» («FLUSHALL», «KEYS»).
TLS per client-server e lines intersito egress-IP fisso.
Segmentazione della rete: subnet private, SG/NACL; Accesso solo da servizi/neimspace.
I segreti non sono logici; PAN/PII in Redis sono solo token/derivati.
Comandi chiave: evita «KEYS» - Usa «SCAN».

9) Osservabilità e 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 frequenze e dimensioni, fork time.
• Streams: PEL (pending entries list), delivery latency, retry count.

• Le operazioni della Redis P99 sono 5-10 ms.
• Evictions ≤ 1 %/ora (kash).
• Stream delivery P99 ≤ 500 мс, retry rate < 2%.

10) Pianificazione e pianificazione delle risorse

Memoria strada: misura $/GB-mes RAM vs risparmio di richieste origin/database.
Abilita la compressione dei valori> 1-2 KB (vedi CPU).
LFU può dare il miglior hit con un volume inferiore.
Per immagini/blob di grandi dimensioni - non Redis: usa CDN + archivio oggetti.

11) Pattern per iGaming/Fintech

11. 1 Rate limiting (finestra scorrevole, Lua)

Idea: «INCRBY» in chiave finestra + TTL; Lua controlla atomonicamente il limite e aumenta.

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 Idampotenza delle richieste

Chiave dì idemp: {richiest _ id} "con TTL 24h, valore risultato/stato. Prima di eseguire l'operazione, controlliamo se c'è.

11. 3 Liderbord

`ZINCRBY leaderboard:game:{g} score user:{u}` → `ZREVRANGE... WITHSCORES`.
Per i Top N per regione/tenante, i singoli ZSet o prefissi.

11. 4 Coda webhoop PSP

«XADD psp: webhooks...» gruppo di consumatori «XGROUP CREATE psp: webhooks g1 $».
Retrai dei messaggi «dipendenti» tramite scansione PEL («XPENDING» «XCLAIM»).

11. 5 Pagamenti ritardati

ZSet'payout: due '(score = epoch) → worker trasferisce periodicamente gli elementi finiti in Stream'payout: exec', con deduplicazione.

11. 6 Contatori antifrode

Combinazione «PFADD» (univoci) + «INCR» (intensità) + geo/etichette ASN; trigger per il controllo manuale.

12) Memoria e prestazioni

Pool di connessione client Ridurre il formato RTT (keep-alive).
Preferisci le pipeline al pacchetto di comandi.
Tieni d'occhio big keys («MEMORY USAGE», «SCAN») - È meglio frazionare gli oggetti.
Hash con pochi campi è più economico di molte chiavi singole.
Attivare io-threads (read-heavy) se il profilo è confermato dai test.
Evitare i frequenti «FLUSHDB/ALL» in vendita; Controlla tramite prefissi e UNLINK per eliminare in modo sicuro.

13) Multi-tenente e isolamento

Singoli cluster/istanze o logical DB per-tenant (se il carico è basso).
Quote di chiavi/memoria separate ACL.
Prefissi in chiave e metriche in namespace.

14) Locking e coerenza

SET key val NX PX = ttl - mutex semplice.
Redlock - Utilizzare con attenzione; per le transazioni critiche distribuite, è meglio basarsi su «sorgente di verità» (database/ledger) e operazioni idropotenti.
Preferite le operazioni atomiche e Lua invece dei blocchi prolungati.

15) Anti-pattern

Storage di grandi blob/immagini - Sovrastampa RAM e reti.
Invarianti finanziari (saldo) solo in Redis.
«KEYS» e «scansione del mondo» in vendita.
Assenza di TTL/jitter - dogpile in scadenza.
Allkeys- su code critiche, perdita di dati a pressione.
Miscelare code, cash e sessioni in un'unica istanza senza quote e priorità.
Script Lua che usano le chiavi dei diversi slot in Cluster.

16) Assegno-foglio di implementazione

1. Definire i ruoli: kash/sessioni, code/striam, contatori/limiti - Esplode le istanze/cluster.
2. Selezionare maxmemory-policy per l'attività; impostare i limiti e il monitoraggio degli evictions.
3. Nayming chiavi, versioni di schemi, matrice TTL + jitter; single-flight per le chiavi top.
4. Per le code, Streams (gruppi, retrai, DLQ), ZSet + migrazione per le code.
5. HA: replica + Sentinel o Redis Cluster; Controlla il failover del client.
6. Persistenza: RDB/AOF sotto lo script; Becap regolari e test di recupero.
7. Sicurezza: ACL, TLS, reti private, proibizione di comandi pericolosi.
8. Osservabilità latency, ops/sec, memory, evictions, replication lag, stream PEL.
9. FinOps profili di memoria, chiavi grandi, compressione, LFU; Evitate Redis per i grandi blob.
10. Documentazione dei pattern (rate-limit, idipotenza, liderboard) e test di carico.

Totale

Redis è il «coltello svizzero multifunzione» della velocità: cash, code, contatori, liderbord, geo e strutture probabilistiche. La sua forza è nella scelta corretta delle strutture dei dati, nella disciplina della TTL/invalidità, nell'atomatologia delle operazioni, e nella percezione/persuasività. Usate Redis dove i millisecondi e l'RPS elevato sono importanti, lasciando invarianti critici (denaro, contabilità) alla fonte della verità - in modo che la piattaforma rimanga veloce e affidabile.