Redis — Cheat Sheet

Tag: redis, in-memory, cache, database, nosql, key-value, pub-sub

Livello: intermedio

TL;DR: Data store in-memory chiave-valore usato principalmente come cache veloce, message broker e database ausiliario. Offre altissime prestazioni a latenza sub-millisecondo grazie all'architettura in-memory.

Concetti chiave

Architettura in-memory: i dati risiedono in RAM, garantendo tempi di accesso minimi.

Single-threaded: il thread principale esegue un comando alla volta in sequenza, garantendo atomicità senza lock complessi.

Persistenza RDB: snapshot del dataset salvati su disco a intervalli di tempo configurabili.

Persistenza AOF: log in accodamento di tutte le operazioni di scrittura (Append Only File) per massima durabilità.

Eviction: gestione automatica della memoria in esaurimento (es. scarto delle chiavi LRU, LFU, o tramite TTL).

Replicazione: supporta repliche read-only per scalare le letture e garantire alta disponibilità.

High Availability: Redis Sentinel gestisce monitoraggio, notifiche e failover automatico verso i nodi replica.

Scalabilità: Redis Cluster distribuisce i dati automaticamente su più nodi (sharding orizzontale).

Strutture dati native: gestisce internamente String, Hash, List, Set, Sorted Set (ZSET), Bitmap e HyperLogLog.

Domande tipiche e risposte pronte

Q: Qual è la differenza tra RDB e AOF e quale usi?R: RDB fa snapshot veloci ma può perdere gli ultimi dati in caso di crash. AOF logga ogni comando per massima sicurezza. In produzione li abilito entrambi per combinare recupero veloce e durabilità.

Q: Cosa succede se la memoria di Redis si satura?R: Dipende dalla maxmemory-policy. Solitamente la imposto su allkeys-lru o volatile-lru per eliminare in automatico le chiavi vecchie, altrimenti Redis restituisce errore sulle scritture (OOM).

Q: Perché non bisognerebbe mai usare il comando KEYS in produzione?R: Perché Redis è single-threaded. KEYS * deve scansionare tutto il keyspace e blocca il server per tutti gli altri client. Uso sempre SCAN che itera a blocchi senza bloccare.

Q: Come gestisci transazioni e lock distribuiti su Redis?R: Per transazioni base uso MULTI/EXEC. Per i lock distribuiti implemento pattern come Redlock usando SET NX PX per garantire mutua esclusione con scadenza.

Insidie e errori comuni

Esporre la porta 6379 su interfacce pubbliche senza impostare direttive bind o password (requirepass).

Salvare oggetti JSON enormi in una singola chiave String invece di usare un Hash, causando picchi di latenza.

Dimenticarsi di impostare un TTL (Time To Live) per le chiavi temporanee, saturando inutilmente la memoria nel lungo periodo.

Affidarsi a Redis come unico datastore per dati critici senza un piano di backup esterno e testato.

Snippet e comandi

# Avviare CLI con password e database specifico (es. db 1)
redis-cli -h 127.0.0.1 -p 6379 -a "mypassword" -n 1

# Stringhe con TTL (Scadenza in 60 secondi)
SET session:123 "data" EX 60
GET session:123

# Iterare chiavi in modo sicuro senza bloccare il server
SCAN 0 MATCH "user:*" COUNT 100

# Hash (ideali per mappare oggetti flat)
HSET user:100 nome "Mario" ruolo "Admin"
HGETALL user:100

# Sorted Set (ottimi per leaderboard o code prioritarie)
ZADD leaderboard 1500 "giocatore1"
ZREVRANGE leaderboard 0 10 WITHSCORES

# Pub/Sub: Iscrizione a un canale e invio messaggi
SUBSCRIBE channel_events
PUBLISH channel_events "Nuovo ordine creato"