Redis — صلاحية الكاش وعزل العملاء وإبطال البيانات

الكاش مفيد عندما يعيد استخدام نتيجة مكلفة، لكنه يصبح مصدر أخطاء عندما ننسى أن البيانات الأصلية تتغيّر. السؤال الأول ليس «ما مدة TTL؟» بل «ما مقدار التأخير المقبول لهذه المعلومة؟». قائمة تصنيفات يمكن أن تتحمّل تأخيرًا، بينما قرار خصم مبلغ أو منح صلاحية يحتاج تحققًا موثوقًا في نقطة التنفيذ.

حدّد مصدر الحقيقة

في تصميم Cache-Aside، يقرأ التطبيق من الكاش أولًا؛ وعند الغياب يقرأ المصدر الأساسي ويخزّن نسخة مؤقتة. تبقى قاعدة البيانات مرجع القرار، ولا يتحوّل Redis تلقائيًا إلى بديل عنها. بعد تعديل البيانات، يجب أن تعرف أي مفاتيح أصبحت قديمة وكيف تُبطلها. وثّق ذلك بجانب مسار الكتابة، لا في صفحة منفصلة ينساها الفريق.

صمّم المفتاح كجزء من العقد

مفتاح products:1 لا يكفي إذا اختلفت النتائج حسب العميل أو اللغة أو العملة أو الصلاحيات. المثال التالي يعبّر عن نتائج كتالوج لتاجر محدد. إضافة إصدار تساعد في تغيير شكل البيانات دون تفسير قيمة قديمة بالبنية الجديدة. لا تضف معلومات شخصية أو أسرارًا إلى اسم المفتاح.

catalog:v2:tenant:8f2:locale:ar:currency:SAR:page:1

عندما تعتمد النتيجة على صلاحيات المستخدم، افصل النطاق المناسب أو تجنّب كاش الرد الكامل. تخزين استجابة مدير ثم تقديمها لموظف خطأ في التصميم حتى لو كان tenant_id صحيحًا. اختبر اختلاف الأدوار داخل العميل نفسه، وليس اختلاف العملاء فقط.

افهم السباق بين القراءة والكتابة

لنفترض أن طلبًا قرأ بيانات قديمة من القاعدة، ثم عدّل طلب آخر البيانات وحذف الكاش، ثم عاد الطلب الأول وكتب النسخة القديمة. الحذف بعد الكتابة وحده لا يمنع كل سباقات التزامن. وفق حساسية البيانات، يمكن استخدام أرقام إصدارات أو تنسيق تحديثات أو TTL قصير مع مصالحة. لا تختَر حلًا معقّدًا قبل تحديد الضرر الحقيقي من نسخة قديمة.

عند غياب الكاش، اقرأ المصدر الأساسي واحفظ نسخة مؤقتة بصلاحية. اضغط لعرض أكبر

امنع اندفاع الطلبات عند انتهاء الصلاحية

إذا انتهت صلاحية مفتاح مشهور، قد تضرب الطلبات كلها قاعدة البيانات في الوقت نفسه. استخدم دمجًا للطلبات المتزامنة أو قفلًا قصيرًا مضبوطًا بعناية، ويمكن توزيع أوقات الانتهاء بإضافة jitter. القفل نفسه يحتاج حدًا زمنيًا ومسارًا عند الفشل؛ لا تسمح بتحوّل حماية الكاش إلى انتظار مفتوح.

راقب القيمة لا نسبة الإصابة وحدها

Hit rate مرتفع لا يثبت صحة البيانات ولا تحسّن تجربة المستخدم. راقب زمن الاستجابة، وحجم القيم، والإخلاء، وأخطاء Redis، وحمل المصدر عند انقطاعه. قرّر مسبقًا هل فشل الكاش يؤدي إلى الرجوع للقاعدة أو رفض الطلب؛ الرجوع غير المحدود أثناء الانقطاع قد يغرق قاعدة البيانات.

تجربة إطلاق صغيرة

ابدأ بقراءة مكلفة وغير حساسة، وحدّد TTL وسبب اختياره، ثم اختبر التحديث والتزامن وانقطاع Redis. اجعل إزالة الكاش ممكنة دون تغيير منطق العمل. الكاش تحسين أداء له عقد صلاحية، وليس مكانًا لإخفاء استعلام غير مفهوم أو قواعد عمل غير واضحة.

سيناريو عملي: تعديل سعر منتج

قد يظهر السعر في صفحة المنتج والقائمة ونتائج البحث وحزمة توصيات. حذف مفتاح واحد لا يكفي إذا كانت النسخ مخزّنة في أكثر من مكان. ارسم أين تُشتق المعلومة، ثم اختَر آلية إبطال مناسبة لكل تمثيل. عند الدفع، لا تعتمد على سعر مخزّن في المتصفح أو استجابة كاش قديمة؛ احسب المبلغ وفق قواعد النظام الحالية وأبلغ المستخدم بالتغيير قبل تأكيد العملية.

تجربة انقطاع Redis

ابدأ بعدد محدود من الطلبات في بيئة اختبار، واجعل Redis غير متاح مؤقتًا. راقب عدد الاستعلامات الذي يصل للقاعدة وهل تنتهي المهلات سريعًا. جرّب أيضًا رجوع Redis بعد الانقطاع؛ لا تفترض أن كل القيم القديمة ما زالت مناسبة. الهدف تحديد سلوك مفهوم عند الغياب والعودة، مع حدود للحمل، وليس إثبات أن catch حول استدعاء الكاش يمنع ظهور رسالة خطأ فقط.