Keyspace notifications stellen clients in staat om zich in te schrijven (via Pub/Sub) op events over wijzigingen in keys — zoals een key die wordt ingesteld, verwijderd, of verlopen. Ze maken het mogelijk om te reageren op gegevenswijzigingen in Redis, waarbij het expiration event een bijzonder veel voorkomende, nuttige trigger is.
CONFIG SET notify-keyspace-events KEA
PSUBSCRIBE
PSUBSCRIBE
Je schakelt notifications in (notify-keyspace-events, waarbij je kiest welke events) en schrijft je in op speciale channels: __keyevent@<db>__:<event> (events van een type, bijv. expired, met de betreffende key) of __keyspace@<db>__:<key> (events op een specifieke key).
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.
Keyspace notifications begrijpen is nuttige kennis voor reageren op gegevenswijzigingen in Redis, een mogelijkheid die bepaalde event-driven patronen mogelijk maakt — maar het begrijpen van de beperkingen ervan is even belangrijk.
De functie stelt clients in staat om zich in te schrijven op events over keywijzigingen (instellingen, verwijderingen, en vooral vervaloningen) via Pub/Sub, waardoor Redis de applicatie kan melden wanneer gegevens veranderen.
Het expiration event in het bijzonder drijft een veelgebruikt, elegant patroon aan: de TTL van een key gebruiken als timer/scheduler — stel een key in om na enige vertraging te verlopen, en de expiration notification activeert een actie (vrijgeven van vastgelegde voorraad na een wachtperiode, afhandelen van sessie-expiratie, uitvoering van vertraagde jobs), wat geplande-actie-gedrag biedt zonder een apart planningsysteem.
Het begrijpen hoe je notifications inschakelt (notify-keyspace-events) en je inschrijft op de speciale keyevent/keyspace channels is het praktische mechanisme.
Critisch is het begrijpen van de voorbehouden essentieel voor correct gebruik: omdat het is gebouwd op Pub/Sub, is het fire-and-forget (events zonder verbonden subscriber gaan permanent verloren — dus het is onbetrouwbaar voor kritieke events), het expired event is vertraagd ten opzichte van de exacte TTL (afgevuurd wanneer de key daadwerkelijk wordt verwijderd door lazy/active expiration, dus timing is niet precies), en het heeft overhead bij groot volume — wat betekent dat voor betrouwbare event-afhandeling Streams of een ander mechanisme beter is.
Deze kennis voorkomt overmatig vertrouwen op notifications voor gegarandeerde bezorging.
Omdat reageren op Redis-gegevenswijzigingen (vooral vervaloningen als timers) een nuttig patroon is voor vertraagde acties en planning, en omdat keyspace notifications het bieden maar met belangrijke betrouwbaarheids- en timing-beperkingen (erfend van Pub/Sub's fire-and-forget-aard), is het begrijpen van keyspace notifications — wat ze zijn, het expiration-as-timer patroon, en vooral de voorbehouden — waardevolle, praktisch relevante kennis voor het passend gebruiken van deze functie terwijl je weet wanneer de beperkingen ervan een betrouwbaardere benadering vereisen.