في تطبيق افتراضي يحفظ بيانات عرض مؤقتة، يطلب الفريق تمديد عمر المفتاح عند كل استخدام. قد يبدو الاستدعاء مجرد قراءة لأنه يعيد القيمة نفسها، لكن تغيير مدة الانتهاء كتابة لها آثار على التوجيه وعلى فترة بقاء المحتوى. راجع العقد قبل استبدال الاستدعاء في كل نقاط القراءة.
حدد ما يفعله الاستدعاء
يقرأ GETEX القيمة ويقبل خيارات لتعيين الانتهاء أو إزالته، وتصنفه وثائق Redis كأمر كتابة. إذا استخدمت EX فهو يحدد عمرًا بالثواني من لحظة الاستدعاء. إذا اخترت PERSIST فإنه يزيل الانتهاء، لذا راجع الخيار الذي ترسله المكتبة بدل الاعتماد على اسم الدالة في الكود.
قارن مفتاحين متطابقين
أنشئ مفتاحين تجريبيين بالعمر الأولي نفسه. اقرأ الأول بـ GET والثاني بـ GETEX مع EX بعد فترة معلومة. راقب أن عمر الأول يواصل النزول بينما يبدأ الثاني مدة جديدة. نفّذ أيضًا قراءة مفتاح غائب وتحقق من أن مسار التطبيق يتعامل مع غياب القيمة دون افتراض أن القراءة أنشأت مفتاحًا جديدًا.
اختر أي وصول يمدد العمر
قد ترغب في تمديد عمر محتوى يعاد استخدامه داخل جلسة، بينما يجب أن تنتهي صلاحية نسخة أسعار بعد موعد ثابت. إذا قرأت خدمة فحص دورية المفتاح بـ GETEX فقد تمدد بقاءه بلا استخدام بشري. حدد مواضع التجديد، واجعل مهلة freshness مستقلة إن كانت هناك قيمة لا يصح عرضها بعد وقت معلوم.
افحص التوجيه والصلاحيات
راجع أن العميل لا يرسل الأمر إلى نسخة مخصصة للقراءة فقط، وأن حساب التطبيق يسمح بالكتابة المطلوبة على نطاق المفاتيح المقصود. جرّب انتقال العميل بين العقد وفق إعداد بيئة الاختبار. راقب العمر والقيمة بعد الاستدعاء، لأن رجوع القيمة المتوقعة لا يكفي لإثبات أن سياسة الانتهاء تعمل.
يمكن تطبيق الاختبارات ضمن الصيانة التقنية والمراجعة التقنية.
المرجع الفني Redis GETEX.
صورة توضيحية أصلية مرتبطة بالمثال.
