Spring GDS 25è Aniversari
Una empresa de logística que envia a 190 països va construir alguna cosa per enviar-se a si mateixa.
El caching consisteix a desar el resultat d'una feina costosa perquè la petició següent el reutilitzi en lloc de refer-lo. Una consulta a base de dades que triga 200 mil·lisegons corre una vegada, la resposta es desa en algun lloc ràpid, i les següents mil peticions la llegeixen en menys d'un mil·lisegon. La feina passa una vegada i rendeix moltes.
Les memòries cau viuen en cada capa d'un sistema. El navegador cacheja recursos perquè una visita repetida carregui a l'instant. Una CDN cacheja pàgines i fitxers a prop de l'usuari. Un magatzem en memòria com Redis cacheja resultats de consultes i sessions. La base de dades cacheja les seves pròpies pàgines calentes. Cada capa respon a la mateixa pregunta: puc evitar tornar a fer aquesta feina? La part famosament difícil és la invalidació. Una memòria cau guarda una còpia, i en el moment en què la dada real canvia, aquesta còpia és una mentida fins que alguna cosa la neteja. Cacheja massa temps i els usuaris veuen informació obsoleta. Cacheja massa poc i perds el benefici. La portada d'un diari cacheja la seva llista d'articles durant trenta segons, així que un milió de lectors en aquesta finestra donen tots a la memòria cau mentre la pàgina segueix gairebé en directe.
Les estratègies habituals inclouen l'expiració per temps, la invalidació per esdeveniment quan la dada canvia i la revalidació per tags que neteja les entrades relacionades alhora.
El caching sol ser la millora de rendiment més barata i gran disponible, i el lloc on s'amaguen els bugs més lletjos. Un preu obsolet, un usuari amb sessió iniciada a qui se serveix la pàgina cachejada d'un altre, un dashboard mostrant els números d'ahir. Per això dissenyem la història de la invalidació abans d'afegir la memòria cau, no després que un client reporti el bug. Aquest pensament per avançat és la diferència entre un caching que ajuda i un que corromp en silenci la confiança en la dada.
Afinem el caching per capa i per ruta, perquè la resposta correcta per a una pàgina de màrqueting és l'equivocada per a un saldo de compte en directe. La invalidació per esdeveniment i per tags manté honest el contingut cachejat quan la dada subjacent es mou. És una part recurrent de les nostres proves i monitoratge de rendiment, i travessa el nostre desenvolupament web i d'aplicacions web a mida sempre que un sistema té rutes calentes que val la pena accelerar.
Pàgines lentes sota càrrega, o et preocupa que una memòria cau serveixi dades obsoletes? Afinem la teva estratègia de caching.
Una empresa de logística que envia a 190 països va construir alguna cosa per enviar-se a si mateixa.
Convertir una marca en un negoci que funciona.
Mig milió de persones. Una app. Zero caos.















