Strategije keširanja: Redis, Memcached i CDN

Strategije keširanja odlučuju koji se odgovori izračunaju jednom i ponovo koriste, a koji uvijek moraju doći do baze. Stranica proizvoda, provjera dozvole ili cijeli HTML dokument koji se gradi na svaki zahtjev troše server i usporavaju sajt baš kada stigne saobraćaj. Posljedica je timeout na checkoutu, baza na punom procesoru i račun za hosting koji raste sa posjetiocima, a ne sa stvarnim poslom.

Sadržaj

U CodeWizu keširanje dizajniramo duž cijelog puta: Redis ili Memcached pored aplikacije, keš unutar Laravela, Node.js-a i WordPressa, HTTP keš kao što su Varnish ili Nginx, i CDN ispred svega. Jednako nam je stalo do invalidacije kao i do pogotka. Brza stranica koja pokazuje jučerašnju cijenu nije dobitak.

Usluga je za prodavnice i sadržajne sajtove koji usporavaju pod opterećenjem, za API-je koji ponavljaju iste teške upite i za timove koji su keš već dodali, a sada ne mogu objasniti zašto servira zastarjele ili tuđe podatke. Ako je sajt brz i baza miruje, reći ćemo da još jedan sloj ne vrijedi složenosti.

Redis: Laptop sa analitičkim dashboardom, grafikonima i ključnim metrikama

Strategije keširanja u Redisu za vruće podatke, sesije i lockove

Redis je skladište u memoriji sa bogatim tipovima podataka, čitanjem ispod milisekunde i jasnom kontrolom izbacivanja. To je podrazumijevani dijeljeni keš kada više servera aplikacije mora vidjeti iste vrijednosti: izrenderovane fragmente, rezultate upita, brojače za rate limiting, distribuirane lockove i sesije. Te poslove držimo odvojeno. Keš smije zaboraviti ključ. Sesija ili red poruka ne smiju.

Cache-aside. Aplikacija prvo čita Redis i puni ključ kada ga nema, sa TTL-om koji odgovara tome koliko podaci smiju biti stari. Pisanje briše ili ažurira ključ u istom zahtjevu koji mijenja bazu.
Odvojene instance ili baze. Keš koristi allkeys-lru ili volatile-lru i granicu memorije. Sesije, lockovi i redovi koriste noeviction, tako da Redis odbije upis umjesto da obriše prijavu.
Kontrola stampede efekta. Kada popularan ključ istekne, jedan worker ga preračuna, a ostali čekaju ili serviraju malo stariju vrijednost. Inače stotinu istih upita odjednom pogodi PostgreSQL ili MySQL.
Bez perzistencije za čisti keš. Snapshoti i AOF usporavaju keš koji smije krenuti prazan. Uključujemo ih samo za podatke koji moraju preživjeti restart.

Politika izbacivanja i granice memorije opisani su u Redis referenci za eviction i u serverskim bilješkama o optimizaciji memorije. Ključeve, TTL-ove i podjelu instanci dokumentujemo u repozitorijumu, da sljedeći programer ne pogađa.

Postavljanje Memcacheda za jednostavan dijeljeni keš

Memcached je manja ideja urađena kako treba: višenitni key-value keš, bez perzistencije, bez bogatih tipova, sa consistent hashingom preko čvorova. Odgovara kada je jedina operacija „sačuvaj ovaj blob, vrati ga, pusti da istekne”. Magento i neki stariji PHP stackovi već govore Memcached, i zamjena Redisom prvog dana nije uvijek taj projekat.

Kada ga biramo, a kada ne

Memcached biramo za dijeljene fragmente i rezultate upita na nizu servera aplikacije kojima trebaju samo get i set.
Ostajemo na Redisu kada trebaju i lockovi, liste, pub/sub, rate limiting ili podaci koji se ne smiju izbaciti.
Veličinu slaba i limit stavke biramo tako da nekoliko velikih stranica ne istisne hiljade malih ključeva.
Memcached stoji na privatnoj mreži, sa autentifikacijom gdje je verzija podržava, nikada na javnom portu.

Naše postavljanje Memcacheda uključuje konfiguraciju klijenta u aplikaciji, budžet memorije, health checkove i ista pravila invalidacije koja bismo napisali za Redis. Protokol je jednostavniji. Greške, posebno keširanje personalizovane stranice pod zajedničkim ključem, iste su.

Strategije keširanja u aplikaciji: Laravel, Node.js i WordPress

Keširanje u aplikaciji je sloj koji kod kontroliše. Čuva objekte, rezultate upita i HTML fragmente pod ključevima koje programeri imenuju. Pravo je mjesto za „ovo stablo kategorija je skupo i mijenja se nekoliko puta dnevno”, a pogrešno za „cijela HTML stranica, uključujući ime prijavljenog korisnika”.

Laptop sa otvorenim kodom aplikacije na stolu pod blagim dnevnim svjetlom

U Laravelu koristimo cache store (Redis u produkciji, array ili fajl samo u lokalnim testovima), Cache::remember za čitanje i eksplicitni forget ili tagove kada se model sačuva. U WordPressu postavljamo trajni object-cache drop-in da opcije, objave i rezultati upita prestanu udarati MySQL na svaki zahtjev, a keš cijele stranice i dalje držimo na HTTP sloju za anonimni saobraćaj. U Node.js-u isti cache-aside obrazac stoji u malom modulu, zajedničkom za API i workere, sa jednom funkcijom koja zna format ključa.

$product = Cache::remember("product:{$id}", 300, function () use ($id) {
    return Product::with('category')->findOrFail($id);
});

// called from the model observer when the product is saved
Cache::forget("product:{$id}");

Ključevi uključuju svaku dimenziju koja mijenja vrijednost: id, jezik, valutu, tenanta. Dimenzija koja nedostaje je način da jedan posjetilac vidi tuđu cijenu.
Keš u procesu (APCu, Node Map) je dodatno brz i nevidljiv ostalim serverima. Koristimo ga za sitne, rijetko mijenjane lookupove, ne kao jedini keš na deployu sa više servera.
Keš frameworka ne zamjenjuje HTTP keširanje. Object cache i dalje pokreće PHP ili Node na svaki pogodak. Keš cijele stranice može aplikaciju potpuno preskočiti.

CDN optimizacija i pravila keša na edgeu

CDN čuva odgovore blizu posjetioca. Za prodavnicu ili izdavača čiji su čitaoci van grada u kojem stoji origin, taj put je često najveći dio čekanja. CDN optimizacija nije „uključi keširanje”. To je skup pravila šta se smije sačuvati, koliko dugo i kako objava ili promjena zalihe to uklanja.

Statički fajlovi imaju dug vijek i imena sa verzijom, pa deploy ne čeka purge.
HTML se kešira samo kada je anoniman. Kolačić ili Authorization header zaobilazi edge, osim ako smo namjerno složili cache key koji isključuje sesiju.
Parametri za praćenje kampanja skidaju se iz cache keya, inače je svaki link kampanje promašaj.
Purge po URL-u ili po tagu kada se sadržaj promijeni, uz rezervni TTL da propušten purge ipak istekne.
Pravila keša žive u repozitorijumu ili u izvezenoj konfiguraciji, a ne samo u dashboardu koji je neko jednom uredio.

Ovo obično radimo na Cloudflareu. Cloudflare dokumentacija za keš referenca je za cache key, pravila i purge. Kako se ta pravila uklapaju u brz origin tema je naših tekstova o Cloudflare konfiguraciji za performanse i o jakim Core Web Vitals rezultatima. Googleova preporuka je LCP ispod 2.5 sekunde; keširanje anonimnog HTML-a i fajlova na edgeu jedan je od pouzdanih načina da se do tog cilja stigne.

Izbliza prikazan globus sa jugoistočnom Azijom i linijom ekvatora

Invalidacija, HTTP keširanje i stampede

Težak dio svakog keša je znati kada sačuvana vrijednost više nije tačna. Sam TTL znači da cijena može biti pogrešna dok tajmer ne istekne. Samo brisanje pri upisu pada kada drugi sistem izmijeni red, ili kada CDN i dalje drži HTML. Kombinujemo oba pristupa i imenujemo vlasnika svakog ključa.

TTL kao osigurač. Čak i ključevi koje brišemo pri upisu dobiju vijek trajanja, da propušten događaj ne zakači zastarjelu vrijednost zauzvijek.
Tagovi i verzionisani prefiksi. „Sve stranice proizvoda za tenanta 18” mogu se odbaciti bez nabrajanja svakog URL-a. Podizanje prefiksa napušta cijelu generaciju ključeva.
HTTP validatori. Cache-Control, ETag i stale-while-revalidate daju browseru i CDN-u da osvježe sadržaj bez navale istih upita.
Varnish ili Nginx ispred origina za sajtove na kojima pogodak cijele stranice nikada ne smije pokrenuti PHP. Odvojeno smo pisali o Varnishu kao HTTP kešu u toj ulozi. PURGE i banovi prate iste događaje koji brišu Redis ključeve.

Koji sloj šta treba da kešira

Većini sporih aplikacija trebaju dva sloja, ne pet. Ove strategije keširanja namjerno ostaju male. Biramo sa ove mape i ostalo preskačemo dok mjerenje ne kaže drugačije.

Sloj	Tipičan alat	Čuva	Ističe po	Najbolje za
Browser	Cache-Control	Fajlovi, poneki HTML	max-age, imena sa verzijom	Statičke fajlove, ponovne posjete
CDN	Cloudflare	Fajlovi, anonimni HTML, poneki API	TTL, purge po URL-u ili tagu	Posjetioce daleko od origina
HTTP keš	Varnish, Nginx	Cijele odgovore	TTL, PURGE, banovi	Prometne stranice koje mogu preskočiti aplikaciju
Aplikacija	Laravel, WordPress, Node.js	Objekte, fragmente, rezultate upita	TTL, ključevi, tagovi	Skup posao koji se ponavlja kroz zahtjeve
Dijeljeni keš	Redis, Memcached	Objekte, sesije, lockove, brojače	TTL plus eksplicitno brisanje	Više servera aplikacije, jedna zajednička istina

Koristan cilj je visok hit ratio na ključevima koji su skupi, manje upita po stranici i stabilno vrijeme do prvog bajta. To čitamo iz statistike keša, slow loga baze i browsera, a ne iz utiska da „izgleda brže”.

Najčešće greške u keširanju koje ispravljamo

Jedan cache key za stranicu koja sadrži ime prijavljenog korisnika, korpu ili cjenovnik.
Redis bez maxmemory politike, pa ili padne kada se RAM napuni ili izbaci sesije zajedno sa kešom.
Nema TTL-a i nema brisanja pri upisu, pa cijena ili stanje zalihe žive dok neko ne restartuje proces.
Keširanje odgovora sa greškom i 404 stranica, pa se serviraju dugo nakon što se origin oporavio.
Lokalni keš u procesu na više servera, svaki sa drugom verzijom istog objekta.
CDN cache key koji uključuje svaki query parametar, pa analitičke oznake svaki URL pretvore u promašaj.

Šta utiče na cijenu projekta keširanja

Redis i Memcached su open source. Cijena je dizajn i pažnja oko invalidacije, a ne licenca. Procjenu dajemo nakon pogleda na saobraćaj, najteže upite i način na koji se sadržaj objavljuje:

Koliko slojeva zaista nedostaje. Sam object cache manji je posao od object cachea plus Varnish plus CDN pravila.
Jesu li stranice anonimne i pogodne za keš, ili personalizovane na svakom prikazu.
Koliko puteva u kodu piše podatke. Jedan admin ekran je jednostavan. Pet integracija koje pišu zalihu nije.
Memorija i broj čvorova kada radni skup više ne stane u jednu malu instancu.
Jednokratno postavljanje ili da ključeve, TTL-ove i purge pravila držimo usklađenim sa kasnijim izmjenama.

Kako radimo

Analiza: mjerimo spore zahtjeve, broj upita, response headere i keš koji je već na mjestu.
Plan: biramo slojeve, ključeve, TTL-ove i događaje koji ih invalidiraju, a slojeve koji vam ne trebaju preskačemo.
Izrada: dodajemo Redis ili Memcached, pozive u aplikaciji, HTTP ili CDN pravila i dashboarde za hit ratio i memoriju.
Testiranje: provjeravamo promašaj, pogodak, purge nakon izmjene i prijavljenu stranicu koja se ne smije dijeliti.
Puštanje u rad: keširanje uključujemo u koracima, pratimo saobraćaj prema originu i greške, i držimo brz način da se loše pravilo zaobiđe.
Podrška: dokumentujemo šemu ključeva i po želji pregledamo nove izmjene da invalidiraju ono što mijenjaju.

Zašto CodeWiz

Gradimo i aplikacije: keš u Laravelu, WordPressu, WooCommerceu i Node.js-u dizajnira se uz kod koji piše podatke.
Open-source na prvom mjestu: Redis, Memcached, Varnish i Nginx, uz Cloudflare na edgeu kada je globalni keš pravi alat.
Manje slojeva: ako su plugin i podešena baza dovoljni, nećemo vam prodati keš u tri nivoa.
Fer cijene: vrhunski razvoj bez vrhunskih cijena, iz Banje Luke, uz rad na daljinu sa klijentima iz regiona i svijeta.
Performanse na jednom mjestu: upiti prema bazi, keširanje i CDN jedan su plan. Više o CodeWizu.

Često postavljana pitanja

Koliko košta projekat keširanja?

Dodavanje Redisa i nekoliko cache-aside poziva oko najsporijih upita mali je angažman. Keš cijele stranice, CDN pravila i invalidacija u prodavnici sa personalizovanim cijenama veći su posao. Procjenu dobijate nakon što vidimo saobraćaj i puteve u kodu koji pišu podatke.

Da li uzeti Redis ili Memcached?

Redis, osim ako već koristite Memcached i trebaju vam samo jednostavni get i set. Redis pokriva keš, lockove, brojače i redove, sa politikom izbacivanja koju možemo postaviti po instanci. Memcached ostaje kada stack već zavisi od njega, a dodatni tipovi se ne koriste.

Hoće li keš pokazati zastarjele cijene ili tuđe stranice?

Hoće samo ako su invalidacija i cache key pogrešni. Brišemo ili radimo purge pri upisu, TTL držimo kao osigurač i odbijamo da odgovor koji zavisi od prijavljenog korisnika sačuvamo pod zajedničkim ključem. Ti slučajevi su dio testa prije puštanja u rad.

Trebaju li mi Redis, Varnish i CDN zajedno?

Ne po pravilu. CDN uz razumne browser headere rješava dobar dio kašnjenja fajlova i anonimnih stranica. Redis rješava ponovljen posao unutar aplikacije. Varnish zaslužuje mjesto kada origin i dalje renderuje isti javni HTML hiljadama puta. Sloj dodajemo kada mjerenja pokažu prazninu, a ne zato što dijagram izgleda potpun.

Možete li dodati keširanje bez prepisivanja aplikacije?

Često možemo. HTTP keš i CDN stoje ispred neizmijenjene aplikacije, a WordPress object-cache drop-in ne traži novu poslovnu logiku. Najveći dobici unutar koda i dalje su nekoliko promišljenih cache-aside poziva, koje možemo dodati bez redizajna.

Kako znate da keš radi?

Hit ratio na skupim ključevima, manje upita po stranici, manji saobraćaj prema originu na CDN-u i vrijeme do prvog bajta koje ostaje mirno tokom skoka. Testiramo i negativno: nakon izmjene stare vrijednosti nema, a prijavljeni odgovor se ne koristi ponovo za nekog drugog.

Ubrzajte spore stranice namjerno

Recite nam koje stranice ili endpointi bole i šta već keširate. Predlažemo strategije keširanja koje odgovaraju saobraćaju, sa jasnim pravilom kada se svaka vrijednost baca. Kontaktirajte nas da prođemo kroz to, ili pogledajte naše usluge strategija keširanja.

Strategije keširanja: Redis, Memcached i CDN