Co jsou notifikace keyspace v Redisu?

Question

Accepted Answer

**Notifikace keyspace** umožňují klientům se přihlásit (prostřednictvím Pub/Sub) k událostem o změnách klíčů — jako je nastavení klíče, jeho smazání nebo **vypršení platnosti**. Umožňují reagovat na změny dat v Redisu, přičemž událost vypršení platnosti je obzvláště běžný a užitečný spouštěč. ## Povolení a přihlášení ```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 ``` Notifikace povolíte (`notify-keyspace-events`, volbou kterých událostí) a přihlásíte se ke speciálním kanálům: `__keyevent@__:` (události určitého typu, např. `expired`, s postižením klíčem) nebo `__keyspace@__:` (události na konkrétním klíči). ## Událost vypršení platnosti: běžný vzor ```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 ``` ## Důležitá varování ```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. ``` ## Proč je to důležité Porozumění notifikacím keyspace je užitečné vědomosti pro **reagování na změny dat v Redisu**, schopnost, která umožňuje určité vzory řízené událostmi — ale porozumění jeho omezením je stejně důležité. Funkce umožňuje klientům **se přihlásit k událostem o změnách klíčů** (nastavení, smazání a zejména **vypršení platnosti**) prostřednictvím Pub/Sub, což umožňuje Redisu upozornit aplikaci na změny dat. **Událost vypršení platnosti zejména** využívá běžný a elegantní vzor: použití TTL klíče jako **časovače/plánovače** — nastavte klíč tak, aby vypršel po určité prodlevě, a notifikace vypršení platnosti spustí akci (uvolnění drženého inventáře po období zadržení, zpracování vypršení relace, spuštění odložených úloh), což poskytuje chování plánované akce bez samostatného plánovacího systému. Porozumění tomu, jak povolить notifikace (`notify-keyspace-events`) a přihlásit se ke speciálním kanálům keyevent/keyspace, je praktickým mechanismem. Zásadně důležité je porozumění **varováním**: protože je vybudeno na **Pub/Sub, je to „spálí a zapomene"** (události bez připojeného odběratele jsou trvale ztraceny — takže je to nespolehlivé pro kritické события), **událost expired má zpoždění** přesného TTL (spuštění, když je klíč skutečně odstraněn líným/aktivním vypršením platnosti, takže načasování není přesné), a má režii při vysokém objemu — což znamená, že pro spolehlivé zpracování událostí je Streams nebo jiný mechanismus lepší. Toto povědomí zabrání nadměrnému spoléhání se na notifikace pro zaručené doručení. Poněvadž reagování na změny dat v Redisu (zejména vypršení platnosti jako časovače) je užitečný vzor pro odložené akce a plánování, a protože notifikace keyspace to poskytují, ale s důležitými omezeními spolehlivosti a časování (dědí povahu "spálí a zapomene" Pub/Sub), je porozumění notifikacím keyspace — co to jsou, vzor vypršení-jako-časovač a zejména varování — cenné a prakticky relevantní vědomosti pro správné použití této funkce a zároveň vědění, kdy její omezení vyžadují spolehlivější přístup.