L'invalidazione della cache in PHP non consiste nello scegliere un TTL e memorizzare risposte in Redis. È una decisione di consistenza: determinare quali informazioni possono subire ritardi, per quanto tempo e cosa deve accadere quando cambia il dato originale. Una cache progettata male può mostrare un prezzo precedente, concedere accesso con permessi revocati o presentare una disponibilità che non esiste più. Una cache troppo conservativa, invece, trasferisce tutto il carico al database e perde il suo scopo.
Il punto di partenza è trattare ogni voce come un dato con proprietario, ciclo di vita e rischio definiti. Ciò consente a prodotto, business e tecnologia di concordare quando una lettura potenzialmente obsoleta è accettabile e quando deve essere ottenuto lo stato attuale dalla fonte di verità.
Classificate i dati prima di metterli in cache
Non tutti i dati frequenti devono essere messi in cache né tutti ammettono lo stesso meccanismo. Valutate ogni lettura secondo quattro criteri: volatilità, impatto dell'obsolescenza, costo di consultazione dell'origine e tolleranza a un guasto della cache.
- Bassa volatilità e basso impatto: cataloghi pubblici, metadati o configurazioni non sensibili ammettono di solito TTL di minuti o ore, in base al loro processo di modifica.
- Volatilità media: schede prodotto, aggregati delle dashboard e risultati di ricerca possono essere messi in cache se vengono invalidati al variare dei record che li compongono.
- Alto impatto: permessi, saldi, limiti, stati transazionali, inventario durante la conferma d'acquisto e controlli di autorizzazione richiedono una fonte di verità coerente o una strategia esplicita di freschezza molto rigorosa.
- Dati costosi da calcolare: report e riepiloghi derivati possono giustificare la cache anche se non vengono consultati spesso, ma devono dichiarare quali entità li invalidano.
È utile separare la cache di presentazione dalla cache decisionale. Mostrare per alcuni secondi il nome precedente di una categoria può essere accettabile. Usare una policy precedente per autorizzare un'operazione normalmente non lo è. Per decisioni critiche, consultate l'origine autorevole o memorizzate versioni che possano essere verificate prima di agire.
Definite proprietà, chiavi e contratti di freschezza
Ogni voce necessita di una scheda operativa. Deve indicare la fonte di verità, la chiave, i consumer, il TTL massimo, l'evento di invalidazione, il comportamento se Redis non è disponibile e il responsabile funzionale o tecnico. Senza questo contratto, le chiavi si moltiplicano e nessuno sa cosa eliminare dopo una modifica.
Usate chiavi prevedibili e con un ambito sufficiente. Per esempio, product:42 rappresenta un'entità specifica; tenant:8:product:42 evita di mescolare dati tra organizzazioni; e dashboard:tenant:8:period:current identifica un risultato derivato. Non includete dati segreti nelle chiavi né usate serializzazioni instabili come identità.
È inoltre opportuno mantenere un formato del valore uniforme: payload, versione o data di generazione e, quando rilevante, un indicatore di freschezza. Un consumer non dovrebbe presumere che una risposta in cache equivalga a una lettura transazionalmente coerente.
final class ProductCacheKey
{
public static function detail(int $tenantId, int $productId): string
{
return "tenant:{$tenantId}:product:{$productId}:v1";
}
}Il suffisso dello schema consente di modificare la struttura del valore senza dover individuare ed eliminare tutte le voci storiche. Non sostituisce l'invalidazione del dato di business, ma riduce i rischi durante un'evoluzione del formato.
Scegliete il pattern di aggiornamento in base al tipo di lettura
Cache-aside per letture riutilizzabili
Con cache-aside, l'applicazione cerca prima la chiave; in caso di assenza, consulta il database, costruisce il valore e lo salva con TTL. È semplice e adatto a letture relativamente stabili. Il suo limite è chiaro: dopo una scrittura, qualcuno deve eliminare o sostituire le voci interessate.
L'invalidazione deve avvenire dopo la conferma della transazione. Eliminare prima del commit può far sì che un altro processo ricostruisca la cache con il valore ancora precedente. Se l'applicazione pubblica eventi, un pattern outbox aiuta a registrare la modifica nella stessa transazione e a consegnare successivamente l'ordine di invalidazione in modo affidabile.
Aggiornamento esplicito e versionamento
Se un'entità viene letta molto frequentemente e le sue modifiche sono controllate, la voce può essere aggiornata dopo la conferma della scrittura. In questo modo si evita il successivo cache miss. Tuttavia, il processo deve generare esattamente la stessa rappresentazione attesa dai lettori; in caso contrario, invalidare e ricostruire è solitamente meno rischioso.
Il versionamento delle chiavi è utile per dipendenze ampie. Invece di eliminare tutte le liste di prodotti di un'organizzazione, si incrementa tenant:8:products:version e le liste incorporano quel numero nella loro chiave. Le liste precedenti scadono da sole. Questo approccio riduce le eliminazioni massive, ma richiede di controllare la crescita delle chiavi e non deve essere usato per nascondere una dipendenza mal compresa.
Controllate le race condition e le dipendenze derivate
La race condition tipica avviene così: una lettura non trova il dato in cache, consulta il valore precedente; una scrittura viene confermata e invalida; la prima lettura termina e salva di nuovo il valore precedente. Per dati sensibili, combinate l'invalidazione con una versione dell'entità o un breve lock di ricostruzione. Prima di scrivere il valore calcolato, verificate che la versione consultata sia ancora quella attuale. In caso contrario, scartate il risultato e rileggete.
I lock distribuiti devono essere brevi, avere una scadenza e non trasformarsi in un unico punto di blocco. La loro funzione è ridurre le ricostruzioni simultanee, non garantire da soli la consistenza di business. Se il lock non viene acquisito, un'opzione consiste nell'attendere brevemente il valore ricostruito o consentire una lettura diretta limitata.
L'invalidazione per dipendenza richiede un inventario. Una modifica a un prodotto può influire sul suo dettaglio, su varie liste, sui risultati di ricerca, sui contatori e su una dashboard. Una modifica a un ruolo può influire sui permessi effettivi degli utenti e sui menu derivati. Modellate queste relazioni in modo esplicito:
- Invalidate l'entità diretta tramite la sua chiave.
- Invalidate o versionate le collezioni e gli aggregati che dipendono da essa.
- Ricalcolate in modo asincrono i risultati costosi se l'esperienza lo consente.
- Non confuse la pulizia di una vista con l'aggiornamento della fonte di verità.
Quando la relazione non è facilmente enumerabile, uno spazio delle versioni per organizzazione, catalogo o policy è solitamente più sicuro che tentare di individuare tutte le chiavi interessate mediante pattern di eliminazione globale.
Usate TTL, jitter e limiti per proteggere l'origine
Il TTL è una rete di sicurezza, non l'unico meccanismo di coerenza. Anche una chiave invalidata correttamente deve scadere: possono esistere errori nella consegna degli eventi, errori di deploy o voci orfane. Scegliete il TTL in base al costo dell'errore, non solo al costo della query.
Applicate un jitter casuale al TTL affinché migliaia di chiavi create contemporaneamente non scadano nello stesso momento. Inoltre, proteggete l'origine da una valanga di cache miss mediante lock di ricostruzione per chiave, limiti di concorrenza e quote per consumer. Per dati non critici, può essere servito un valore leggermente scaduto mentre un unico processo lo ricalcola; per permessi o disponibilità decisionale, questa tecnica deve essere scartata o limitata a scenari espressamente approvati.
Progettate il degrado quando Redis non funziona
Redis è una dipendenza operativa, non la fonte di verità. Se non risponde, l'applicazione necessita di una modalità di degrado definita. Per una lettura pubblica poco costosa, può consultare direttamente il database con timeout. Per query costose, è opportuno applicare la limitazione del carico, ridurre i campi, rispondere con uno stato temporaneamente non disponibile o utilizzare una replica appropriata se l'architettura la prevede.
Non trasformate un guasto della cache nell'esaurimento delle connessioni al database. Definite timeout brevi, circuit breaker, budget di query e metriche per route. Per dati critici, è preferibile rifiutare un'operazione piuttosto che prendere una decisione con permessi, saldi o inventario la cui freschezza non può essere garantita.
Testate e osservate la freschezza, non solo gli hit
Un alto tasso di hit non dimostra che la cache sia corretta. Strumentate hit, miss, latenza, errori di lettura e scrittura, TTL residuo, lock di ricostruzione, invalidazioni emesse e fallite, oltre a query e saturazione del database. Correlate questi segnali a ciascuna famiglia di chiavi e non soltanto a Redis come servizio globale.
Nei test, coprite almeno la lettura iniziale, l'aggiornamento successivo, l'eliminazione, l'invalidazione dopo il commit, il guasto della cache e le race condition tra lettore e writer. Verificate che un utente perda l'accesso dopo la revoca di un permesso, che una lista rifletta una modifica in base al suo contratto di freschezza e che un'invalidazione fallita attivi avvisi o recupero.
Checklist per un'applicazione PHP esistente
- Elencate le letture ripetute e classificatele per rischio, volatilità e costo.
- Dichiarate la fonte di verità e la massima tolleranza all'obsolescenza di ciascun dato.
- Documentate chiavi, TTL, dipendenze, consumer ed evento di invalidazione.
- Eseguite invalidazioni o aggiornamenti solo dopo il commit confermato.
- Proteggete le ricostruzioni simultanee e aggiungete jitter alle scadenze rilevanti.
- Definite la modalità degradata in caso di indisponibilità di Redis senza sovraccaricare il database.
- Misurate freschezza e invalidazioni, non solo la percentuale di hit.
- Rivedete periodicamente chiavi senza proprietario, TTL eccessivi e dipendenze non coperte.
Una strategia affidabile di invalidazione della cache in PHP rende visibili i propri compromessi: cosa può diventare obsoleto, per quale intervallo, come viene corretto e cosa accade quando un componente si guasta. Questa chiarezza è più preziosa che aggiungere una cache in modo indiscriminato.
