Hvad er Redis keyspace notifications?

Question

Accepted Answer

**Keyspace notifications** lader klienter abonnere (via Pub/Sub) på begivenheder om ændringer til nøgler — såsom en nøgle der bliver sat, slettet eller **udløber**. De gør det muligt at reagere på dataændringer i Redis, hvor expiration-begivenheden er særligt almindeligt og nyttigt trigger. ## Aktivering og abonnement ```bash # keyspace notifications are OFF by default — enable the event classes you want CONFIG SET notify-keyspace-events KEA # K=keyspace, E=keyevent, A=all event types # subscribe to events: e.g. all expirations across the database PSUBSCRIBE "__keyevent@0__:expired" # fires when ANY key expires (with the key name) PSUBSCRIBE "__keyspace@0__:mykey" # all events on a specific key ``` Du aktiverer notifications (`notify-keyspace-events`, og vælger hvilke begivenheder) og abonnerer på special kanaler: `__keyevent@__:` (begivenheder af en type, f.eks. `expired`, med den påvirkede nøgle) eller `__keyspace@__:` (begivenheder på en specifik nøgle). ## Expiration-begivenheden: et almindeligt mønster ```text 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 ``` ## Vigtige forbehold ```text ⚠️ 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. ``` ## Hvorfor det betyder noget At forstå keyspace notifications er nyttig viden for **at reagere på dataændringer i Redis**, en kapabilitet der muliggør visse event-drevne mønstre — selvom forståelse af dets begrænsninger er lige så vigtig. Funktionen lader klienter **abonnere på begivenheder om nøgleændringer** (sætter, sletter og især **udløb**) via Pub/Sub, hvilket gør det muligt for Redis at underrette applikationen når data ændrer sig. **Expiration-begivenheden især** driver et almindeligt, elegant mønster: at bruge en nøgles TTL som en **timer/scheduler** — sæt en nøgle til at udløbe efter en vis forsinkelse, og expiration-notifikationen udløser en handling (frigørelse af holdlager efter en hold-periode, håndtering af session-udløb, kørsel af udskudte jobs), hvilket giver planlagt-handling-adfærd uden et separat scheduling-system. At forstå hvordan man aktiverer notifications (`notify-keyspace-events`) og abonnerer på de special keyevent/keyspace-kanaler er den praktiske mekanisme. Kritisk set er det vigtig at forstå **forbeholdene** for at bruge dette korrekt: fordi det er bygget på **Pub/Sub, det er send-og-glem** (begivenheder uden tilsluttet abonnent går permanent tabt — så det er upålideligt for kritiske begivenheder), **expired-begivenheden forsinker** det nøjagtige TTL (afsendes når nøglen faktisk fjernes af lazy/aktiv expiration, så timing er ikke præcis), og det har overhead ved høj volumen — hvilket betyder for pålidelig event-håndtering er Streams eller en anden mekanisme bedre. Denne bevidsthed forhindrer over-afhængighed af notifications for garanteret levering. Da at reagere på Redis-dataændringer (især expirations som timere) er et nyttigt mønster for udskudte handlinger og scheduling, og da keyspace notifications tilbyder det men med vigtige pålidelighedsamsung timing-begrænsninger (der arver Pub/Subs send-og-glem-natur), er forståelse af keyspace notifications — hvad de er, expiration-som-timer-mønsteret, og især forbeholdene — værdifuld, praktisk-relevant viden for at bruge denne funktion passende mens man ved hvornår dets begrænsninger kræver en mere pålidelig tilgang.