Le notifiche di keyspace permettono ai client di sottoscriversi (tramite Pub/Sub) a eventi relativi a modifiche alle chiavi — ad esempio quando una chiave viene impostata, eliminata o scade. Abilitano la reazione a cambiamenti di dati in Redis, con l'evento di scadenza che è un trigger particolarmente comune e utile.
CONFIG SET notify-keyspace-events KEA
PSUBSCRIBE
PSUBSCRIBE
Abiliti le notifiche (notify-keyspace-events, scegliendo quali eventi) e ti sottoscrivi a canali speciali: __keyevent@<db>__:<event> (eventi di un tipo, ad esempio expired, con la chiave interessata) oppure __keyspace@<db>__:<key> (eventi su una chiave specifica).
The "expired" event is widely used as a TIMER/SCHEDULER:
→ set a key with a TTL; when it expires, you get notified → trigger an action
→ e.g. "order:123:hold" expires in 15 min → notification → release the held inventory
→ delayed jobs, session-expiry handling, scheduled actions without a separate scheduler
⚠️ Built on PUB/SUB → fire-and-forget: if no subscriber is connected when the event
fires, it's MISSED (not reliable/persistent). Don't rely on it for critical events.
⚠️ "expired" fires when the key is actually REMOVED (lazy/active expiration), which can
LAG behind the exact TTL time → not precise timing.
⚠️ Has overhead at high volume; for reliable event handling, use STREAMS instead.
Comprendere le notifiche di keyspace è una conoscenza utile per reagire a cambiamenti di dati in Redis, una capacità che abilita certi pattern event-driven — anche se comprendere i limiti è altrettanto importante.
La funzionalità permette ai client di sottoscriversi a eventi su modifiche di chiavi (impostazioni, eliminazioni e soprattutto scadenze) tramite Pub/Sub, abilitando Redis a notificare l'applicazione quando i dati cambiano.
L'evento di scadenza in particolare alimenta un pattern comune ed elegante: usare il TTL di una chiave come timer/scheduler — imposta una chiave a scadere dopo un certo ritardo, e la notifica di scadenza innesca un'azione (rilasciare l'inventario trattenuto dopo un periodo di attesa, gestire la scadenza della sessione, eseguire job ritardati), fornendo un comportamento di azione programmata senza un sistema di scheduling separato.
Capire come abilitare le notifiche (notify-keyspace-events) e sottoscriversi ai canali speciali keyevent/keyspace è il meccanismo pratico.
Criticamente, comprendere le avvertenze è essenziale per usare questa funzionalità correttamente: poiché è costruita su Pub/Sub, è fire-and-forget (gli eventi senza subscriber connesso sono permanentemente persi — quindi non è affidabile per eventi critici), l'evento expired ha un ritardo rispetto al TTL esatto (si attiva quando la chiave viene effettivamente rimossa dall'espirazione lazy/active, quindi il timing non è preciso), e ha overhead ad alto volume — il che significa che per la gestione affidabile degli eventi, Streams o un altro meccanismo è migliore.
Questa consapevolezza previene l'affidarsi eccessivamente alle notifiche per la consegna garantita.
Poiché reagire ai cambiamenti di dati Redis (soprattutto le scadenze come timer) è un pattern utile per azioni ritardate e scheduling, e poiché le notifiche di keyspace lo forniscono ma con importanti limitazioni di affidabilità e timing (ereditando la natura fire-and-forget di Pub/Sub), comprendere le notifiche di keyspace — cosa sono, il pattern di scadenza-come-timer, e soprattutto le avvertenze — è una conoscenza preziosa e praticamente rilevante per usare questa funzionalità in modo appropriato sapendo quando i suoi limiti richiedono un approccio più affidabile.