Strategia di cache con Redis: chiavi, TTL, invalidazione e stampede
Decidi cosa mettere in cache su Redis e come: pattern per tipo di dato, nomi delle chiavi, TTL con jitter, invalidazione, protezione dallo stampede, policy di memoria e codice d’esempio. Pensato per ChatGPT, Claude, Gemini e Microsoft Copilot. Include 4 variabili personalizzabili e puoi copiarlo gratuitamente con un clic.
Avanzato · Codice · In attesa di revisione editoriale
Prompt
Agisci come architetto backend specializzato in prestazioni e caching con Redis.
Contesto:
- Applicazione e stack: {{applicazione}}
- Dati candidati alla cache e loro schema di lettura e scrittura: {{dati}}
- Tolleranza ai dati non aggiornati: {{tolleranza}}
- Problema attuale: {{problema}}
Consegna:
1. Cosa mettere in cache e cosa no: una tabella con ogni dato, rapporto letture/scritture stimato (o [DA COMPLETARE] se non lo conosco), costo del ricalcolo e decisione.
2. Il pattern per ogni dato (cache-aside, read-through, write-through o write-behind) e il perché.
3. Schema delle chiavi: convenzione dei nomi, prefisso di versione per invalidare in blocco e come evitare una crescita illimitata delle chiavi.
4. TTL per tipo di dato, con jitter perché non scadano tutte insieme.
5. Invalidazione: quali eventi cancellano o aggiornano ogni chiave, come evitare race condition tra scrittura su database e su cache e cosa succede se l’invalidazione fallisce.
6. Protezione dal cache stampede: lock con `SET NX` e scadenza, refresh anticipato probabilistico o servire il dato scaduto durante il ricalcolo.
7. Configurazione di Redis: `maxmemory`, politica di eviction adatta, serializzazione e dimensione massima dei valori.
8. Comportamento se Redis non risponde: timeout brevi, fallback sul database e protezione del database dal sovraccarico.
9. Metriche da misurare (hit rate, latenza, eviction, memoria) e un piano di rilascio graduale.
10. Codice d’esempio nel mio stack per il caso principale, con la protezione dallo stampede inclusa.
Vincoli:
- Non dare cifre di miglioramento inventate; spiega come misurarle prima e dopo.
- Se mancano informazioni su volumi o consistenza, chiedimele prima di consigliare.
- Segnala i dati che non vanno mai messi in cache in modo condiviso (per esempio i dati personali di un altro utente).Come usarlo
- Elenca gli endpoint o le query più lenti o più chiamati e ogni quanto cambiano i loro dati.
- Indica per quanto tempo ogni dato può essere non aggiornato senza creare problemi.
- Introduci la cache su un solo caso, misura l’hit rate e poi estendi.
Esempio d'uso
App: negozio Laravel su PHP 8.3 · Dati: catalogo (cambia poche volte al giorno) e magazzino (cambia ogni minuto) · Problema: la pagina categoria impiega 1,8 s nei picchi.
Esempio di risultato
1. Cosa mettere in cache
| Dato | Lettura/scrittura | Decisione |
|---|---|---|
| Catalogo per categoria | Altissima / poche al giorno | Cache-aside, TTL ~10 min |
| Giacenze | Alta / ogni minuto | TTL 30 s o lettura da MySQL |
| Carrello | Per utente | Chiave per utente, mai condivisa |
| Prezzo al checkout | — | Niente cache: sempre da MySQL |
10. Codice: catalogo con protezione dallo stampede
public function prodottiDellaCategoria(int $categoriaId): array
{
$versione = Cache::get('catalogo:versione', 1); // incrementarla invalida tutto il catalogo
$chiave = "v{$versione}:categoria:{$categoriaId}:prodotti";
$ttl = 600 - random_int(0, 60); // jitter per non far scadere tutto insieme
if (($inCache = Cache::get($chiave)) !== null) {
return $inCache;
}
// Un solo processo ricalcola; gli altri attendono fino a 3 s
return Cache::lock("lock:{$chiave}", 10)->block(3, fn () =>
Cache::remember($chiave, $ttl, fn () => Product::query()
->where('category_id', $categoriaId)
->where('active', true)
->get(['id', 'name', 'slug', 'image'])
->toArray())
);
}
Se block() lancia LockTimeoutException, servi l’ultima copia o interroga MySQL con un limite di concorrenza. Misura hit rate e latenza p95 della pagina prima e dopo il rilascio…
Dati chiave
- Categoria
- Programmazione e sviluppo · Architettura software
- Tipo di output
- Codice
- Livello
- Avanzato
- Pensato per
- ChatGPT, Claude, Gemini e Microsoft Copilot
- Verificato in
- In attesa di verifica editoriale
- Variabili
- Applicazione e stack, Dati e schema di accesso, Tolleranza ai dati vecchi e Problema attuale
- Lingua
- Italiano
- Prezzo
- Gratuito, senza registrazione
- Aggiornato
- 07/11/2026
Domande frequenti
Che cos’è un cache stampede?
Quando una chiave molto usata scade, centinaia di richieste provano a ricalcolarla insieme e sovraccaricano il database. Si evita con un lock perché una sola la rigeneri, o rinfrescandola prima della scadenza.
Perché aggiungere jitter al TTL?
Chiavi create insieme con lo stesso TTL scadono insieme e causano un picco di carico. Un piccolo scarto casuale distribuisce le scadenze.
Quale politica di eviction scelgo in Redis?
Se Redis fa solo da cache, di solito vanno bene allkeys-lru o allkeys-lfu. Se condivide l’istanza con dati da non perdere, come le code, spostali su un’istanza separata.
A cosa serve questo prompt?
Decidi cosa mettere in cache su Redis e come: pattern per tipo di dato, nomi delle chiavi, TTL con jitter, invalidazione, protezione dallo stampede, policy di memoria e codice d’esempio.
Con quali strumenti di IA funziona?
È pensato per ChatGPT, Claude, Gemini e Microsoft Copilot. Non lo abbiamo ancora verificato in questi strumenti, quindi i risultati possono variare da uno all'altro.
Come personalizzo il prompt?
Clicca su «Personalizza» e compila le variabili (Applicazione e stack, Dati e schema di accesso, Tolleranza ai dati vecchi e Problema attuale). Il testo si aggiorna all'istante e poi puoi copiarlo con un clic. I valori vengono salvati solo nel tuo browser.
Serve esperienza per usarlo?
È di livello avanzato: è pensato per persone con esperienza nell'argomento, in grado di valutare e regolare il risultato.
Questo prompt è gratuito?
Sì. Tutti i prompt di HomeCasa Prompts sono gratuiti, senza registrazione né abbonamento. Puoi usarli anche in progetti professionali.
Posso fidarmi dell'output dell'IA?
Consideralo una bozza di alta qualità: verifica sempre dati, cifre e affermazioni importanti prima di pubblicare o prendere decisioni.