يعرض فحص Redis قيمة سالبة لمدة بقاء المفتاح، فيفسرها التقرير كخطأ اتصال أو كمفتاح منتهي. هذا التفسير قد يخفي مشكلة مختلفة تمامًا: المفتاح موجود، لكن لا توجد له مدة انتهاء. اقرأ معنى نتيجة TTL قبل اقتراح إعادة إنشاء بيانات أو تعديل صلاحية جلسات العمل.
اقرأ الحالات الثلاث بوحدتها الصحيحة
وفق مرجع Redis لأمر TTL، ترجع المدة المتبقية بالثواني. ومن Redis 2.8 تعني -2 أن المفتاح غير موجود، بينما تعني -1 أنه موجود دون وقت انتهاء مرتبط. ويوفر PTTL المعلومة بدقة المللي ثانية. الإصدارات الأقدم لها سلوك مختلف، لذا سجل الإصدار والعميل المستخدمين.
| النتيجة | وصف مناسب في التشخيص |
|---|---|
| مدة غير سالبة | وقت متبق وفق وحدة الأمر ولحظة القياس |
| -1 | موجود دون انتهاء زمني مرتبط |
| -2 | غير موجود عند تنفيذ الفحص |
لا تستنتج سبب الغياب من الرقم
في نموذج افتراضي لكاش نتائج البحث، قد يغيب المفتاح لأنه لم يُنشأ أصلًا، أو حُذف، أو انتهت مدته. نتيجة -2 وحدها لا تختار أحد هذه الأسباب. اربطها بمسار إنشاء المفتاح وسجل تشغيل آمن وسياسة الكاش، بدل كتابة «انتهت الصلاحية طبيعيًا» في كل حالة غياب.
كذلك لا تعني -1 أن البيانات باقية إلى الأبد. عدم وجود انتهاء زمني لا يمنع الحذف الصريح أو أثر سياسة الإخلاء وغيرها من ظروف التشغيل. افصل قرار مدة البقاء عن ضمانات الاستمرارية وحفظ البيانات الأساسية.
اختبر عميل التطبيق ببيانات مصطنعة
أنشئ في بيئة منفصلة ثلاثة مفاتيح تجريبية: مفتاحًا بمدة، وآخر دون مدة، واسمًا لمفتاح غير موجود. قارن ما يعيده الأمر الخام بما تعرضه مكتبة التطبيق. بعض العملاء يمثل الحالات الخاصة بقيم أو أنواع مختلفة؛ يجب ألا تتحول في التقرير إلى صفر أو مدة عادية دون تمييز.
لا تشترط أن يتساوى رقمان للمدة بعد مرور وقت بين قراءتهما. اختبر الوحدة والحالة وحدود التفسير، وسجل وقت الفحص. وإذا أضفت الفحص إلى جرد SCAN، تذكر أن المخزون يتغير أثناء الجولة، وأن كل TTL قراءة مستقلة.
اجعل التشخيص منفصلًا عن الإصلاح
في صيانة الأنظمة لا تحول رؤية -1 إلى أمر تلقائي يفرض مدة على كل مفتاح، خصوصًا الجلسات والطوابير. ناقش سياسة البقاء مع مالك الوظيفة أولًا. التسليم المفيد يوضح الحالة والوحدة وسياق الإنشاء وما لم يثبت بعد؛ لا يغير بيانات التشغيل ليجعل لوحة المراقبة تبدو خضراء.
