Redis keyspace notifications क्या हैं?

Question

Accepted Answer

**Keyspace notifications** clients को keys में बदलावों के बारे में events को subscribe करने देते हैं (Pub/Sub के माध्यम से) — जैसे एक key का set होना, delete होना, या **expire** होना। ये Redis में data changes पर react करने को सक्षम बनाते हैं, expiration event एक विशेष रूप से आम, उपयोगी trigger होने के साथ। ## enabling और subscribing ```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) और विशेष channels को subscribe करते हैं: `__keyevent@__:` (एक type के events, जैसे `expired`, affected key के साथ) या `__keyspace@__:` (एक specific 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 ``` ## महत्वपूर्ण 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 को सक्षम बनाती है — हालाँकि इसकी limitations को समझना समान रूप से महत्वपूर्ण है। यह feature clients को **key changes के बारे में events को subscribe करने** देता है (sets, deletes, और विशेष रूप से **expirations**) Pub/Sub के माध्यम से, Redis को application को सूचित करने में सक्षम बनाते हुए जब data बदलता है। **विशेष रूप से expiration event** एक आम, elegant pattern को शक्ति देता है: एक key के TTL को एक **timer/scheduler** के रूप में उपयोग करना — एक key को कुछ delay के बाद expire होने के लिए set करें, और expiration notification एक action को trigger करता है (एक hold period के बाद held inventory release करना, session expiry संभालना, delayed jobs चलाना), एक separate scheduling system के बिना scheduled-action behavior प्रदान करते हुए। notifications को कैसे enable करें (`notify-keyspace-events`) और special keyevent/keyspace channels को subscribe करें यह समझना व्यावहारिक mechanism है। महत्वपूर्ण रूप से, **caveats** को समझना इसे सही तरीके से उपयोग करने के लिए आवश्यक है: क्योंकि यह **Pub/Sub पर बना है, यह fire-and-forget है** (किसी connected subscriber के बिना events स्थायी रूप से miss होते हैं — इसलिए यह critical events के लिए unreliable है), **expired event exact TTL के पीछे lag करता है** (तब fire होता है जब key वास्तव में lazy/active expiration द्वारा हटाई जाती है, इसलिए timing precise नहीं है), और इसका high volume पर overhead है — मतलब reliable event handling के लिए, Streams या कोई अन्य mechanism बेहतर है। यह जागरूकता guaranteed delivery के लिए notifications पर over-rely करने से रोकती है। चूँकि Redis data changes पर react करना (विशेष रूप से timers के रूप में expirations) delayed actions और scheduling के लिए एक उपयोगी pattern है, और चूँकि keyspace notifications इसे प्रदान करते हैं लेकिन महत्वपूर्ण reliability और timing limitations के साथ (Pub/Sub की fire-and-forget प्रकृति को inherit करते हुए), keyspace notifications को समझना — वे क्या हैं, expiration-as-timer pattern, और विशेष रूप से caveats — इस feature को उपयुक्त रूप से उपयोग करने के लिए मूल्यवान, व्यावहारिक रूप से प्रासंगिक ज्ञान है जबकि यह जानते हुए कि इसकी limitations कब एक अधिक reliable approach की आवश्यकता रखती हैं।