Chiar dacă o interogare Redis pe rețea locală răspunde în doar 0.5 – 1 milisecundă, aplicațiile de scară extremă (cum ar fi e-commerce-ul în ore de vârf sau sistemele financiare de trading) pot fi încetinite de latența cumulată a zeci de mii de apeluri TCP repetitive pentru date care se modifică foarte rar.
Client-Side Caching (introdus în Redis 6) permite clienților să stocheze o copie a datelor direct în memoria RAM a aplicației locale (L1 Cache). Atunci când datele sunt modificate pe serverul Redis de către un alt proces, Redis trimite automat un mesaj asincron de invalidare prin protocolul RESP3 pentru ca instanța locală să șteargă copia învechită.
Cele Două Moduri de Client-Side Tracking în Redis
# MODUL 1: Tracking Standard (Default)
# - Serverul Redis menține un tabel intern cu cheile citite de fiecare conexiune (Invalidation Table).
# - Dacă clientul A a citit 'produs:1', iar clientul B rulează 'SET produs:1 "nou"',
# Redis trimite un mesaj PUSH către clientul A: "Șterge cheia produs:1 din cache-ul tău local!".
# - Limită: Consumă memorie pe serverul Redis pentru a ține minte cine ce chei a citit.
# Activare pe conexiunea curentă (necesită protocol RESP3):
HELLO 3
CLIENT TRACKING on
# MODUL 2: Tracking prin Broadcast (BCAST) - Recomandat în Producție
# - Serverul Redis NU mai ține minte ce chei specifice a citit fiecare client!
# - În schimb, clienții se înregistrează pentru anumite prefixe de chei.
# - De fiecare dată când o cheie cu acel prefix este modificată, serverul transmite
# notificarea către toți clienții abonați la acel prefix.
# Înregistrare pentru notificări de invalidare pe prefixul 'produse:':
CLIENT TRACKING on BCAST PREFIX produse:Avantaje Măsurabile în Producție
- Latență de ordinul nanosecundelor: Citirea cheilor din L1 se realizează la viteza memoriei locale (fără socket TCP, fără serializare).
- Degrevare Masivă a Clusterului: Debitul de interogare pe clusterul Redis scade drastic pentru date intens citite (cataloage de produse, configurații globale).