--- title: "Nagy forgalmú API-k gyorsítótárazása: Redis és Elasticsearch" description: "Mérje előbb a P95-öt, aztán cache-aside, észszerű TTL, invalidálás és stampede elleni védelem Redisszel és Elasticsearch-csel. És mit ne gyorsítótárazzon." canonical: https://sdk.enterprises/hu/insights/caching-high-traffic-apis language: hu --- # Nagy forgalmú API-k gyorsítótárazása: Redis és Elasticsearch Frissítve: 2026-09-25 > Egy nagy forgalmú API gyorsítótárazását méréssel kezdje, majd a leglassabb és leggyakrabban olvasott végpontok elé tegyen egy Redisre épülő cache-aside réteget, explicit TTL-ekkel, íráskori invalidálással és a cache stampede (a gyorsítótár-roham) elleni védelemmel. Az Elasticsearch-öt a keresésre és a szűrt listákra használja, amelyeket az elsődleges adatbázis rosszul kezel, és felhasználóhoz kötött vagy szigorú konzisztenciát igénylő adatot soha ne gyorsítótárazzon tudatos tervezés nélkül. ## Mérje a P95-ös késleltetést, mielőtt bármilyen gyorsítótárat bevezet Az átlagok elrejtik azokat a kéréseket, amelyekre a felhasználók panaszkodnak. Kövesse végpontonként a P95-ös és P99-es késleltetést a kérések számával együtt, így látni fogja, mely útvonalak lassúak és egyben erősen használtak. Aztán derítse ki, hová megy el az idő. Egy trace vagy a kérésenkénti időráfordítás egyszerű lebontása általában megmutatja, hogy lassú lekérdezés, ismétlődő lekérdezések, külső API-hívás vagy a szerializálás a költséges rész. Ha egy olyan választ gyorsítótáraz, amelynek valódi gondja egy hiányzó index, azzal a problémát csak elrejti, a következő cache miss pillanatáig, amikor a kért adat nincs a gyorsítótárban. - Végpontonként rögzítse a P50, P95 és P99 értéket, ne csak egy globális számot - Rangsorolja a végpontokat a kérésszám és a késleltetés szorzata szerint, hogy lássa, hol térül meg leginkább a gyorsítótárazás - Nézze meg az olvasások és írások arányát, mert a legjobb jelölt az az adat, amelyet sokkal gyakrabban olvasnak, mint ahogy változik - A hiányzó indexeket és az N+1 lekérdezéseket javítsa ki, mielőtt gyorsítótárat tenne köréjük ## Alapértelmezett mintaként használja a cache-aside-ot Cache-aside esetén az alkalmazás először a Redisben keres. Találat esetén a gyorsítótárazott értéket adja vissza. Ha nincs találat, az adatbázisból olvas, az eredményt TTL-lel beírja a Redisbe, és visszaadja. A minta az adatbázist tartja meg az igazság forrásának, és hiba esetén biztonságosan viselkedik. Ha a Redis lassú vagy elérhetetlen, az alkalmazás az adatbázishoz fordul, rövid időkorláttal és circuit breakerrel (áramkör-megszakítóval), hogy egy akadozó gyorsítótár ne lassítson le minden kérést. A kulcsokat tudatosan tervezze meg. Szerepeljen bennük az erőforrás típusa, az azonosító, az API-verzió és minden paraméter, amely megváltoztatja a választ, például a nyelv vagy az oldalszám. Egy kiszámítható kulcsséma teszi később lehetővé a célzott invalidálást. ## A TTL-t az adat megengedett elavultsága szerint állítsa be, és változáskor invalidáljon A TTL számként leírt üzleti döntés. Tegye fel a kérdést, milyen régi lehet az adat, mielőtt kárt okoz egy felhasználónak vagy egy ráépülő rendszernek, és ebből a válaszból adódik a TTL. Egy élő mérkőzés állása és egy archivált cikk nagyon eltérő mértékű elavultságot visel el. Ha csak a lejáratra hagyatkozik, a TTL leteltéig elavult adatot szolgál ki. Az olyan adatoknál, amelyeket a saját alkalmazása módosít, az írás véglegesítése után törölje vagy írja felül a kulcsot, ideális esetben a tranzakció után kibocsátott eseményből, így a gyorsítótárban soha nem marad olyan adat, amelyet az adatbázis visszagörgetett. Adjon a TTL-ekhez kis véletlenszerű eltolást (jittert), hogy az egyszerre írt kulcsok ne ugyanabban a pillanatban járjanak le. - Néhány másodperces rövid TTL a gyorsan változó adatokhoz, ahol az enyhe elavultság elfogadható - Hosszabb TTL és íráskori invalidálás az Ön által kezelt, ritkán változó adatokhoz - Verziózott kulcsok, ahol a verziószám növelése egyszerre egy egész kulcscsoportot invalidál ## Védje az adatbázist a cache stampede ellen Cache stampede akkor következik be, amikor egy népszerű kulcs lejár, és sok egyidejű kérés egyszerre nem találja a gyorsítótárban, így mind ugyanazt a drága lekérdezést küldi az adatbázisnak. Egy nagy forgalmú API-nál ez éppen a forgalmi csúcs pillanatában terhelheti túl az adatbázist. A legforgalmasabb kulcsain kombináljon kettőt vagy többet az alábbi védekezési módok közül. - Kérésösszevonás: egyetlen kérés építi újra a kulcsot egy rövid, NX opcióval és lejárattal beállított Redis-zár alatt, a többi rövid ideig vár, vagy az előző értéket szolgálja ki - Stale-while-revalidate: az értéken belül tároljon egy puha lejárati időt, azon túl is szolgálja ki az elavult másolatot, és a háttérben frissítsen - Korai valószínűségi frissítés: egy forgalmas kulcsot időnként még lejárat előtt építsen újra, a lejárat közeledtével növekvő valószínűséggel - Előmelegítés: töltse fel az ismert forgalmas kulcsokat egy előre látható forgalmi csúcs, például egy nagy élő esemény előtt ## Az Elasticsearch-öt keresésre és listákra használja, ne általános gyorsítótárnak A Redis kulcs-érték alapú lekérdezésekre a legjobb: egyetlen objektumra, egy kiszámított részletre, egy kéréskorlátozási számlálóra. Az Elasticsearch más feladatra való: teljes szöveges keresésre, facettás szűrőkre és rendezett listákra, amelyek kiszámítása egy relációs adatbázisban drága. Az Elasticsearch-indexet kezelje az elsődleges adatbázisból, változási eseményeken vagy ütemezett szinkronizáláson keresztül táplált olvasási modellként, és fogadja el, hogy csak idővel lesz konzisztens (eventual consistency). Az írásoknál és mindennél, aminek pontosnak kell lennie, az adatbázis maradjon a mérvadó. A havonta 50M+ felhasználót kiszolgáló NorthStar Network sportmédia-platformon mérnökeink újratervezték a kritikus API-kat és a Redisre és Elasticsearch-re épülő gyorsítótárazást, ami csökkentette a P95-ös válaszidőket. ## Tudja, mit ne gyorsítótárazzon A legdrágább gyorsítótár-hiba az, ha az egyik felhasználó adatait egy másik kapja meg. Minden gyorsítótárazott végpontnál ellenőrizze, hogy a kulcs tartalmazza-e az identitást, és kiadás előtt tesztelje két különböző fiókkal. - A hívó identitásától vagy jogosultságaitól függő válaszok, hacsak a kulcs nem tartalmazza a felhasználót vagy a szerepkört - Szigorúan konzisztens adatok, például egyenlegek, a fizetéskori készletadat vagy bármi, amit jogosultsági döntésekhez használnak - Író végpontok, egyszer használatos tokenek és minden, aminek mellékhatása van - Kis forgalmú végpontok, ahol a gyorsítótár csekély haszonért növeli a bonyolultságot, és új hibalehetőséget teremt - Nagyon nagy válaszok, amelyek sok kisebb, gyakrabban használt kulcsot szorítanak ki ## Legyen a gyorsítótár megfigyelhető, különben nem bízhat benne Kövesse kulcselőtagonként a találati arányt, a Redis memóriahasználatát és kiszorításait, a Redis-parancsok késleltetését és az adatbázis terhelését, ugyanazon a dashboardon, mint az API P95-ös értékét. Ha a P95 elmozdul, perceken belül meg kell tudnia mondani, hogy a gyorsítótár, az adatbázis vagy egy általa hívott szolgáltatás okozta. Riasszon, ha a találati arány hirtelen esik, ami gyakran azt jelenti, hogy egy telepítés megváltoztatta a kulcsformátumot, és ha nőnek a kiszorítások, ami azt jelzi, hogy a gyorsítótár túl kicsi a munkakészletéhez. Az API-teljesítménnyel kapcsolatos munkát jól körülhatárolt blokként vállaljuk: mérés, a gyorsítótár-réteg újratervezése, majd a dashboardok és az üzemeltetési kézikönyvek (runbookok) átadása az üzemeltető csapatnak. ## A legfontosabbak - Mérje végpontonként a P95-öt, és a lekérdezési problémákat javítsa ki, mielőtt gyorsítótárat vezet be. - A Redisre épülő cache-aside a legbiztonságosabb alapértelmezés, mert az adatbázis marad az igazság forrása. - A TTL-t aszerint állítsa be, mennyire lehet elavult az adat, és az Ön által kezelt adatoknál íráskor invalidáljon. - A forgalmas kulcsokat zárolással, stale-while-revalidate módszerrel vagy előmelegítéssel védje a stampede ellen. - Az Elasticsearch-öt idővel konzisztens olvasási modellként használja keresésre és listákra, ne általános gyorsítótárként. ## GYIK ### Redis vagy Elasticsearch az API-válaszok gyorsítótárazására? A Redist objektumok, kiszámított részletek és számlálók kulcs-érték alapú gyorsítótárazására használja, mert a kulcs szerinti keresés gyors, és egyszerű invalidálni. Az Elasticsearch-öt akkor válassza, ha a drága rész a keresés, a szűrés vagy a rendezés sok rekordon, és az indexét olvasási modellként kezelje, ne gyorsítótárként. ### Mennyi a jó TTL az API-válaszokhoz? Nincs univerzális érték. Minden TTL-t aszerint állítson be, mennyire lehet elavult az adott adat anélkül, hogy kárt okozna egy felhasználónak; a gyorsan változó adatokhoz néhány másodperc elég, a hosszabb TTL-eket pedig párosítsa íráskori invalidálással. Adjon hozzá véletlenszerű eltolást, hogy az összetartozó kulcsok ne egyszerre járjanak le. ### Hogyan előzhető meg a cache stampede Redisben? Egy lejárt kulcsot csak egyetlen kérés építsen újra, egy SET paranccsal és NX opcióval felvett rövid zár alatt, a többi kérés pedig rövid ideig várjon, vagy az előző értéket szolgálja ki. A stale-while-revalidate és a forgalmas kulcsok korai frissítése eleve csökkenti a kemény lejáratok számát. ## Kapcsolódó szolgáltatások - [Egyedi szoftver](https://sdk.enterprises/hu/services/product-engineering)