ما هي إخطارات مساحة المفاتيح (Keyspace Notifications) في 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 الدقيق (ينطلق عند إزالة المفتاح فعليًا بواسطة انتهاء الصلاحية الكسول/النشط، لذا التوقيت ليس دقيقًا)، وله تكلفة عند الحجم الكبير — مما يعني أنه للمعالجة الموثوقة للأحداث، Streams أو آلية أخرى أفضل. هذا الوعي يمنع الاعتماد المفرط على الإخطارات للتسليم المضمون. بما أن التفاعل مع تغييرات بيانات Redis (خاصة انتهاء الصلاحية كمؤقتات) نمط مفيد للإجراءات المؤجلة والجدولة، وبما أن إخطارات مساحة المفاتيح توفره لكن مع قيود موثوقية وتوقيت مهمة (وراثة طبيعة إطلاق ونسيان Pub/Sub)، فإن فهم إخطارات مساحة المفاتيح — ما هي، نمط انتهاء الصلاحية كمؤقت، والتحذيرات بشكل خاص — معرفة قيمة وعملية لاستخدام هذه الميزة بشكل صحيح مع معرفة متى تتطلب قيودها نهجًا أكثر موثوقية.