Redis może wykonywać skrypty Lua po stronie serwera — uruchamiając wiele poleceń jako pojedynczą atomową operację. Skrypty umożliwiają złożoną logikę atomową, zmniejszają liczbę objazdów sieciowych i są zalecanym sposobem wykonywania wieloetapowych operacji atomowych w Redis.
EVAL 1 mykey myvalue
EVAL 1 lock:resource mytoken
Skrypty używają redis.call() do wykonywania poleceń, z KEYS[] (nazwy kluczy) i ARGV[] (argumenty) przekazywanymi jako parametry. Cały skrypt wykonuje się atomowo jako jedna jednostka.
✓ 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 wykonuje wcześniej załadowany skrypt poprzez jego hash — efektywne dla często używanych skryptów (skrypt jest buforowany po stronie serwera).
⚠️ 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.
Zrozumienie skryptowania Lua w Redis to cenna wiedza na poziomie seniora dla wykonywania złożonych operacji atomowych, dlatego jest przydatne do zaawansowanego użytku Redis.
Zasadnicza wartość to atomowość dla logiki wieloetapowej: skrypt Lua wykonuje się całkowicie jako jedna jednostka atomowa (żadne inne polecenia się nie przeplatają), co czyni go zalecanym sposobem wykonywania operacji odczyt-modyfikacja-zapis, które muszą być atomowe — takich jak aktualizacje warunkowe, bezpieczne zwalnianie blokad (usuwanie tylko jeśli token się zgadza), ograniczanie szybkości i złożone liczniki — czasem lepiej niż MULTI/EXEC, ponieważ skrypty obsługują logikę warunkową (transakcja nie może podejmować decyzji na podstawie pośrednich odczytów, ale skrypt może).
Rozwiązuje to rzeczywistą potrzebę operacji atomowych bardziej złożonych niż pojedyncze polecenia.
Dodatkową korzyścią jest mniej objazdów sieciowych (wiele operacji w jednym wywołaniu, zmniejszające opóźnienie) i uruchamianie niestandardowej logiki po stronie serwera (blisko danych).
Zrozumienie EVALSHA (cachowanie skryptów po hashie, aby uniknąć ich ponownego przesyłania) to praktyczna technika wydajności dla często używanych skryptów.
Krytycznie, rozumienie ostrzeżeń jest ważne: skrypty blokują jednowątkowy serwer podczas wykonywania, dlatego muszą być szybkie i proste (powolny skrypt zatrzymuje wszystkich klientów — rzeczywiste zagrożenie wydajności), a skrypty powinny być deterministyczne z kluczami przekazywanymi przez KEYS[] (dla poprawności klastra).
Ta świadomość zapobiega niewłaściwemu używaniu skryptów do intensywnych obliczeń.
Ponieważ złożone operacje atomowe to rzeczywista potrzeba (blokady, logika warunkowa, atomowe aktualizacje wieloetapowe), a skrypty Lua zapewniają atomową, jednokierunkową, logikę po stronie serwera, która jest zalecanym podejściem dla nich (z istotnymi ostrzeżeniami dotyczącymi blokowania), zrozumienie skryptowania Lua — jak to działa, dlaczego jest atomowe i przydatne, cachowanie EVALSHA i ostrzeżenia dotyczące szybkości — to cenna wiedza na poziomie seniora dla zaawansowanego użytku Redis, odpowiednie narzędzie dla atomowej logiki wieloetapowej i temat odzwierciedlający głęboką wiedzę na temat Redis.