Redis keyspace notifications ਕੀ ਹਨ?

Question

Accepted Answer

**Keyspace notifications** ਕਲায়েंट्स ਨੂੰ (Pub/Sub ਦੁਆਰਾ) key changes ਬਾਰੇ events ਨੂੰ subscribe ਕਰਨ ਦਿੰਦੀਆਂ ਹਨ — ਜਿਵੇਂ ਕਿ key set ਹੋਣਾ, deleted ਹੋਣਾ, ਜਾਂ **expire** ਹੋਣਾ। ਇਹ Redis ਵਿੱਚ data changes ਉੱਤੇ react ਕਰਨ ਲਈ enable ਕਰਦੀਆਂ ਹਨ, expiration event ਇੱਕ ਖਾਸ ਤੌਰ 'ਤੇ common, useful trigger ਹੈ। ## Enable ਅਤੇ subscribe ਕਰਨਾ ```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 ``` ਤੁਸੀਂ notifications ਨੂੰ enable ਕਰਦੇ ਹੋ (`notify-keyspace-events`, ਕਿਹੜੀਆਂ events ਚੁਣਦੇ ਹੋ) ਅਤੇ special channels ਨੂੰ subscribe ਕਰਦੇ ਹੋ: `__keyevent@__:` (ਇੱਕ type ਦੀਆਂ events, ਜਿਵੇਂ `expired`, affected key ਨਾਲ) ਜਾਂ `__keyspace@__:` (ਇੱਕ specific key 'ਤੇ events)। ## Expiration event: ਇੱਕ common pattern ```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 ``` ## ਮਹੱਤਵਪੂਰਨ caveats ```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. ``` ## ਇਸ ਦਾ ਕੀ ਮਹੱਤਵ ਹੈ Keyspace notifications ਨੂੰ ਸਮਝਣਾ **Redis ਵਿੱਚ data changes ਉੱਤੇ react ਕਰਨ** ਲਈ ਲਾਭਦਾਇਕ ਗਿਆਨ ਹੈ, ਇੱਕ ਸਮਰੱਥਾ ਜੋ ਕੁਝ event-driven patterns ਨੂੰ enable ਕਰਦੀ ਹੈ — ਹਾਲਾਂਕਿ ਇਸ ਦੀਆਂ limitations ਨੂੰ ਸਮਝਣਾ ਬਰਾਬਰ ਮਹੱਤਵਪੂਰਨ ਹੈ। Yeh feature ਕਲায়েंट्स ਨੂੰ **key changes ਬਾਰੇ events ਨੂੰ subscribe ਕਰਨ** (sets, deletes, ਅਤੇ ਖਾਸ ਤੌਰ 'ਤੇ **expirations**) Pub/Sub ਦੁਆਰਾ enable ਕਰਦੀ ਹੈ, Redis ਨੂੰ application ਨੂੰ notify ਕਰਨ ਦਾ ਸਮਰੱਥ ਬਣਾਉਂਦੀ ਹੈ ਜਦੋਂ data changes ਹੋਵੇ। **Expiration event ਖਾਸ ਤੌਰ 'ਤੇ** ਇੱਕ common, elegant pattern ਨੂੰ power ਕਰਦਾ ਹੈ: ਕਿਸੇ key ਦੀ TTL ਨੂੰ **timer/scheduler** ਵਜੋਂ ਵਰਤੋ — key ਨੂੰ ਕਿਸੇ delay ਤੋਂ ਬਾਅਦ expire ਹੋਣ ਦੇ ਲਈ set ਕਰੋ, ਅਤੇ expiration notification ਇੱਕ action trigger ਕਰਦਾ ਹੈ (hold period ਤੋਂ ਬਾਅਦ held inventory release ਕਰਨਾ, session expiry handle ਕਰਨਾ, delayed jobs run ਕਰਨਾ), ਵੱਖ scheduling system ਤੋਂ ਬਿਨਾ scheduled-action behavior ਦਿੰਦਾ ਹੈ। Notifications ਨੂੰ enable ਕਰਨਾ (`notify-keyspace-events`) ਅਤੇ special keyevent/keyspace channels ਨੂੰ subscribe ਕਰਨਾ ਸਮਝਣਾ practical mechanism ਹੈ। Critically, **caveats** ਨੂੰ ਸਮਝਣਾ ਅਤਿ ਜ਼ਰੂਰੀ ਹੈ ਇਸਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਵਰਤਣ ਲਈ: ਕਿਉਂਕਿ ਇਹ **Pub/Sub ਉੱਤੇ built** ਹੈ, ਇਹ **fire-and-forget** ਹੈ (events ਬਿਨਾ connected subscriber ਦੇ ਸਥਾਈ ਤੌਰ 'ਤੇ missed ਹਨ — ਇਸ ਲਈ ਇਹ unreliable ਹੈ critical events ਲਈ), **expired event** exact TTL ਨੂੰ **lag** ਕਰਦਾ ਹੈ (ਜਦੋਂ key lazy/active expiration ਦੁਆਰਾ actually remove ਹੋ ਜਾਂਦੀ ਹੈ ਤਾਂ fire ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ timing precise ਨਹੀਂ ਹੈ), ਅਤੇ ਇਸ ਦੇ high volume ਵਿੱਚ overhead ਹੈ — ਮਤਲਬ reliable event handling ਲਈ, Streams ਜਾਂ ਕੋਈ ਹੋਰ mechanism ਬਿਹਤਰ ਹੈ। Yeh ਜਾਗਰੂਕਤਾ critical events ਲਈ guaranteed delivery ਉੱਤੇ ਓਵਰ-ਰਿਲਾਇ ਕਰਨ ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ। Since Redis data changes ਉੱਤੇ react ਕਰਨਾ (ਖਾਸ ਤੌਰ 'ਤੇ timers ਦੇ ਤੌਰ 'ਤੇ expirations) delayed actions ਅਤੇ scheduling ਲਈ ਇੱਕ useful pattern ਹੈ, ਅਤੇ since keyspace notifications ਇਹ ਦਿੰਦੀਆਂ ਹਨ ਪਰ important reliability ਅਤੇ timing limitations (Pub/Sub ਦੀ fire-and-forget nature ਨੂੰ inherit ਕਰਦੇ ਹੋਏ), keyspace notifications ਨੂੰ ਸਮਝਣਾ — ਉਹ ਕੀ ਹਨ, expiration-as-timer pattern, ਅਤੇ ਖਾਸ ਤੌਰ 'ਤੇ caveats — ਮੁੱਲਵਾਨ, practically-relevant ਗਿਆਨ ਹੈ ਇਸ feature ਨੂੰ appropriately ਵਰਤਣ ਲਈ ਜਦੋਂ ਇਸ ਦੀਆਂ limitations ਨੂੰ ਪਤਾ ਹੋ ਕਿ ਇੱਕ more reliable approach ਦੀ ਜ਼ਰੂਰਤ ਹੈ।