Kaj so Redis keyspace notifications?

Question

Accepted Answer

**Keyspace notifications** omogočajo klientom, da se naročijo (prek Pub/Sub) na dogodke o spremembah ključev — kot je nastavljanje ključa, brisanje ali **poteka**. Omogočajo odzivanje na spremembe podatkov v Redisu, pri čemer je dogodek poteka posebno pogost, uporaben sprožilec. ## Omogočanje in naročanje ```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 ``` Omogočite obvestila (`notify-keyspace-events`, izbira, katere dogodke) in se naročite na posebne kanale: `__keyevent@__:` (dogodki vrste, npr. `expired`, z vpletenim ključem) ali `__keyspace@__:` (dogodki na določenem ključu). ## Dogodek poteka: pogost vzorec ```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 ``` ## Pomembna opozorila ```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. ``` ## Zakaj je to pomembno Razumevanje keyspace notifications je koristno znanje za **odzivanje na spremembe podatkov v Redisu**, zmožnost, ki omogoča določene vzorce vodenega z dogodki — čeprav je razumevanje njegovih omejitev enako pomembno. Funkcionalnost omogoča klientom **naročanje na dogodke o spremembah ključev** (nastavljanje, brisanje in zlasti **poteki**) prek Pub/Sub, kar Redisu omogoča, da obvesti aplikacijo, ko se podatki spremenijo. **Dogodek poteka še posebej** omogoča pogost, eleganten vzorec: uporaba TTL ključa kot **časovnika/razporejevalnika** — nastavljate ključ, da poteče po neki zakasnitve, in obvestilo o poteku sproži dejanje (sprostitev prosto vložene zaloge po obdobju čakanja, ravnanje s potekom seje, pogon zakasnjelih nalog), kar zagotavlja vedenje zaporednih dejanj brez ločenega sistema razporejevanja. Razumevanje, kako omogočiti obvestila (`notify-keyspace-events`) in se naročiti na posebne kanale keyevent/keyspace, je praktični mehanizem. Kritično je razumevanje **opozoril** bistveno za pravilno uporabo te funkcionalnosti: ker je zgrajena na **Pub/Sub, je brez povratka** (dogodki brez povezanega naročnika so trajno izgubljeni — torej je nezanesljivo za kritične dogodke), se **dogodek poteka pojavi s časovno zamudo** (sproži se, ko je ključ dejansko odstranjen z lenobno/aktivno iztekanjem, zato čas ni natančen), in ima režijo pri veliki količini — kar pomeni, da je za zanesljivo obravnavo dogodkov Streams ali drug mehanizem boljši. To zavedanje preprečuje preslabo zanašanje na obvestila za garantirano dostavo. Ker je odzivanje na spremembe podatkov v Redisu (zlasti poteki kot časovniki) koristen vzorec za zakasnjena dejanja in razporejanje, in ker keyspace notifications to zagotavljajo, vendar z važnimi omejitvami zanesljivosti in časa (s podedovanjem narave Pub/Sub brez povratka), je razumevanje keyspace notifications — kaj so, vzorec poteka-kot-časovnika in zlasti opozorila — dragoceno, praktično relevantno znanje za primerno uporabo te funkcionalnosti, medtem ko veste, kdaj njegove omejitve zahtevajo bolj zanesljiv pristop.