Vad är Redis keyspace notifications?

Question

Accepted Answer

**Keyspace notifications** låter klienter prenumerera (via Pub/Sub) på händelser om ändringar av nycklar — till exempel att en nyckel sätts, raderas eller **förfaller**. De möjliggör reaktion på dataändringar i Redis, med förfallohändelsen vara en särskilt vanlig, användbar utlösare. ## Aktivering och prenumeration ```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 aktiverar notifikationer (`notify-keyspace-events`, där du väljer vilka händelser) och prenumererar på särskilda kanaler: `__keyevent@__:` (händelser av en typ, t.ex. `expired`, med den påverkade nyckeln) eller `__keyspace@__:` (händelser på en specifik nyckel). ## Förfallohändelsen: ett vanligt 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 ``` ## Viktiga varningar ```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. ``` ## Varför det är viktigt Att förstå keyspace notifications är användbar kunskap för **att reagera på dataändringar i Redis**, en förmåga som möjliggör vissa händelsestyrda mönster — men att förstå dess begränsningar är lika viktigt. Funktionen låter klienter **prenumerera på händelser om nyckeländringar** (sättningar, raderingar och särskilt **förfall**) via Pub/Sub, vilket möjliggör att Redis notifierar applikationen när data ändras. **Förfallohändelsen i synnerhet** driver ett vanligt, elegant mönster: att använda en nyckels TTL som en **timer/schemaläggare** — sätt en nyckel att förfalla efter en viss fördröjning, och förfallohändelsen utlöser en åtgärd (frigöra hållen inventering efter en innehållningsperiod, hantera sessionsförfall, köra försenade jobb), vilket ger schemalagd-åtgärd-beteende utan ett separat schemaläggningssystem. Att förstå hur man aktiverar notifikationer (`notify-keyspace-events`) och prenumererar på de särskilda keyevent/keyspace-kanalerna är den praktiska mekanismen. Viktigt är att förstå **varningarna** väsentligt för att använda detta korrekt: eftersom det är byggt på **Pub/Sub är det brand-och-glöm** (händelser utan ansluten prenumerant går för alltid förlorade — så det är opålitligt för kritiska händelser), **förfallohändelsen släpar** den exakta TTL:n (utlöses när nyckeln faktiskt tas bort genom lat/aktiv förfallning, så tidpunkten är inte exakt), och det har overhead vid högt volym — vilket innebär att för pålitlig händelsehantering är Streams eller en annan mekanism bättre. Denna medvetenhet förhindrar att man för mycket förlitar sig på notifikationer för garanterad leverans. Därför att reagera på Redis-dataändringar (särskilt förfall som timrar) är ett användbart mönster för försenade åtgärder och schemaläggning, och eftersom keyspace notifications tillhandahåller det men med viktiga tillförlitlighets- och tidpunktsbegränsningar (som ärver Pub/Sub:s brand-och-glöm-natur), är förståelse för keyspace notifications — vad de är, förfall-som-timer-mönstret och särskilt varningarna — värdefull, praktiskt relevant kunskap för att använda denna funktion på lämpligt sätt samtidigt som du vet när dess begränsningar kräver en mer pålitlig metod.