نجاح INCR لا يعني أن عداد Redis اكتسب مدة انتهاء. إذا زاد التطبيق العداد ثم انقطع قبل EXPIRE، قد يبقى المفتاح بلا المدة المقصودة. هذا عيب في رحلة متعددة الأوامر، حتى لو كانت زيادة العداد نفسها ذرية.
حدد أين تبدأ النافذة
تعرض وثائق Redis الأصلية لأمر INCR أنماطًا لعداد تحديد المعدل. وتوضح فجوة تنفيذ INCR دون EXPIRE في نمط يضع الانتهاء عند أول زيادة، وتقترح تجميع الزيادة والانتهاء الشرطي داخل Lua. لا تعني ذرية العملية أن الخوارزمية صالحة تلقائيًا لكل سياسة حد.
في نموذج افتراضي لخدمة تجريبية، اتفق أولًا هل النافذة تبدأ بأول طلب، أم تتبع فترة زمنية مسماة، أم تتمدد مع كل طلب. إعادة EXPIRE في كل مرة قد تغير المقصود. لا تختَر السياسة فقط لأنها تجعل الاختبار القصير يمر.
اختبر الانقطاع قبل التزامن
| الحالة | الدليل المطلوب |
|---|---|
| أول طلب لمفتاح جديد | قيمة عداد ومدة توافقان السياسة |
| انقطاع العميل بعد الزيادة | عدم بقاء عداد خارج سياسة الانتهاء المعتمدة |
| طلب قرب نهاية النافذة | لا تمديد غير مقصود للنافذة |
| طلبات متزامنة في بيئة اختبار | قرار قبول متسق مع الحد المختار |
الأمر الذري ليس ضمانًا شاملًا
راجع أين يحسب قرار السماح نفسه، وما يحدث إذا تعذر الوصول إلى Redis. اختيار السماح أو الرفض عند التعطل يحتاج قرارًا حسب حساسية الوظيفة، لا افتراضًا عامًا. كذلك تحتاج إعادة الطلب بعد مهلة اتصال إلى فهم النتيجة المحتملة؛ انتهاء انتظار العميل لا يثبت أن الزيادة لم تنفذ.
افحص أنواع المفاتيح وأسماءها وعزل المؤسسات قبل التشغيل، ولا تستخدم معرفات عملاء حقيقية في السجلات المشتركة. تجربة مفتاح واحد لا تغطي بنية موزعة أو تغيير الساعة أو تصميم كل نافذة.
لا تصلح عدادات الإنتاج بالجملة
ضمن صيانة الأنظمة نفذ التجارب على مفاتيح منفصلة، ثم راجع معاني TTL لتوثيق حالة المفتاح. لا تضف مدة لكل مفتاح بلا انتهاء تلقائيًا؛ قد تخالف وظيفة أخرى. التسليم الجيد يربط سياسة النافذة بحالات الانقطاع والتزامن والنتيجة الفعلية.
