Redis 8.8: array-uri native și rate limiting cu INCREX

Redis 8.8 a ajuns la disponibilitate generală (GA) săptămâna aceasta și două dintre adăugiri contează pentru oricine îl rulează în spatele unui API. Principala noutate este un tip de date Array nativ, contribuit de creatorul Redis, Salvatore Sanfilippo. De ani de zile, echipele au simulat colecții ordonate și indexabile cu liste sau sorted sets. Acum există o structură dedicată pentru asta, astfel că poți agrega date și face operații poziționale pe server, în loc să aduci datele înapoi la client și să le parcurgi în buclă. Cealaltă noutate este INCREX, o comandă de tip window-counter care combină INCR, verificarea limitelor și expirarea într-o singură operație atomică. Pe înțelesul tuturor, „100 de cereri pe minut” este acum o singură comandă, în loc de un script Lua scris de mână sau o succesiune atentă de comenzi multiple.

Mai sunt și alte îmbunătățiri: notificări pentru sub-chei ale câmpurilor hash, o comandă XNACK care permite consumatorilor de stream-uri să returneze mesajele blocate, și o rundă de optimizări de performanță care include portarea unor căi critice la Rust și activarea optimizării în faza de link-editare (link-time optimization) pentru build-urile x86_64. Plus corecțiile obișnuite de securitate și bug-uri. Dar tipul array și INCREX sunt schimbările pe care le vor observa primele cele mai multe echipe.

Iată perspectiva noastră. INCREX este cel care merită atenție. Am revizuit multe baze de cod în care rate limiting-ul era un script Lua pe care cineva l-a scris în grabă și pe care nimeni nu l-a mai atins de atunci. Acele scripturi funcționează bine până când nu mai funcționează: o greșeală de tip off-by-one în calculul ferestrei de timp, un TTL care nu se setează niciodată la prima accesare, o condiție de cursă sub sarcină care lasă un burst să treacă. Din experiența noastră cu PHP și Docker în construirea de API-uri pentru clienți enterprise, rate limiting-ul este unul dintre acele lucruri care par banale și, în tăcere, nu sunt. O singură comandă atomică care deține contorul, limita și expirarea elimină o întreagă categorie de astfel de bug-uri.

Acestea fiind spuse, nu scoate codul funcțional din uz în prima zi. O comandă nativă ajută doar dacă migrezi efectiv la versiunea 8.8 și ai încredere în ea în producție. Dacă ești deja pe Redis 8.x și rate limiting-ul tău este Lua personalizat, prototipizează INCREX în staging, testează-l cu tipare de trafic reale și compară comportamentul la marginile ferestrei de timp înainte să faci trecerea. Dacă ești pe un Redis mai vechi, tratează asta ca un motiv să planifici upgrade-ul, nu să-l faci vineri după-amiază.

Tipul array contează mai mult pentru workload-urile read-heavy și cele de tip analytics. Când construim aplicații cloud-native pe AWS, ucigașul de latență nu este rareori Redis însuși. Sunt round trip-urile. Fiecare operație de tip „aduc lista, filtrez pe client, trimit înapoi o parte din ea” este un salt în rețea pe care îl plătești la fiecare cerere. Operațiile poziționale pe server elimină asta. Am văzut același pattern afectând echipele mobile: în proiectele noastre native iOS și Android, în special în aplicațiile offline-first din domeniul sănătății și IoT, un backend care comunică excesiv consumă bateria și face sincronizarea să pară lentă pe rețele slabe. A face mai mult într-un singur apel server-side este un câștig real atunci când clientul e în tren printr-un tunel.

O notă din perspectiva securității. În timpul angajamentelor noastre de pentesting și când configurăm Cloudflare pentru protecție DDoS, tratăm rate limiting-ul la nivel de aplicație și protecția la nivel de edge ca două straturi diferite, nu ca substitute. INCREX face stratul de aplicație mai curat. Nu înlocuiește rate limiting-ul la nivel de edge în fața originii tale. Dacă singurul tău mecanism de throttling trăiește în Redis, un atacator care îți poate epuiza pool-ul de conexiuni nu va ajunge niciodată la codul care îl apelează. Păstrează ambele straturi.

Deci ce ar trebui să faci efectiv săptămâna aceasta? Găsește-ți codul de rate limiting. Fie că este un script Lua, un pachet middleware sau câteva linii copiate dintr-un articol de blog cu ani în urmă, citește-l din nou și confirmă că face ceea ce crezi că face sub sarcină concurentă. Indiferent dacă adopți sau nu INCREX, acel audit valorează mai mult decât upgrade-ul în sine. O lansare de baze de date este un bun pretext pentru a te uita la lucrurile pe care ai încetat să le mai verifici.

Tratăm versiunea 8.8 la fel cum tratăm orice lansare minoră de baze de date pentru un client: citim changelog-ul, notăm corecțiile de securitate, testăm funcționalitățile care ne interesează în staging și programăm deliberat upgrade-ul. Tipul array nativ și INCREX sunt cu adevărat utile. Disciplina în adoptarea lor este cea care menține producția plictisitoare, ceea ce este exact cum ne place.

Dacă rate limiting-ul personalizat sau un strat Redis prea verbos ți se par familiare, să vorbim.