Hva er Redis keyspace-notifikasjoner?

Question

Accepted Answer

**Keyspace-notifikasjoner** lar klienter abonnere (via Pub/Sub) på hendelser om endringer i nøkler — for eksempel når en nøkkel settes, slettes, eller **utløper**. De gjør det mulig å reagere på dataendringer i Redis, med utløpshendelsen som en spesielt vanlig og nyttig 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 notifikasjoner (`notify-keyspace-events`, og velger hvilke hendelser) og abonnerer på spesielle kanaler: `__keyevent@__:` (hendelser av en type, f.eks. `expired`, med den påvirkede nøkkelen) eller `__keyspace@__:` (hendelser på en spesifikk nøkkel). ## Utløpshendelsen: et vanlig 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 ``` ## Viktige 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 betyr noe Å forstå keyspace-notifikasjoner er nyttig kunnskap for **å reagere på dataendringer i Redis**, en evne som muliggjør visse event-drevne mønstre — men å forstå begrensningene er like viktig. Funksjonen lar klienter **abonnere på hendelser om nøkkelendringer** (setter, sletter, og spesielt **utløpinger**) via Pub/Sub, noe som gjør det mulig for Redis å varsle applikasjonen når data endres. **Utløpshendelsen spesielt** muliggjør et vanlig, elegant mønster: å bruke en nøkkels TTL som en **timer/scheduler** — sett en nøkkel til å utløpe etter en viss forsinkelse, og utløpsnotifikasjonen utløser en handling (frigjøring av holdt inventar etter en holdeperiode, håndtering av sesjonexpiry, kjøring av forsinket jobber), som gir planlagt-handling-atferd uten et eget planleggingssystem. Å forstå hvordan man aktiverer notifikasjoner (`notify-keyspace-events`) og abonnerer på de spesielle keyevent/keyspace-kanalene, er den praktiske mekanismen. Kritisk sett er det essensielt å forstå **forbehold**: fordi det er bygget på **Pub/Sub, er det brann-og-glem** (hendelser uten tilkoblet abonnent blir permanent mistet — så det er upålitelig for kritiske hendelser), **utløpshendelsen lagrer** den eksakte TTL (avfyrer når nøkkelen faktisk fjernes av lazy/aktiv expiration, så timingen er ikke presis), og det har overhead ved høyt volum — noe som betyr at for pålitelig hendelseshåndtering, er Streams eller en annen mekanisme bedre. Denne bevisstheten forhindrer å stole for mye på notifikasjoner for garantert levering. Fordi å reagere på Redis-dataendringer (spesielt utløpinger som timere) er et nyttig mønster for forsinket handling og planlegging, og fordi keyspace-notifikasjoner gir det men med viktige pålitelighets- og timingbegrensninger (arver Pub/Subs brann-og-glem-natur), er det å forstå keyspace-notifikasjoner — hva de er, utløpings-som-timer-mønsteret, og spesielt forbehold — verdifull, praktisk relevant kunnskap for å bruke denne funksjonen passende mens du vet når dens begrensninger krever en mer pålitelig tilnærming.