Redis può eseguire script Lua lato server — eseguendo più comandi come un'unica operazione atomica. Gli script abilitano una logica atomica complessa, riducono i round-trip di rete e sono il modo consigliato per eseguire operazioni atomiche multi-step in Redis.
# EVAL runs a Lua script; KEYS[] and ARGV[] pass keys and arguments
EVAL 1 mykey myvalue
EVAL 1 lock:resource mytoken
Gli script usano redis.call() per eseguire comandi, con KEYS[] (nomi delle chiavi) e ARGV[] (argomenti) passati. L'intero script viene eseguito atomicamente come una singola unità.
✓ ATOMICITY — the ENTIRE script runs as one unit, no other commands interleave
→ perfect for read-modify-write logic that must be atomic (locks, conditional updates,
rate limiting, complex counters) — better than MULTI/EXEC for conditional logic
✓ FEWER ROUND-TRIPS — multiple operations in ONE call to Redis (less network latency)
✓ Custom LOGIC server-side — conditionals, loops, computations near the data
# load a script once, then call by its SHA hash (avoids resending the script each time)
SCRIPT LOAD "return redis.call('GET', KEYS[1])" # => returns a SHA1 hash
EVALSHA <sha> 1 mykey # run the cached script by hash
EVALSHA esegue uno script precedentemente caricato tramite il suo hash — efficiente per script usati di frequente (lo script è memorizzato in cache lato server).
⚠️ Scripts BLOCK the server while running (Redis is single-threaded) → keep them FAST
and simple (no slow loops/operations — they'd stall ALL clients)
⚠️ Scripts should be deterministic; pass keys via KEYS[] (for cluster correctness)
→ Use scripts for short, atomic logic — not heavy computation.
Comprendere lo scripting Lua in Redis è una conoscenza di livello senior preziosa per eseguire operazioni atomiche complesse, quindi è utile per l'uso avanzato di Redis.
Il valore principale è l'atomicità per la logica multi-step: uno script Lua viene eseguito interamente come una singola unità atomica (nessun altro comando si interpone), rendendolo il modo consigliato per eseguire operazioni read-modify-write che devono essere atomiche — come aggiornamenti condizionali, rilascio sicuro del lock (elimina solo se il token corrisponde), rate limiting e contatori complessi — spesso migliore di MULTI/EXEC perché gli script supportano logica condizionale (la transazione non può prendere decisioni in base alle letture intermedie, ma uno script può).
Questo risolve un'esigenza reale di operazioni atomiche più complesse dei singoli comandi.
Un vantaggio secondario è meno round-trip di rete (più operazioni in una chiamata, riducendo la latenza) e l'esecuzione di logica personalizzata lato server (vicino ai dati).
Comprendere EVALSHA (caching degli script per hash per evitare di inviarli di nuovo) è una tecnica pratica di efficienza per script usati di frequente.
Criticamente, comprendere le avvertenze è importante: gli script bloccano il server single-threaded mentre vengono eseguiti, quindi devono essere mantenuti veloci e semplici (uno script lento blocca tutti i client — un vero pericolo di prestazioni), e gli script dovrebbero essere deterministici con le chiavi passate tramite KEYS[] (per la correttezza del cluster).
Questa consapevolezza previene l'uso improprio degli script per calcoli pesanti.
Poiché le operazioni atomiche complesse sono un'esigenza genuina (lock, logica condizionale, aggiornamenti multi-step atomici), e poiché gli script Lua forniscono logica atomica, a round-trip singolo e lato server che è l'approccio consigliato per esse (con importanti avvertenze sul blocco), comprendere lo scripting Lua — come funziona, perché è atomico e utile, il caching EVALSHA e le avvertenze keep-it-fast — è una conoscenza di livello senior preziosa per l'uso avanzato di Redis, lo strumento giusto per la logica atomica multi-step e un argomento che riflette un'expertise più profonda di Redis.