Redis কীস্পেস নোটিফিকেশন কী?

Question

Accepted Answer

**কীস্পেস নোটিফিকেশন** ক্লায়েন্টদের (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 ``` আপনি নোটিফিকেশন সক্ষম করেন (`notify-keyspace-events`, কোন ইভেন্টগুলি বেছে নিয়ে) এবং বিশেষ চ্যানেলগুলিতে সাবস্ক্রাইব করেন: `__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. ``` ## এটি কেন গুরুত্বপূর্ণ কীস্পেস নোটিফিকেশন বোঝা **Redis-এ ডেটা পরিবর্তনের প্রতি প্রতিক্রিয়া জানানোর** জন্য দরকারী জ্ঞান, একটি সামর্থ্য যা নির্দিষ্ট ইভেন্ট-চালিত প্যাটার্নগুলি সক্ষম করে — যদিও এর সীমাবদ্ধতা বোঝাও সমান গুরুত্বপূর্ণ। ফিচারটি ক্লায়েন্টদের **কী পরিবর্তনের বিষয়ে ইভেন্টগুলিতে সাবস্ক্রাইব করতে** দেয় (সেট, ডিলিট, এবং বিশেষত **এক্সপিরেশন**) Pub/Sub এর মাধ্যমে, Redis কে ডেটা পরিবর্তন হলে অ্যাপ্লিকেশনকে নোটিফাই করতে সক্ষম করে। **এক্সপিরেশন ইভেন্ট বিশেষত** একটি সাধারণ, মার্জিত প্যাটার্ন চালিত করে: একটি কীর TTL কে একটি **টাইমার/শিডিউলার** হিসাবে ব্যবহার করা — কিছু বিলম্বের পরে এক্সপায়ার করার জন্য একটি কী সেট করুন, এবং এক্সপিরেশন নোটিফিকেশন একটি অ্যাকশন ট্রিগার করে (একটি হোল্ড পিরিয়ডের পরে ধারণকৃত ইনভেন্টরি রিলিজ করা, সেশন এক্সপায়ারি হ্যান্ডল করা, বিলম্বিত জবস চালানো), একটি আলাদা শিডিউলিং সিস্টেম ছাড়াই শিডিউল করা অ্যাকশনের আচরণ প্রদান করে। নোটিফিকেশন সক্ষম করা (`notify-keyspace-events`) এবং বিশেষ keyevent/keyspace চ্যানেলগুলিতে সাবস্ক্রাইব করার উপায় বোঝা হল ব্যবহারিক মেকানিজম। গুরুত্বের সাথে, **সতর্কতা** বোঝা এটি সঠিকভাবে ব্যবহার করার জন্য অপরিহার্য: কারণ এটি **Pub/Sub এর উপর নির্মিত, এটি ফায়ার-এন্ড-ফরগেট** (কোন সংযুক্ত সাবস্ক্রাইবার ছাড়া ইভেন্টগুলি স্থায়ীভাবে মিস হয় — তাই এটি গুরুত্বপূর্ণ ইভেন্টের জন্য অনির্ভরযোগ্য), **এক্সপায়ার্ড ইভেন্ট সঠিক TTL-এর পিছিয়ে থাকে** (কী প্রকৃতপক্ষে lazy/active এক্সপিরেশন দ্বারা সরানো হলে ফায়ার হয়, তাই টাইমিং সঠিক নয়), এবং এটিতে উচ্চ ভলিউমে ওভারহেড রয়েছে — অর্থাৎ নির্ভরযোগ্য ইভেন্ট হ্যান্ডলিংয়ের জন্য, Streams বা অন্য একটি মেকানিজম ভাল। এই সচেতনতা সমালোচনামূলক ইভেন্টের জন্য গ্যারান্টিড ডেলিভারির উপর অতিরিক্ত নির্ভরতা প্রতিরোধ করে। Rediস ডেটা পরিবর্তনে প্রতিক্রিয়া করা (বিশেষত এক্সপিরেশন টাইমার হিসাবে) বিলম্বিত অ্যাকশন এবং শিডিউলিংয়ের জন্য একটি দরকারী প্যাটার্ন হওয়ায়, এবং যেহেতু কীস্পেস নোটিফিকেশন এটি প্রদান করে কিন্তু গুরুত্বপূর্ণ নির্ভরযোগ্যতা এবং টাইমিং সীমাবদ্ধতার সাথে (Pub/Sub-এর ফায়ার-এন্ড-ফরগেট প্রকৃতি উত্তরাধিকার), কীস্পেস নোটিফিকেশন বোঝা — সেগুলি কী, এক্সপিরেশন-টাইমার প্যাটার্ন, এবং বিশেষত সতর্কতা — এই ফিচার উপযুক্তভাবে ব্যবহার করার জন্য মূল্যবান, ব্যবহারিকভাবে প্রাসঙ্গিক জ্ঞান যখন এর সীমাবদ্ধতা আরও নির্ভরযোগ্য পদ্ধতির প্রয়োজন তা জানার জন্য।