كيف تخزّن في الكاش لتقليل حمل قاعدة البيانات عند ملايين الطلبات/دقيقة؟

Question

IT Interview Practice · Accepted Answer

ضع طبقة **cache-aside** (Redis/Memcached) أمام قاعدة البيانات كي تصيب القراءات الذاكرة، وامنح المداخل **TTL** و**أبطِلها عند الكتابة**، وأضِف **حماية من التدافع (stampede protection)** كي لا يُطلق مفتاح بارد قطيعاً هادراً (thundering herd) على قاعدة البيانات، ووزّع **المفاتيح الساخنة** عبر replicas كي لا يُذيب مفتاح شائع واحد عقدة واحدة.

```text
                 ┌── hit ──▶ return value
request ──▶ cache│
                 └── miss ─▶ lock ─▶ DB read ─▶ set(TTL) ─▶ return
                              │
                    (only ONE miss populates; others wait)
DB writes ──▶ invalidate/update key
```

## Cache-aside مقابل read-through

في **cache-aside** يفحص التطبيق الكاش؛ وعند الفقدان يقرأ قاعدة البيانات ويعبّئ الكاش بنفسه. في **read-through** تفعل مكتبة الكاش ذلك عنك. في كلتا الحالتين الهدف واحد: تحويل استعلام قاعدة بيانات بـ 5 مللي ثانية إلى بحث ذاكرة بـ 0.2 مللي ثانية، فكاش بمعدّل إصابة 95% يقلّل حركة قراءة قاعدة البيانات **20×**. عند ملايين الطلبات/دقيقة لا يمكن لقاعدة البيانات ببساطة خدمة كل قراءة — الكاش هو ما يجعل الأرقام تعمل.

## TTL + الإبطال

طريقتان لإبقاء الكاش طازجاً، وعادةً تحتاج كلتيهما. **TTL** يحدّ القِدَم — مدخل ينتهي بعد N ثانية فتُصلِح البيانات الخاطئة نفسها. **الإبطال الصريح** يحذف/يحدّث المفتاح عند الكتابة لصحّة لا تحتمل انتظار TTL. الخلل الكلاسيكي هو التخزين دون إبطال وخدمة بيانات قديمة لدقائق؛ والأدقّ هو الإبطال *و* التعيين في نفس الكتابة، وهو ما يتسابق.

## الحماية من التدافع والمفاتيح الساخنة

- **التدافع (القطيع الهادر):** عند انتهاء مفتاح ساخن، آلاف الفقدانات المتزامنة تصيب قاعدة البيانات معاً وقد تُطيح بها. أصلِح بـ**قفل لكل مفتاح/single-flight** (طلب واحد فقط يُعيد الحساب، والبقية تنتظر) أو **تحديث مبكّر/احتمالي (early/probabilistic refresh)** قبل الانتهاء.
- **المفاتيح الساخنة:** مفتاح واحد (ملفّ مشهور) قد يُشبع CPU/شبكة عقدة Redis واحدة. وزّعه — انسخ المفتاح عبر العُقد، أو أضِف كاشاً محلياً صغيراً داخل العملية أمام Redis لأكثر العناصر سخونة.

## منظور المقابلة

يريد المُحاور أن يراك تفكّر أبعد من "أضِف Redis". الجيد: cache-aside مع TTL. الرائع: تسمّي **الحماية من التدافع، واستراتيجية الإبطال، ومعالجة المفاتيح الساخنة، وماذا يحدث عند انقطاع الكاش**. الفخّ هو افتراض أن الكاش دائماً يعمل — إن مات Redis وسقطت كل فقدانات عبره إلى قاعدة البيانات، تحصل على **انهيار كاش (cache-avalanche)** يُسقِط قاعدة البيانات أيضاً.

## المقايضات وأنماط الأعطال

- **القِدَم مقابل الحمل:** TTL قصير = طازج لكن فقدانات أكثر؛ TTL طويل = فقدانات أقل لكن أقدم. اضبط حسب البيانات.
- **انهيار الكاش:** انتهاء مفاتيح كثيرة معاً (نفس TTL) يسبّب ذروة حمل — أضِف **jitter** إلى TTLs.
- **الاتساق:** الكاش وقاعدة البيانات قد يتباعدان؛ للقراءات الحرجة مالياً، اقرأ قاعدة البيانات أو استخدم write-through.
- **الإخلاء من الذاكرة (Memory eviction):** تحت الضغط يُخلي Redis حسب السياسة (LRU/LFU)؛ سياسة خاطئة تُسقِط مجموعتك الساخنة بصمت.

Cache-aside مقابل read-through

TTL + الإبطال

الحماية من التدافع والمفاتيح الساخنة

منظور المقابلة

المقايضات وأنماط الأعطال

أسئلة ذات صلة