Redis keyspace notifications म्हणजे काय?

Question

Accepted Answer

**Keyspace notifications** ग्राहकांना Pub/Sub द्वारे की मध्ये होणार्‍या बदलांच्या इव्हेंटला सबस्क्राइब करण्याची सुविधा देते — जसे की की सेट होणे, डिलीट होणे किंवा **एक्सपायर** होणे. त्यामुळे Redis मध्ये डेटा बदलांला प्रतिक्रिया देणे शक्य होते, एक्सपायरेशन इव्हेंट विशेषत: एक उपयोगी ट्रिगर असते. ## सक्षम करणे आणि सबस्क्राइब करणे ```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`, कोणत्या इव्हेंट्स हवे हे निवडून) सक्षम करता आणि विशेष channels ला सबस्क्राइब करता: `__keyevent@__:` (एक प्रकारच्या इव्हेंट्स, उदाहरणार्थ `expired`, प्रभावित की सह) किंवा `__keyspace@__:` (विशिष्ट की वर होणार्‍या इव्हेंट्स). ## एक्सपायरेशन इव्हेंट: एक सामान्य प्रक्रिया ```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. ``` ## याचे महत्व Keyspace notifications समजून घेणे हे **Redis मध्ये डेटा बदलांना प्रतिक्रिया देणे** साठी उपयोगी ज्ञान आहे, हे क्षमता विशिष्ट इव्हेंट-चालित प्रक्रिया सक्षम करते — परंतु त्याच्या मर्यादा समजून घेणेही तितकेच महत्वाचे आहे. हा फीचर ग्राहकांना Pub/Sub द्वारे **की बदलांबद्दल इव्हेंट्सला सबस्क्राइब करणे** (सेट्स, डिलीट्स, आणि विशेषत: **expirations**) देते, ज्यामुळे Redis अॅप्लिकेशनला डेटा बदलल्यास सूचित करू शकते. **एक्सपायरेशन इव्हेंट विशेषत:* एक सामान्य, मजेदार प्रक्रिया चालवते: ki च्या TTL ला **timer/scheduler** म्हणून वापरणे — एक ki काही विलंबानंतर एक्सपायर होण्यासाठी सेट करा, आणि एक्सपायरेशन notification एक क्रिया ट्रिगर करते (एक होल्ड कालावधीनंतर आयोजित इन्व्हेंटरी रिलीज करणे, सेशन एक्सपायरी हाताळणे, विलंबित कार्य चालवणे), वेगळ्या शेड्यूलिंग सिस्टमशिवाय शेड्यूल केलेल्या-क्रिया वर्तन प्रदान करते. Notifications (`notify-keyspace-events`) कसे सक्षम करायचे आणि विशेष keyevent/keyspace channels ला कसे सबस्क्राइब करायचे हे समजून घेणे ही व्यावहारिक यंत्रणा आहे. याचे महत्वपूर्ण मुद्दा हे आहे की **caveats** समजून घेणे योग्य वापरासाठी आवश्यक आहे: कारण ते **Pub/Sub वर बांधलेले आहे, ते fire-and-forget आहे** (कोणत्याही जोडलेल्या subscriber शिवाय इव्हेंट्स कायमस्वरूपी हरले जातात — त्यामुळे महत्वाच्या इव्हेंट्सच्या लिए हे अविश्वसनीय आहे), **expired event TTL मध्ये मंद चलते** (की वास्तविकपणे lazy/active expiration द्वारे काढून टाकली जाते तेव्हा फायर होते, त्यामुळे timing अचूक नाही), आणि उच्च व्हॉल्यूमवर त्याचा ओव्हरहेड आहे — त्यामुळे विश्वसनीय इव्हेंट हँडलिंगसाठी, Streams किंवा दुसरी यंत्रणा बरी आहे. हा जागरूकता notifications वर महत्वपूर्ण इव्हेंट्सच्या लिए जास्त विश्वास न ठेवणे प्रतिबंधित करते. Redis डेटा बदलांना प्रतिक्रिया देणे (विशेषत: expirations ला timers म्हणून) विलंबित क्रिया आणि शेड्यूलिंगसाठी उपयोगी प्रक्रिया आहे, आणि keyspace notifications ते प्रदान करतात परंतु महत्वाचे विश्वसनीयता आणि timing मर्यादा सह (Pub/Sub च्या fire-and-forget स्वभावाचा वारसा), keyspace notifications समजून घेणे — ते काय आहेत, expiration-as-timer प्रक्रिया, आणि विशेषत: caveats — हे या फीचर योग्यरित्या वापरणे, आणि कधी त्याच्या मर्यादा अधिक विश्वसनीय दृष्टिकोन आवश्यक आहे हे जाणून घेणे साठी मूल्यवान, व्यावहारिकदृष्ट्या प्रासंगिक ज्ञान आहे.