ما الذاكرة المؤقتة الموزعة وكيف تتعامل مع أعطالها؟

Question

IT Interview Practice · Accepted Answer

**تتيح الذاكرة المؤقتة الموزعة لعدة نسخ من التطبيق إعادة استخدام البيانات عبر الشبكة.** هدفها تجنب تكرار العمل المكلف مع إبقاء قواعد واضحة للحداثة والفشل.

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

## 1. قرر ما يمكن تخزينه مؤقتًا بأمان

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

حدد مفتاحًا يعرّف النتيجة كاملة، بما فيها المستأجر واللغة والمدخلات ذات الصلة. وإلا فقد تعيد ذاكرة مؤقتة سريعة بيانات العميل الخطأ. أبقِ قاعدة البيانات مصدرًا معتمدًا للسجلات التجارية الدائمة، لأن القيم المؤقتة قد تختفي.

## 2. تتبع القراءة قبل تصميم التحديثات

أسلوب شائع هو cache-aside: يفحص التطبيق الذاكرة المؤقتة، ويقرأ قاعدة البيانات عند عدم العثور على القيمة، ثم يخزن النتيجة مع مدة انتهاء تسمى TTL.

```text
Request -> Cache -> hit  -> Return value
                 -> miss -> Database -> Fill cache -> Return value
```

يقلل ذلك قراءات قاعدة البيانات المتكررة عندما تحتاج طلبات كثيرة القيمة نفسها. لكنه يضيف اتصالات شبكة واعتمادًا آخر، لذلك لا يفيد إلا إذا تجاوز العمل المتجنب هذه التكاليف. راجع [cache-aside في Redis](https://redis.io/docs/latest/develop/use-cases/cache-aside/).

## 3. قرر كيف تصبح التحديثات مرئية

للكتالوج، بداية عملية هي تثبيت تحديث قاعدة البيانات ثم إبطال نسخة المنتج المؤقتة. يعيد القارئ التالي تحميلها. لكن يبقى سباق: قد يجلب قارئ القيمة القديمة قبل التثبيت، ثم يضعها في الذاكرة المؤقتة بعد الإبطال.

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

## 4. امنع فقد القيمة المؤقتة من التحول إلى انقطاع

إذا انتهت صلاحية قيمة شائعة، فقد يقرأ مستدعون كثيرون قاعدة البيانات معًا. يسمى ذلك cache stampede. ويمكن أن يخلق تعطل الذاكرة المؤقتة المشكلة نفسها عبر قيم كثيرة.

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

اختبر هذه المسارات عمدًا. نسبة إصابات مرتفعة أثناء التشغيل الطبيعي لا تخبرك كثيرًا عن سلوك الخدمة عندما تختفي الذاكرة المؤقتة.

## 5. توسع حسب الاختناق الفعلي

يوزع sharding المفاتيح بين العقد، بينما تحتفظ replication بنسخ للإتاحة أو القراءة. إنهما يحلان مشكلتين مختلفتين. يستخدم Redis Cluster خانات hash لتحديد المكان، لذا لا تقسم إضافة العقد عمل مفتاح ساخن واحد تلقائيًا. راجع [مواصفات Redis Cluster](https://redis.io/docs/latest/operate/oss_and_stack/reference/cluster-spec/).

راقب نسبة الإصابات وزمن الطلبات والمهل والذاكرة والإخلاءات والحمل الواصل إلى قاعدة البيانات. يعني الإخلاء إزالة قيمة لإدارة الذاكرة وقد يحدث قبل TTL. لا تعتبر القيمة المؤقتة تخزينًا دائمًا مضمونًا لبيانات العمل أو المهام في الطابور.

للكتالوج، سأبدأ ببيانات cache-aside ذات مفاتيح صريحة وسياسة حداثة ورجوع محمي. ولن أضيف عقدًا إلا بعد أن تثبت القياسات مشكلة قدرة يستطيع التوزيع حلها فعلًا. **يشرح التصميم الجيد ما يحدث عند وجود القيمة وكذلك عند غيابها أو خطئها.**

1. قرر ما يمكن تخزينه مؤقتًا بأمان

2. تتبع القراءة قبل تصميم التحديثات

3. قرر كيف تصبح التحديثات مرئية

4. امنع فقد القيمة المؤقتة من التحول إلى انقطاع

5. توسع حسب الاختناق الفعلي

أسئلة ذات صلة