Redis keyspace notifications के हुन्?

Question

Accepted Answer

**Keyspace notifications** ले clients लाई Pub/Sub मार्फत keys मा भएका परिवर्तनहरूको events मा subscribe गर्न दिन्छ — जस्तै एक key set हुनु, delete हुनु, वा **expire** हुनु। तिनले Redis मा डेटा परिवर्तनहरूमा प्रतिक्रिया गर्न सक्षम गर्छ, expiration event विशेष गरी सामान्य र उपयोगी ट्रिगर भइरहेको छ। ## सक्षम गर्नु र 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 सक्षम गर्नुहुन्छ (`notify-keyspace-events`, कुन events चाहिन्छ भनी छनोट गर्दै) र विशेष channels मा subscribe गर्नुहुन्छ: `__keyevent@__:` (एक प्रकारको events, जस्तै `expired`, असर गरिएको key सहित) वा `__keyspace@__:` (एक विशिष्ट key मा events)। ## Expiration event: एक सामान्य 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 ``` ## महत्वपूर्ण सावधानीहरू ```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. ``` ## यो किन महत्वपूर्ण छ **Redis मा डेटा परिवर्तनहरूमा प्रतिक्रिया गर्ने** यो को लागि keyspace notifications बुझ्नु उपयोगी ज्ञान हो, एक क्षमता जसले निश्चित event-driven patterns लाई सक्षम गर्छ — यद्यपि यसको सीमाहरू बुझ्नु समान रूपमा महत्वपूर्ण छ। यो feature ले clients लाई key परिवर्तनहरू (sets, deletes, र विशेष गरी **expirations**) को बारेमा events मा subscribe गर्न सक्षम गर्छ Pub/Sub मार्फत, Redis लाई डेटा परिवर्तन हुँदा application लाई सूचित गर्न सक्षम गर्दै। **Expiration event विशेष गरी** एक सामान्य, सुन्दर pattern लाई शक्तिशाली गर्छ: एक key को TTL लाई **timer/scheduler** को रूपमा प्रयोग गर्नु — केही विलम्ब पछि expire हुनको लागि एक key सेट गर्नु, र expiration notification ले एक कार्य ट्रिगर गर्छ (होल्ड अवधि पछि राखिएको inventory रिलिज गर्नु, session expiry हेर्नु, विलम्बित कार्यहरू चलाउनु), अलग scheduling system बिना scheduled-action व्यवहार प्रदान गर्दै। Notifications सक्षम गर्ने (`notify-keyspace-events`) र विशेष keyevent/keyspace channels मा subscribe गर्ने तरिका बुझ्नु व्यावहारिक मेकानिज्म हो। गंभीर रूपमा, **caveats** को बारेमा बुझ्नु यो सही तरीकामा प्रयोग गर्न आवश्यक छ: किनभने यो **Pub/Sub मा निर्मित छ, यो fire-and-forget हो** (कुनै जडिएको subscriber बिना events स्थायी रूपमा हराइन्छ — त्यसैले यो महत्वपूर्ण events को लागि अनिर्भरणीय छ), **expired event exact TTL भन्दा ढिलो हो** (key actually remove हुँदा lazy/active expiration द्वारा ट्रिगर हुन्छ, त्यसैले timing precise छैन), र उच्च volume मा यसको overhead छ — मतलब विश्वसनीय event handling को लागि, Streams वा अन्य मेकानिज्म राम्रो छ। यो जागरूकता notifications मा अत्यधिक भरोसा गरेर guaranteed delivery को लागि अवरोध गर्दछ। Redis डेटा परिवर्तनहरू (विशेष गरी expirations लाई timers को रूपमा) मा प्रतिक्रिया गर्नु विलम्बित कार्यहरू र scheduling को लागि एक उपयोगी pattern भएको कारण, र keyspace notifications ले यो प्रदान गर्छ तर महत्वपूर्ण विश्वसनीयता र timing सीमाहरू सहित (Pub/Sub को fire-and-forget प्रकृति वारिस गर्दै), keyspace notifications बुझ्नु — तिनले के हुन्, expiration-as-timer pattern, र विशेष गरी caveats — यो feature को उपयुक्त तरीकामा प्रयोग गर्न र यसको सीमाहरू अधिक विश्वसनीय दृष्टिकोण आवश्यक हुँदा बुझ्नको लागि मूल्यवान, व्यावहारिक रूपमा प्रासंगिक ज्ञान हो।