--- title: "Cache pentru API-uri cu trafic mare: Redis și Elasticsearch" description: "Măsurați întâi P95, apoi aplicați cache-aside, TTL-uri bine alese, invalidare și protecție la stampede cu Redis și Elasticsearch. Și ce nu puneți în cache." canonical: https://sdk.enterprises/ro/insights/caching-high-traffic-apis language: ro --- # Cache pentru API-uri cu trafic mare: Redis și Elasticsearch Actualizat: 2026-09-25 > Pentru un API cu trafic mare, măsurați mai întâi, apoi puneți un strat cache-aside în Redis în fața endpointurilor celor mai lente și mai citite, cu TTL-uri explicite, invalidare la scriere și protecție împotriva cache stampede. Folosiți Elasticsearch pentru căutare și pentru listările filtrate pe care baza de date principală le gestionează prost și nu puneți niciodată în cache date specifice unui utilizator sau date strict consistente fără un design gândit anume. ## Măsurați latența P95 înainte de a adăuga orice cache Mediile ascund cererile de care se plâng utilizatorii. Urmăriți latența P95 și P99 pentru fiecare endpoint, împreună cu volumul de cereri, ca să vedeți ce rute sunt în același timp lente și foarte folosite. Apoi aflați unde se duce timpul. O urmărire (trace) sau o simplă defalcare a timpilor pe cerere arată de obicei dacă de vină este o interogare lentă, interogări repetate, un apel către un API extern sau serializarea. Punerea în cache a unui răspuns a cărui problemă reală este un index lipsă doar ascunde problema până la următorul cache miss. - Înregistrați P50, P95 și P99 pentru fiecare endpoint, nu doar o cifră globală - Ordonați endpointurile după volumul de cereri înmulțit cu latența, ca să vedeți unde aduce cache-ul cel mai mult - Verificați raportul dintre citiri și scrieri: datele citite mult mai des decât se schimbă sunt cei mai buni candidați - Reparați indexurile lipsă și interogările N+1 înainte de a pune un cache în jurul lor ## Folosiți cache-aside ca tipar implicit În cache-aside, aplicația verifică mai întâi Redis. La un hit, returnează valoarea din cache. La un miss, citește din baza de date, scrie rezultatul în Redis cu un TTL și îl returnează. Tiparul păstrează baza de date ca sursă de adevăr și eșuează fără riscuri. Dacă Redis este lent sau indisponibil, aplicația revine la baza de date, cu un timeout scurt și un circuit breaker, astfel încât un cache în dificultate să nu încetinească fiecare cerere. Proiectați cheile cu grijă. Includeți tipul resursei, identificatorul, versiunea API-ului și fiecare parametru care schimbă răspunsul, precum limba sau pagina. O schemă de chei previzibilă este ceea ce face posibilă, mai târziu, invalidarea țintită. ## Stabiliți TTL-urile după cât de vechi pot fi datele, apoi invalidați la schimbare Un TTL este o decizie de business scrisă ca un număr. Întrebați-vă cât de vechi pot fi datele înainte ca un utilizator sau un sistem din aval să aibă de suferit și stabiliți TTL-ul pe baza acestui răspuns. Scorul unui meci în direct și un articol arhivat tolerează grade de învechire foarte diferite. Dacă vă bazați doar pe expirare, serviți date învechite până se termină TTL-ul. Pentru datele pe care le modifică propria aplicație, ștergeți sau suprascrieți cheia după ce scrierea este confirmată (commit), ideal dintr-un eveniment emis după tranzacție, pentru ca cache-ul să nu păstreze niciodată date pe care baza de date le-a anulat (rollback). Adăugați la TTL-uri o mică variație aleatorie (jitter), pentru ca cheile scrise în același timp să nu expire toate în același moment. - TTL scurt, de câteva secunde, pentru datele care se schimbă repede și unde o ușoară întârziere este acceptabilă - TTL mai lung plus invalidare la scriere pentru datele pe care le controlați și care se schimbă rar - Chei versionate: incrementarea unui număr de versiune invalidează dintr-odată un întreg grup de chei ## Protejați baza de date de cache stampede Un stampede apare când o cheie populară expiră și multe cereri simultane ratează cache-ul în același timp, trimițând toate aceeași interogare costisitoare către baza de date. Pe un API cu trafic mare, asta poate supraîncărca baza de date exact în momentul de vârf al traficului. Combinați două sau mai multe dintre aceste apărări pentru cheile cele mai solicitate. - Coalescența cererilor: o singură cerere reconstruiește cheia sub un lock Redis scurt, setat cu NX și o expirare, în timp ce celelalte așteaptă puțin sau servesc valoarea anterioară - Stale-while-revalidate: stocați o expirare „soft” în interiorul valorii, continuați să serviți copia învechită după acest termen și reîmprospătați în fundal - Reîmprospătare probabilistică timpurie: reconstruiți ocazional o cheie solicitată înainte să expire, cu o probabilitate care crește pe măsură ce se apropie expirarea - Preîncălzire: populați cheile solicitate cunoscute înainte de un vârf de trafic programat, precum un mare eveniment în direct ## Folosiți Elasticsearch pentru căutare și listări, nu drept cache general Redis este cel mai bun pentru căutări cheie-valoare: un singur obiect, un fragment calculat, un contor de limitare a ratei. Elasticsearch servește la altceva: căutare full-text, filtre pe fațete și listări sortate, costisitoare de calculat într-o bază de date relațională. Tratați indexul Elasticsearch ca pe un model de citire alimentat din baza de date principală, prin evenimente de schimbare sau printr-o sincronizare programată, și acceptați că este consistent doar în cele din urmă (eventual consistency). Păstrați baza de date ca autoritate pentru scrieri și pentru tot ce trebuie să fie exact. Pe platforma media sportivă NorthStar Network, care deservește 50M+ de utilizatori lunari, inginerii noștri au rearhitecturat API-uri critice și au reproiectat cache-ul în Redis și Elasticsearch, ceea ce a redus timpii de răspuns P95. ## Știți ce nu trebuie pus în cache Cel mai costisitor bug de cache este servirea datelor unui utilizator către altul. Verificați ca fiecare endpoint pus în cache să aibă identitatea în cheie și testați-l cu două conturi diferite înainte de lansare. - Răspunsurile care depind de identitatea sau de permisiunile apelantului, cu excepția cazului în care cheia include utilizatorul sau rolul - Datele care trebuie să fie strict consistente, precum soldurile, stocul la finalizarea comenzii sau orice folosit în decizii de autorizare - Endpointurile de scriere, tokenurile de unică folosință și tot ce are efecte secundare - Endpointurile cu trafic redus, unde un cache adaugă complexitate și un nou mod de defectare pentru un câștig mic - Payloadurile foarte mari, care scot din cache multe chei mai mici și mai solicitate ## Faceți cache-ul observabil, altfel nu vă puteți baza pe el Urmăriți rata de hit pe fiecare prefix de cheie, memoria folosită de Redis și evacuările din cache (evictions), latența comenzilor Redis și încărcarea bazei de date, alături de P95 al API-ului, pe același dashboard. Când P95 se mișcă, trebuie să puteți spune în câteva minute dacă de vină este cache-ul, baza de date sau un serviciu din amonte. Setați alerte la o scădere bruscă a ratei de hit, care înseamnă adesea că un deploy a schimbat un format de cheie, și la creșterea evacuărilor, care arată că cache-ul este prea mic pentru setul de date folosit activ. Preluăm lucrările de performanță API ca un bloc bine definit: măsurare, reproiectarea stratului de cache și predarea dashboardurilor și a runbookurilor către echipa care îl operează. ## De reținut - Măsurați P95 pe fiecare endpoint și rezolvați problemele de interogare înainte de a adăuga un cache. - Cache-aside în Redis este cea mai sigură opțiune implicită, pentru că baza de date rămâne sursa de adevăr. - Stabiliți TTL-urile după cât de vechi pot fi datele și invalidați la scriere datele pe care le controlați. - Protejați cheile solicitate împotriva stampede cu lock-uri, stale-while-revalidate sau preîncălzire. - Folosiți Elasticsearch ca model de citire consistent în cele din urmă, pentru căutare și listări, nu drept cache general. ## Întrebări frecvente ### Redis sau Elasticsearch pentru cache-ul răspunsurilor API? Folosiți Redis pentru cache-ul cheie-valoare al obiectelor, al fragmentelor calculate și al contoarelor, pentru că accesul după cheie este rapid și ușor de invalidat. Folosiți Elasticsearch când partea costisitoare este căutarea, filtrarea sau sortarea pe multe înregistrări și tratați indexul lui ca pe un model de citire, nu ca pe un cache. ### Care este un TTL bun pentru răspunsurile unui API? Nu există o valoare universală. Stabiliți fiecare TTL după cât de vechi pot fi datele respective fără să afecteze un utilizator, folosiți câteva secunde pentru datele care se schimbă repede și combinați TTL-urile mai lungi cu invalidarea la scriere. Adăugați o variație aleatorie (jitter), ca cheile înrudite să nu expire împreună. ### Cum preveniți un cache stampede în Redis? Lăsați o singură cerere să reconstruiască o cheie expirată, luând un lock scurt cu SET și opțiunea NX, iar celelalte cereri să aștepte puțin sau să servească valoarea anterioară. Stale-while-revalidate și reîmprospătarea timpurie a cheilor solicitate reduc de la bun început numărul expirărilor bruște. ## Servicii conexe - [Software la comandă](https://sdk.enterprises/ro/services/product-engineering)