مستويات واستراتيجيات التخزين المؤقت

🎯 السؤال الأساسي

لماذا تفتح بعض المواقع خلال 50 ميلي ثانية، بينما يستغرق البعض الآخر 5 ثوانٍ؟ الأمر أشبه بالسؤال: لماذا يستغرق إخراج كتاب من حقيبتك ثانية واحدة، بينما يستغرق البحث عن كتاب في المكتبة 10 دقائق؟ الإجابة هي — التخزين المؤقت (Cache). سيأخذك هذا الفصل في رحلة لفهم المبادئ الأساسية للتخزين المؤقت وأنماط التصميم والتقنيات العملية، لزيادة أداء نظامك بمقدار 100 مرة.

1. لماذا نحتاج إلى "التخزين المؤقت"؟

1.1 التطور من "الاستعلام في كل مرة" إلى "تذكر البيانات الشائعة"

في بدايات عالم الحاسوب، كان المبرمجون يستعلمون من القرص الصلب أو قاعدة البيانات في كل مرة يحتاجون فيها إلى البيانات. يشبه ذلك اضطرارك لتصفح الكتاب للبحث عن صيغة رياضية في كل مرة تحل فيها مسألة — صحيح أنه دقيق، لكنه بطيء جدًا. ومع ازدياد حجم النظام، بدأ أسلوب "الاستعلام في كل مرة" يكشف عن مشاكل خطيرة: ارتفاع استخدام وحدة المعالجة المركزية لقاعدة البيانات إلى 95%، وارتفاع زمن الاستجابة من 100 ميلي ثانية إلى 8 ثوانٍ، وانهيار النظام بالكامل في النهاية.

الأمر يشبه طالبًا يضطر للجري من السكن الجامعي إلى المكتبة للبحث عن المراجع 50 مرة يوميًا، حتى ينهار من التعب في منتصف الطريق. الحل بسيط: ضع كتيبًا للصيغ الشائعة في حقيبتك، وارجع إليه مباشرة عند الحاجة دون الذهاب إلى المكتبة في كل مرة. التخزين المؤقت هو "كتيب الصيغ" لنظام الحاسوب — يخزن البيانات الشائعة في مكان سريع الوصول، لئلا يضطر النظام للذهاب إلى "المكتبة" (قاعدة البيانات) في كل مرة.

🐌 بدون تخزين مؤقت

كل طلب يستعلم من قاعدة البيانات
استخدام CPU لقاعدة البيانات 95%
زمن الاستجابة 5-8 ثوانٍ
النظام عرضة للانهيار

🚀 مع تخزين مؤقت

95% من الطلبات تُعاد مباشرة
استخدام CPU لقاعدة البيانات < 20%
زمن الاستجابة 50 ميلي ثانية
النظام يعمل باستقرار

هذه هي المشكلة الأساسية التي يحلها "التخزين المؤقت": من خلال تخزين نسخ من البيانات الشائعة، تقليل الوصول إلى التخزين البطيء (قاعدة البيانات)، مما يجعل النظام أسرع وأكثر استقرارًا.

Without cache

5-8 s response, high DB pressure

With cache

50 ms response, most reads served from memory

1.2 قصة واقعية عن فشل مؤلم: لماذا التخزين المؤقت هو طوق النجاة

قد تتساءل: "نظامي يعمل جيدًا الآن، لماذا أصمم التخزين المؤقت مسبقًا؟" دعني أحكِ لك قصة واقعية، وستفهم لماذا التخزين المؤقت ليس "خيارًا" بل "ضرورة".

انهيار قاعدة بيانات تشيانغ

تشيانغ هو مهندس Full-Stack في شركة ناشئة، طور تطبيقًا اجتماعيًا. في البداية كان عدد المستخدمين قليلًا (بضع مئات)، وكان النظام يعمل بشكل طبيعي، وشعر تشيانغ أنه لا حاجة للتخزين المؤقت، فكان يستعلم مباشرة من قاعدة البيانات.

بعد نصف عام، نما عدد المستخدمين إلى 100 ألف، وفي أحد الأيام نشر أحد المشاهير منشورًا على التطبيق، فتدفق 100 ألف مستخدم فجأة. انهارت قاعدة البيانات مباشرة: CPU وصل إلى 100%، وزمن الاستجابة قفز من 100ms إلى 30 ثانية، وانهار التطبيق بالكامل، وخسرت الشركة عددًا كبيرًا من المستخدمين.

بعد التحليل بأثر رجعي: لو كان هناك طبقة تخزين مؤقت بسيطة (مثل Redis) لتخزين المنشورات الرائجة، لكان من الممكن تخفيف ضغط قاعدة البيانات بنسبة 95% على الأقل، ولكان النظام صمد أمام هذا التدفق الهائل.

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

💡 الدرس الأساسي

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

2. المفاهيم الأساسية: ما هو التخزين المؤقت؟

🤔 ما هو التخزين المؤقت تحديدًا؟

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

ثلاث نقاط رئيسية:

نسخة: البيانات في التخزين المؤقت هي نسخة من البيانات الأصلية (قاعدة البيانات)، وليست البيانات الرئيسية
وصول سريع: التخزين المؤقت يكون عادة في الذاكرة، وسرعة قراءته أسرع بـ 100 ألف مرة من القرص الصلب
سعة محدودة: مساحة التخزين المؤقت محدودة، ولا يمكن تخزين سوى البيانات الأكثر استخدامًا

إذن، التخزين المؤقت هو مقايضة المساحة بالوقت — التضحية ببعض مساحة الذاكرة للحصول على سرعة وصول فائقة للبيانات.

قبل التعمق في التقنيات المحددة، نحتاج أولاً لتوضيح بعض المفاهيم الأساسية. ولنساعدك على الفهم، سنستخدم تشبيه "حقيبة الطالب" لشرح نظام التخزين المؤقت.

2.1 فهم المفاهيم الأساسية للتخزين المؤقت من خلال "تشبيه الحقيبة"

تخيل أنك طالب، تحتاج للبحث عن مراجع متنوعة يوميًا. هذه العملية مشابهة بشكل مذهل لنظام التخزين المؤقت:

المفهوم	🎒 تشبيه الحقيبة	المعنى التقني	مثال واقعي
Hit (إصابة التخزين المؤقت)	الصيغة التي تبحث عنها موجودة على الملصق	البيانات المطلوبة موجودة في التخزين المؤقت	الاستعلام عن معلومات مستخدم، موجودة في Redis، تُعاد مباشرة
Miss (فقدان التخزين المؤقت)	الصيغة ليست على الملصق، عليك البحث في الكتاب	البيانات المطلوبة غير موجودة في التخزين المؤقت	الاستعلام عن معلومات مستخدم، غير موجودة في Redis، يجب الاستعلام من قاعدة البيانات
Hit Ratio (نسبة الإصابة)	من 100 بحث عن صيغة، 95 مرة وجدتها على الملصق	نسبة وجود البيانات في التخزين المؤقت	نسبة إصابة 95% تعني أن 95% من الطلبات لا تحتاج للاستعلام من قاعدة البيانات
TTL (مدة البقاء)	الملصق مكتوب عليه "أزله بعد 3 أيام"	مدة صلاحية التخزين المؤقت	تعيين صلاحية تخزين معلومات المستخدم 30 دقيقة ثم تنتهي تلقائيًا
Eviction (الإخلاء)	الحقيبة ممتلئة، أرمي أقدم ملصق	حذف البيانات القديمة عند امتلاء التخزين المؤقت	امتلاء ذاكرة Redis، يحذف تلقائيًا البيانات الأقل استخدامًا

2.2 إصابة التخزين المؤقت مقابل فقدان التخزين المؤقت

الفارق في الأداء بين الإصابة والفقدان هائل. لنلق نظرة على البيانات المحددة:

نوع العملية	زمن الاستجابة	السرعة النسبية	السيناريو المناسب
ذاكرة CPU L1	~0.5 نانوثانية	فائقة السرعة (الأساس)	العمليات الداخلية لوحدة المعالجة
قراءة الذاكرة	~100 نانوثانية	أسرع بـ 200 مرة	تخزين مؤقت محلي (مثل Caffeine)
استعلام Redis	~1 ميلي ثانية	أبطأ بـ 2 مليون مرة	تخزين مؤقت موزع
استعلام MySQL	~10 ميلي ثانية	أبطأ بـ 20 مليون مرة	استعلام قاعدة بيانات على القرص

📊 ماذا يمكنك أن ترى من الجدول؟

الفجوة في الأداء صادمة: عمليات الذاكرة أسرع بـ 100 ألف مرة من استعلام MySQL! هذا يشبه الفرق بين أخذ كتاب من مكتبك (ثانية واحدة) والذهاب للمكتبة للبحث عنه (100 ألف ثانية، أي حوالي 28 ساعة).

سلم الأداء ثلاثي المستويات:

التخزين المؤقت المحلي (الذاكرة): الأسرع، لكن سعته صغيرة، مناسب للبيانات شديدة الرواج
تخزين Redis المؤقت: سرعة متوسطة، سعة كبيرة، مناسب للسيناريوهات الموزعة
قاعدة البيانات: الأبطأ، لكن سعتها غير محدودة، وهي المصدر النهائي للبيانات

درس عملي: يجب أن يعيد نظامك أكثر من 95% من الطلبات من طبقة التخزين المؤقت، وأقل من 5% فقط تحتاج للاستعلام من قاعدة البيانات. بهذه الطريقة يقل ضغط قاعدة البيانات، ويرتفع أداء النظام الكلي بشكل كبير.

🔍 نظرة على كود حقيقي لحالتي "الإصابة" و"الفقدان"

لنقارن بين الحالتين من خلال الكود:

javascript

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

// ===== إصابة التخزين المؤقت (Cache Hit) =====
// 1. استعلام من Redis أولاً
const userFromCache = await redis.get('user:123')
if (userFromCache) {
  // إصابة! إرجاع مباشر، يستغرق حوالي 1 ميلي ثانية
  return JSON.parse(userFromCache)
}

// ===== فقدان التخزين المؤقت (Cache Miss) =====
// 2. غير موجود في التخزين المؤقت، استعلام من قاعدة البيانات
const userFromDB = await db.query('SELECT * FROM users WHERE id = 123')
// فقدان! يحتاج لاستعلام قاعدة البيانات، يستغرق حوالي 10 ميلي ثانية، أبطأ بـ 10 مرات

// 3. بعد الاستعلام، يكتب في التخزين المؤقت، ليصيب في المرة القادمة
await redis.set('user:123', JSON.stringify(userFromDB), 'EX', 1800)
return userFromDB

النقاط الرئيسية:

إصابة التخزين المؤقت: إرجاع خلال 1 ميلي ثانية، تجربة مستخدم ممتازة
فقدان التخزين المؤقت: إرجاع خلال 10 ميلي ثانية، تجربة مستخدم أقل جودة
قيمة التخزين المؤقت: تحويل الفقدان إلى إصابة، لتحسين الأداء بمقدار 10 أضعاف

2.3 دورة حياة التخزين المؤقت

تمر أي بيانات مخزنة مؤقتًا بدورة حياة كاملة من الإنشاء إلى التدمير. فهم هذه العملية أمر بالغ الأهمية لتصميم نظام تخزين مؤقت.

المراحل الأربع:

المرحلة الأولى: الكتابة (Write)

الكتابة النشطة: عند بدء تشغيل النظام، تحميل البيانات الرائجة مسبقًا إلى التخزين المؤقت (التسخين المسبق)
التحميل الكسول (Lazy Loading): عند أول وصول، التحميل من قاعدة البيانات والكتابة في التخزين المؤقت (الأكثر استخدامًا)

المرحلة الثانية: الإصابة/الفقدان (Hit/Miss)

كل طلب يستعلم من التخزين المؤقت أولاً
الإصابة تؤدي للإرجاع المباشر، والفقدان يؤدي للاستعلام من قاعدة البيانات

المرحلة الثالثة: انتهاء الصلاحية (Expiration)

TTL (مدة البقاء): تعيين مدة بقاء التخزين المؤقت (مثل 30 دقيقة)
بعد انتهاء المدة، ينتهي التخزين المؤقت تلقائيًا، ويحتاج التحميل من جديد في المرة القادمة

المرحلة الرابعة: الإخلاء (Eviction)

مساحة التخزين المؤقت محدودة، وعند امتلائها تحتاج لحذف البيانات القديمة
استراتيجيات الإخلاء الشائعة:
- LRU (الأقل استخدامًا مؤخرًا): حذف البيانات التي لم تُستخدم لأطول فترة (الأكثر استخدامًا)
- LFU (الأقل تكرارًا في الاستخدام): حذف البيانات الأقل تكرارًا في الوصول
- FIFO (الداخل أولاً يخرج أولاً): حذف البيانات الأقدم كتابة

👇 جرب بنفسك: العرض التوضيحي التالي يوضح دورة حياة التخزين المؤقت. اضغط على "إضافة تخزين مؤقت"، ولاحظ كيف تمر البيانات بمراحل الكتابة والإصابة وانتهاء الصلاحية والإخلاء:

Cache storage (capacity: 0/6)

Hit rate: 0%Evictions: 0

Operation

Auto simulation

Event timeline

New write

Cache hit

Expiring soon

Evicting

3. رحلة تطور التخزين المؤقت: من الجهاز الواحد إلى الموزع

🤔 لماذا نحتاج لأنواع مختلفة من التخزين المؤقت؟

مثلما تضع المراجع في أماكن مختلفة أثناء الدراسة: على المكتب تضع الأكثر استخدامًا (الملصقات)، وفي الحقيبة تضع الشائع استخدامه (الدفتر)، وفي المكتبة تضع جميع المراجع (المستودع).

الأمر نفسه ينطبق على نظام التخزين المؤقت:

التخزين المؤقت المحلي (المكتب): الأسرع، سعة صغيرة، للبيانات شديدة الرواج
التخزين المؤقت الموزع (الخزانة العامة): سريع، سعة كبيرة، للبيانات الشائعة
قاعدة البيانات (المكتبة): الأبطأ، سعة غير محدودة، لجميع البيانات

لماذا التقسيم الطبقي؟ لأن أداء وتكلفة كل طبقة مختلفان، والجمع المعقول بينهما يحقق أفضل النتائج.

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

3.1 المرحلة الأولى: عصر بلا تخزين مؤقت — قاعدة البيانات عارية

الخلفية: في بدايات النظام كان عدد المستخدمين قليلًا (بضع مئات)، وجميع الطلبات تستعلم مباشرة من قاعدة البيانات دون أي طبقة تخزين مؤقت.

الحزمة التقنية:

قاعدة البيانات: MySQL
بدون تخزين مؤقت: لا Redis، ولا تخزين مؤقت محلي

بنية النظام:

طلب المستخدم → خادم التطبيق → قاعدة بيانات MySQL

خصائص هذه المرحلة:

✅ المزايا: بنية بسيطة، تطوير سريع
❌ العيوب: ضغط كبير على قاعدة البيانات، أداء ضعيف، ينهار عند وصول المستخدمين للآلاف

عرض الكود والمشاكل التي واجهتهم في ذلك الوقت

مثال على الكود (الاستعلام من قاعدة البيانات في كل مرة):

javascript

// الحصول على تفاصيل المنتج — الاستعلام من قاعدة البيانات في كل مرة
async function getProduct(productId) {
  // استعلام مباشر من قاعدة البيانات، بدون أي تخزين مؤقت
  const product = await db.query(
    'SELECT * FROM products WHERE id = ?',
    [productId]
  )
  return product
}

المشاكل التي واجهتهم:

ارتفاع CPU لقاعدة البيانات: كل طلب يستعلم من قاعدة البيانات، استخدام CPU يتجاوز 80%
استجابة بطيئة: الاستعلامات المعقدة تستغرق 50-100 ميلي ثانية، تجربة مستخدم سيئة
ضعف قدرة التزامن: الحد الأقصى لـ QPS (استعلامات في الثانية) لقاعدة البيانات هو 2000 فقط، وأكثر من ذلك يؤدي للانهيار
مشكلة المنتجات الرائجة: صفحات المنتجات الرائجة تُستعلم بشكل متكرر، وقاعدة البيانات تصبح عنق الزجاجة

الحلول المؤقتة آنذاك:

شراء خوادم أغلى (زيادة CPU، ذاكرة) — تكلفة عالية، تأثير محدود
فصل القراءة عن الكتابة في قاعدة البيانات — يخفف ضغط القراءة، لكن ضغط الكتابة ما زال موجودًا
تحسين SQL — يحسن بنسبة 20-30%، لكنه لا يحل المشكلة الجذرية

هذا النمط "العاري" كان مقبولاً عندما كان عدد المستخدمين أقل من 1000، لكن مع نمو المستخدمين إلى 10 آلاف، 100 ألف، بدأت قاعدة البيانات في الانهيار المتكرر، وأصبح الفريق في حاجة ماسة لإدخال التخزين المؤقت.

3.2 المرحلة الثانية: إدخال Redis للتخزين المؤقت — تحسين الأداء 10 أضعاف

الخلفية: نما عدد المستخدمين إلى 10 آلاف، وقاعدة البيانات لم تعد تتحمل، فقرر الفريق إدخال Redis كطبقة تخزين مؤقت.

الحزمة التقنية:

قاعدة البيانات: MySQL
التخزين المؤقت: Redis (نسخة فردية)

بنية النظام:

طلب المستخدم → خادم التطبيق → تخزين Redis المؤقت (يستعلم من قاعدة البيانات فقط عند الفقدان) → قاعدة بيانات MySQL

خصائص هذه المرحلة:

✅ المزايا: تحسين الأداء 10 أضعاف، تخفيف ضغط قاعدة البيانات بنسبة 90%
❌ العيوب: نقطة فشل وحيدة في Redis، احتمال عدم تناسق بين التخزين المؤقت وقاعدة البيانات

عرض كود تنفيذ تخزين Redis المؤقت

مثال على الكود (إضافة تخزين Redis المؤقت):

javascript

// الحصول على تفاصيل المنتج — استعلام Redis أولاً، ثم قاعدة البيانات عند الحاجة
async function getProduct(productId) {
  // 1. استعلام Redis أولاً
  const cacheKey = `product:${productId}`
  const cached = await redis.get(cacheKey)

  if (cached) {
    // إصابة! إرجاع مباشر، حوالي 1 ميلي ثانية
    return JSON.parse(cached)
  }

  // 2. فقدان في التخزين المؤقت، استعلام قاعدة البيانات
  const product = await db.query(
    'SELECT * FROM products WHERE id = ?',
    [productId]
  )

  // 3. بعد الاستعلام، الكتابة في Redis مع صلاحية 30 دقيقة
  await redis.setex(
    cacheKey,
    1800,  // 30 دقيقة = 1800 ثانية
    JSON.stringify(product)
  )

  return product
}

مقارنة تحسين الأداء:

السيناريو	بدون تخزين مؤقت	مع Redis	مضاعف التحسين
استعلام منتج عادي	50ms	5ms (عند الإصابة)	10 أضعاف
استعلام منتج رائج	80ms	1ms (نسبة إصابة 95%)	80 ضعفًا
QPS لقاعدة البيانات	2000 (حمولة كاملة)	200 (التخزين المؤقت يحجز 90%)	تخفيف ضغط قاعدة البيانات 10 أضعاف
أقصى تزامن للنظام	2000 مستخدم	20000 مستخدم	10 أضعاف

التحسينات التي تحققت:

سرعة الاستجابة: عند الإصابة، زمن الاستجابة ينخفض من 50ms إلى 1-5ms
قدرة التزامن: عدد المستخدمين الذي يتحمله النظام يرتفع من 2000 إلى 20000
ضغط قاعدة البيانات: 90% من الطلبات يحجزها Redis، CPU قاعدة البيانات ينخفض من 80% إلى 20%
تجربة المستخدم: سرعة تحميل الصفحات تتحسن بشكل ملحوظ، وتقل شكاوى المستخدمين

التحديات الجديدة:

مشكلة تناسق التخزين المؤقت: تغير سعر المنتج، وتحدثت قاعدة البيانات، لكن التخزين المؤقت ما زال يحمل القيمة القديمة
اختراق التخزين المؤقت (Cache Penetration): استعلامات خبيثة عن معرفات منتجات غير موجودة (مثل id=-1)، تخترق إلى قاعدة البيانات في كل مرة
انهيار التخزين المؤقت (Cache Avalanche): بعد إعادة تشغيل النظام، تنتهي صلاحية جميع البيانات المخزنة مؤقتًا في نفس الوقت، وتصل كمية هائلة من الطلبات إلى قاعدة البيانات دفعة واحدة
نقطة فشل وحيدة في Redis: تعطل Redis يؤدي إلى وصول جميع الطلبات مباشرة إلى قاعدة البيانات، وربما ينهار النظام

الحلول:

تناسق التخزين المؤقت: عند تحديث قاعدة البيانات، حذف التخزين المؤقت بالتزامن
اختراق التخزين المؤقت: تخزين البيانات غير الموجودة أيضًا في Redis (بقيمة فارغة، مع TTL قصير، مثل 5 دقائق)
انهيار التخزين المؤقت: إضافة قيمة عشوائية لوقت انتهاء الصلاحية، لتجنب الانتهاء المتزامن

بعد إدخال Redis، تحسن أداء النظام بشكل كبير، لكن ظهرت مشاكل جديدة. بدأ الفريق في دراسة كيفية حل هذه المشاكل المتعلقة بالتخزين المؤقت.

3.3 المرحلة الثالثة: بنية التخزين المؤقت متعددة المستويات — تحسين الأداء 5 أضعاف إضافية

الخلفية: نما عدد المستخدمين إلى 100 ألف، وحتى Redis أصبح عنق زجاجة (الحد الأقصى لـ QPS لنسخة Redis الفردية حوالي 100 ألف)، فقرر الفريق إدخال التخزين المؤقت متعدد المستويات.

الحزمة التقنية:

تخزين مؤقت L1: تخزين مؤقت محلي للتطبيق (Caffeine)
تخزين مؤقت L2: مجموعة Redis
قاعدة البيانات: مجموعة MySQL رئيسية/تابعة

بنية النظام:

طلب المستخدم → تخزين CDN المؤقت (الموارد الثابتة) → خادم التطبيق
                                        ↓
                          L1: تخزين مؤقت محلي (Caffeine) → فقدان → L2: Redis → فقدان → MySQL

خصائص هذه المرحلة:

✅ المزايا: أداء فائق (التخزين المؤقت المحلي يحتاج 0.1 ميلي ثانية فقط)، توفر عالٍ (تعطل Redis لا يؤثر على البيانات الرائجة)
❌ العيوب: بنية معقدة، صعوبة ضمان تناسق التخزين المؤقت متعدد المستويات

عرض كود تنفيذ التخزين المؤقت متعدد المستويات

مثال على الكود (تخزين مؤقت محلي + Redis بمستويين):

javascript

// استخدام Caffeine للتخزين المؤقت المحلي
const caffeine = require('caffeine')
const localCache = new caffeine.Cache({
  max: 1000,              // تخزين 1000 عنصر كحد أقصى
  ttl: 30,                // صلاحية 30 ثانية
})

// الحصول على تفاصيل المنتج — تخزين مؤقت بمستويين
async function getProduct(productId) {
  const cacheKey = `product:${productId}`

  // L1: استعلام التخزين المؤقت المحلي أولاً (الأسرع، حوالي 0.1 ميلي ثانية)
  const localCached = localCache.get(cacheKey)
  if (localCached) {
    console.log('L1 إصابة')
    return localCached
  }

  // L2: فقدان في المحلي، استعلام Redis (سريع، حوالي 1 ميلي ثانية)
  const redisCached = await redis.get(cacheKey)
  if (redisCached) {
    console.log('L2 إصابة، إعادة تعبئة L1')
    const product = JSON.parse(redisCached)
    // إعادة تعبئة التخزين المؤقت المحلي
    localCache.set(cacheKey, product)
    return product
  }

  // L3: فقدان في Redis أيضًا، استعلام قاعدة البيانات (الأبطأ، حوالي 10 ميلي ثانية)
  console.log('L3 إصابة، إعادة تعبئة L2 و L1')
  const product = await db.query(
    'SELECT * FROM products WHERE id = ?',
    [productId]
  )

  // إعادة تعبئة Redis (صلاحية 30 دقيقة)
  await redis.setex(cacheKey, 1800, JSON.stringify(product))
  // إعادة تعبئة التخزين المؤقت المحلي
  localCache.set(cacheKey, product)

  return product
}

مقارنة أداء التخزين المؤقت متعدد المستويات:

مستوى التخزين المؤقت	زمن الاستجابة	نسبة الإصابة	البيانات المناسبة للتخزين
L1: تخزين مؤقت محلي	~0.1 ميلي ثانية	70% (شديد الرواج)	المنتجات الرائجة، إعدادات النظام، جلسات المستخدم
L2: تخزين Redis المؤقت	~1 ميلي ثانية	25% (شائع الرواج)	معظم بيانات المنتجات، تجميع التعليقات
L3: قاعدة البيانات	~10 ميلي ثانية	5% (بيانات باردة)	جميع بيانات المنتجات الكاملة

تحسين الأداء الكلي:

متوسط زمن الاستجابة: 5ms (المرحلة الثانية) → 1ms (المرحلة الثالثة)، تحسين 5 أضعاف إضافية
أقصى تزامن للنظام: 20 ألف مستخدم (المرحلة الثانية) → 100 ألف مستخدم (المرحلة الثالثة)، تحسين 5 أضعاف
QPS لقاعدة البيانات: 200 (المرحلة الثانية) → 50 (المرحلة الثالثة)، تخفيض 4 أضعاف إضافية

المشاكل الجديدة التي حُلَّت في هذه المرحلة:

تناسق التخزين المؤقت المحلي: التخزين المؤقت المحلي لعدة نسخ من التطبيق قد يكون غير متسق (النسخة A تخزن السعر القديم، والنسخة B تخزن السعر الجديد)
- الحل: تعيين TTL قصير للتخزين المؤقت المحلي (30 ثانية)، لتقليص نافذة عدم التناسق
التسخين المسبق للتخزين المؤقت: بعد إعادة تشغيل النظام، يكون التخزين المؤقت المحلي فارغًا، وتخترق كمية كبيرة من الطلبات إلى Redis
- الحل: عند بدء تشغيل النظام، تحميل البيانات الرائجة بشكل نشط إلى التخزين المؤقت المحلي

بنية التخزين المؤقت متعددة المستويات تُستخدم على نطاق واسع في شركات الإنترنت الكبيرة (مثل تاوباو، JD.com)، وهي قادرة على دعم وصول بمستوى ملايين QPS.

3.4 صورة شاملة لتطور بنية التخزين المؤقت

المرحلة	البنية	زمن الاستجابة	أقصى تزامن	التغيير الأساسي
المرحلة الأولى: بدون تخزين مؤقت	تطبيق → قاعدة بيانات	50ms	2000 مستخدم	قاعدة بيانات عارية، أداء ضعيف
المرحلة الثانية: تخزين مؤقت أحادي المستوى	تطبيق → Redis → قاعدة بيانات	5ms	20000 مستخدم	إدخال Redis، تحسين الأداء 10 أضعاف
المرحلة الثالثة: تخزين مؤقت متعدد المستويات	تطبيق → تخزين محلي → Redis → قاعدة بيانات	1ms	100000 مستخدم	تخزين محلي + Redis، تحسين الأداء 5 أضعاف إضافية

📊 ماذا يمكنك أن ترى من الجدول؟

المرحلة الأولى → المرحلة الثانية: نقلة نوعية. بعد إدخال Redis، تحسن الأداء 10 أضعاف، وانخفض ضغط قاعدة البيانات بنسبة 90%. هذه هي الخطوة الحاسمة من "قابل للاستخدام" إلى "كافٍ".

المرحلة الثانية → المرحلة الثالثة: تحسين فائق. بعد إدخال التخزين المؤقت المحلي، تحسن الأداء 5 أضعاف إضافية. هذا هو التقدم من "كافٍ" إلى "ممتاز"، مناسب لسيناريوهات الأحمال الضخمة.

توصيات عملية:

عدد المستخدمين < 10 آلاف: المرحلة الأولى (بدون تخزين مؤقت) كافية، لكن يُنصح بإدخال Redis (المرحلة الثانية)
عدد المستخدمين 10-100 ألف: المرحلة الثانية (Redis) هي الخيار الأفضل
عدد المستخدمين > 100 ألف: النظر في المرحلة الثالثة (تخزين مؤقت متعدد المستويات)، مع الانتباه لتعقيد التناسق

خلاصة: تطور بنية التخزين المؤقت ليس مجرد "إضافة المزيد من طبقات التخزين المؤقت"، بل هو اختيار البنية المناسبة وفقًا لحجم الحركة — الإفراط في التصميم يزيد التعقيد، والتصميم الناقص يؤدي إلى اختناقات في الأداء.

4. المشاكل الكلاسيكية الثلاث للتخزين المؤقت: الاختراق، والانهيار الموضعي، والانهيار الشامل

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

4.1 اختراق التخزين المؤقت (Cache Penetration): الاستعلام عن بيانات غير موجودة

تعريف المشكلة: الاستعلام عن بيانات غير موجودة (مثل id=-1)، وهي غير موجودة في التخزين المؤقت (لأنها لم تُخزن أبدًا) ولا في قاعدة البيانات، مما يؤدي إلى اختراق كل طلب مباشرة إلى قاعدة البيانات.

🤔 تشبيه "البحث عن كتاب" لاختراق التخزين المؤقت

تخيل أنك في المكتبة تبحث عن كتاب، وتسأل أمين المكتبة: "هل يوجد كتاب 'الكتاب غير الموجود'؟"

السير الطبيعي:

أمين المكتبة يبحث في الفهرس: "لا يوجد هذا الكتاب"
تغادر

سيناريو اختراق التخزين المؤقت:

المرة الأولى التي تسأل فيها، أمين المكتبة يبحث في قاعدة البيانات: "لا يوجد"، ويخبرك
المرة الثانية التي تسأل فيها، أمين المكتبة يبحث في قاعدة البيانات مرة أخرى: "لا يوجد"
المرة المائة التي تسأل فيها، أمين المكتبة ما زال يبحث في قاعدة البيانات: "لا يوجد"

المشكلة: أمين المكتبة (قاعدة البيانات) أُنهك، يبحث في قاعدة البيانات في كل مرة، حتى لو كانت الإجابة دائمًا "لا يوجد".

الحل: أمين المكتبة يتذكر أن "'الكتاب غير الموجود' غير موجود"، وفي المرة القادمة عندما تسأل، يقول مباشرة "لا يوجد" دون البحث في قاعدة البيانات. هذا هو تخزين الكائن الفارغ.

سيناريوهات واقعية:

مهاجمون خبيثون يبنون أعدادًا كبيرة من المعرفات غير الموجودة للاستعلام (مثل id=-1, id=999999999)
زواحف تتصفح مسارات موارد غير موجودة (مثل /api/products/invalid-id)
أخطاء في منطق العمل تؤدي للاستعلام عن بيانات غير صالحة

الحل 1: تخزين الكائن الفارغ

javascript

async function getProduct(productId) {
  const cacheKey = `product:${productId}`

  // 1. استعلام التخزين المؤقت أولاً
  const cached = await redis.get(cacheKey)
  if (cached !== null) {
    // انتبه: cached قد يكون النص "null"
    if (cached === 'null') {
      // المخزن هو "كائن فارغ"، يعني أن هذه البيانات غير موجودة في قاعدة البيانات
      return null
    }
    return JSON.parse(cached)
  }

  // 2. استعلام قاعدة البيانات
  const product = await db.query(
    'SELECT * FROM products WHERE id = ?',
    [productId]
  )

  // 3. حتى لو لم توجد في قاعدة البيانات، خزن "null" مع TTL قصير (مثل 5 دقائق)
  if (!product) {
    await redis.setex(cacheKey, 300, 'null')
    return null
  }

  // 4. وجدت البيانات، تخزين طبيعي
  await redis.setex(cacheKey, 1800, JSON.stringify(product))
  return product
}

الحل 2: مرشح بلوم (Bloom Filter)

مرشح بلوم هو أداة "للحكم السريع على وجود البيانات"، إنه مثل "فهرس فائق":

📖 ما هو مرشح بلوم؟

تخيل أن لديك "صندوقًا أسود سحريًا":

تسأله: "هل المنتج ذو المعرف 123 موجود؟"
يقول: "بالتأكيد غير موجود" → إذن هو غير موجود فعلاً، لا حاجة للاستعلام من قاعدة البيانات
يقول: "قد يكون موجودًا" → استعلم من قاعدة البيانات للتأكيد

الخصائص:

لا يفوت أبدًا: إذا قال إنه غير موجود، فهو غير موجود فعلاً
قد يخطئ في الإيجاب: إذا قال إنه قد يكون موجودًا، فمن الممكن أنه غير موجود فعليًا (الاحتمال منخفض، وقابل للتعديل)

القيمة: مرشح بلوم يمكنه حجز 99% من طلبات "غير موجود" قبل حتى الوصول للتخزين المؤقت، مما يحمي قاعدة البيانات.

javascript

// استخدام مرشح بلوم
const { BloomFilter } = require('bloom-filters')

// تهيئة مرشح بلوم (بافتراض وجود مليون معرف منتج كحد أقصى)
const bloomFilter = new BloomFilter(1000000, 0.01)  // نسبة خطأ 1%

// عند بدء تشغيل النظام، إضافة جميع معرفات المنتجات إلى مرشح بلوم
async function initBloomFilter() {
  const allIds = await db.query('SELECT id FROM products')
  allIds.forEach(row => {
    bloomFilter.add(row.id)
  })
}

// قبل الاستعلام عن منتج، استخدم مرشح بلوم أولاً للحكم
async function getProduct(productId) {
  // 1. استخدم مرشح بلوم أولاً للحكم
  if (!bloomFilter.has(productId)) {
    // بالتأكيد غير موجود، إرجاع null مباشرة، دون استعلام قاعدة البيانات
    console.log('مرشح بلوم يحجز: المنتج غير موجود')
    return null
  }

  // 2. مرشح بلوم يقول "قد يكون موجودًا"، استعلم التخزين المؤقت
  const cached = await redis.get(`product:${productId}`)
  if (cached) {
    return JSON.parse(cached)
  }

  // 3. فقدان في التخزين المؤقت، استعلام قاعدة البيانات
  const product = await db.query(
    'SELECT * FROM products WHERE id = ?',
    [productId]
  )

  if (!product) {
    // مرشح بلوم أخطأ في الإيجاب (احتمال منخفض جدًا)، غير موجود فعليًا
    await redis.setex(`product:${productId}`, 300, 'null')
    return null
  }

  // 4. وجدت البيانات، كتابة في التخزين المؤقت
  await redis.setex(`product:${productId}`, 1800, JSON.stringify(product))
  return product
}

4.2 انهيار التخزين المؤقت الموضعي (Cache Breakdown): انتهاء صلاحية البيانات الرائجة

تعريف المشكلة: بيانات رائجة معينة (مثل منتج رائج، أخبار رائجة) تنتهي صلاحيتها في التخزين المؤقت (وصول TTL لنهايته)، وفي هذه اللحظة تصل كمية كبيرة من الطلبات المتزامنة معًا، وتستعلم جميعها من قاعدة البيانات، مما يؤدي إلى زيادة مفاجئة في ضغط قاعدة البيانات.

🤔 تشبيه "التزاحم على كتاب" لانهيار التخزين المؤقت الموضعي

تخيل أن المكتبة لديها كتاب "هاري بوتر"، شديد الرواج، و100 شخص يريدون استعارته.

الوضع الطبيعي:

المكتبة تضع "هاري بوتر" على "منصة الإعارة" (التخزين المؤقت)
الجميع يأخذونه مباشرة من منصة الإعارة، دون حاجة للذهاب إلى الرف

سيناريو انهيار التخزين المؤقت الموضعي:

انتهت صلاحية "هاري بوتر" على منصة الإعارة (أُعيد إلى الرف)
100 شخص يأتون معًا للاستعارة، يكتشفون أنه ليس على منصة الإعارة
100 شخص يندفعون جميعًا إلى الرف (قاعدة البيانات)
أمين الرف (قاعدة البيانات) يُسحق بالزحام

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

سيناريوهات واقعية:

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

الحل 1: القفل المتبادل (Mutex Lock)

javascript

async function getProduct(productId) {
  const cacheKey = `product:${productId}`

  // 1. استعلام التخزين المؤقت أولاً
  const cached = await redis.get(cacheKey)
  if (cached) {
    return JSON.parse(cached)
  }

  // 2. فقدان في التخزين المؤقت، الحصول على قفل موزع
  const lockKey = `lock:${productId}`
  const lock = await redis.set(lockKey, '1', 'NX', 'EX', 10)  // قفل لمدة 10 ثوانٍ

  if (lock === 'OK') {
    // 3. حصل على القفل، استعلام قاعدة البيانات
    console.log('نجح الحصول على القفل، استعلام قاعدة البيانات')
    const product = await db.query(
      'SELECT * FROM products WHERE id = ?',
      [productId]
    )

    // 4. كتابة في التخزين المؤقت
    await redis.setex(cacheKey, 1800, JSON.stringify(product))

    // 5. تحرير القفل
    await redis.del(lockKey)
    return product
  } else {
    // 6. لم يحصل على القفل، انتظر 50ms ثم أعد المحاولة
    console.log('فشل الحصول على القفل، انتظار ثم إعادة المحاولة')
    await new Promise(resolve => setTimeout(resolve, 50))
    return getProduct(productId)  // إعادة محاولة تكرارية
  }
}

الحل 2: انتهاء الصلاحية المنطقي (Logical Expiration)

javascript

async function getProduct(productId) {
  const cacheKey = `product:${productId}`

  // 1. استعلام التخزين المؤقت
  const cached = await redis.get(cacheKey)
  if (cached) {
    const data = JSON.parse(cached)

    // 2. التحقق من وقت انتهاء الصلاحية المنطقي
    if (Date.now() < data.expireTime) {
      // لم تنتهِ صلاحيته، إرجاع مباشر
      return data.product
    } else {
      // 3. انتهت الصلاحية المنطقية، إعادة بناء التخزين المؤقت بشكل غير متزامن، مع إرجاع البيانات القديمة
      console.log('انتهاء صلاحية منطقي، إعادة بناء غير متزامنة للتخزين المؤقت')
      rebuildCacheAsync(productId)  // إعادة بناء غير متزامنة
      return data.product  // إرجاع البيانات القديمة
    }
  }

  // 4. التخزين المؤقت غير موجود (تحميل أولي)، استعلام متزامن من قاعدة البيانات
  const product = await db.query(
    'SELECT * FROM products WHERE id = ?',
    [productId]
  )

  // 5. كتابة في التخزين المؤقت (مع وقت انتهاء صلاحية منطقي)
  const cacheData = {
    product: product,
    expireTime: Date.now() + 30 * 60 * 1000  // انتهاء صلاحية منطقي بعد 30 دقيقة
  }
  await redis.set(cacheKey, JSON.stringify(cacheData))

  return product
}

// إعادة بناء التخزين المؤقت بشكل غير متزامن
async function rebuildCacheAsync(productId) {
  const lockKey = `rebuild:${productId}`
  const lock = await redis.set(lockKey, '1', 'NX', 'EX', 10)

  if (lock === 'OK') {
    console.log('بدء إعادة البناء غير المتزامن للتخزين المؤقت')
    const product = await db.query(
      'SELECT * FROM products WHERE id = ?',
      [productId]
    )

    const cacheData = {
      product: product,
      expireTime: Date.now() + 30 * 60 * 1000
    }
    await redis.set(`product:${productId}`, JSON.stringify(cacheData))
    await redis.del(lockKey)
    console.log('اكتملت إعادة البناء غير المتزامن للتخزين المؤقت')
  }
}

4.3 انهيار التخزين المؤقت الشامل (Cache Avalanche): انتهاء صلاحية كمية كبيرة من البيانات في نفس الوقت

تعريف المشكلة: كمية كبيرة من البيانات المخزنة مؤقتًا تنتهي صلاحيتها في نفس اللحظة (أو تعطل Redis)، مما يؤدي إلى اختراق جميع الطلبات إلى قاعدة البيانات في نفس الوقت، وسحق قاعدة البيانات فورًا.

🤔 تشبيه "إعادة الكتب الجماعية للمكتبة" لانهيار التخزين المؤقت الشامل

تخيل أن "منصة الإعارة" (التخزين المؤقت) في المكتبة تحوي 1000 كتاب.

الوضع الطبيعي:

أوقات إعادة هذه الكتب متفرقة: بعضها يُعاد اليوم، وبعضها غدًا، وبعضها بعد غد
كل يوم فقط عشرات الكتب تنتهي مدتها، وأمين المكتبة (قاعدة البيانات) يتعامل معها بسهولة

سيناريو انهيار التخزين المؤقت الشامل:

بعد إعادة تشغيل النظام، أمين المكتبة يضبط جميع الكتب الـ 1000 على "انتهاء المدة بعد 30 يومًا"
بعد 30 يومًا، جميع الكتب الـ 1000 تنتهي مدتها في نفس الوقت
1000 شخص يأتون معًا لاستعارة الكتب، يكتشفون أنها ليست على منصة الإعارة
1000 شخص يندفعون جميعًا إلى الرف
أمين الرف (قاعدة البيانات) يُسحق فورًا

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

سيناريوهات واقعية:

بعد إعادة تشغيل النظام، جميع التخزين المؤقت يُعاد بناؤه من الصفر، مع تعيين TTL متطابق (مثل 30 دقيقة)
مهام مجدولة تقوم بتحديث التخزين المؤقت دفعة واحدة، مع تعيين أوقات انتهاء صلاحية متطابقة
تعطل خدمة التخزين المؤقت (Redis) أو انقسام الشبكة

الحل 1: TTL عشوائي

javascript

async function getProduct(productId) {
  const cacheKey = `product:${productId}`

  const cached = await redis.get(cacheKey)
  if (cached) {
    return JSON.parse(cached)
  }

  const product = await db.query(
    'SELECT * FROM products WHERE id = ?',
    [productId]
  )

  // الأساس: إضافة قيمة عشوائية (±5 دقائق) على TTL الأساسي (30 دقيقة)
  const baseTTL = 1800  // 30 دقيقة
  const randomOffset = Math.floor(Math.random() * 600) - 300  // -5 إلى +5 دقائق
  const finalTTL = baseTTL + randomOffset

  console.log(`TTL التخزين المؤقت: ${finalTTL} ثانية (${Math.floor(finalTTL / 60)} دقيقة)`)
  await redis.setex(cacheKey, finalTTL, JSON.stringify(product))

  return product
}

الحل 2: التسخين المسبق للتخزين المؤقت (Cache Preheating)

javascript

// عند بدء تشغيل النظام، تحميل البيانات الرائجة بشكل نشط إلى التخزين المؤقت
async function cacheWarmup() {
  console.log('بدء التسخين المسبق للتخزين المؤقت...')

  // 1. استعلام أكثر 1000 منتج رواجًا (مرتبة حسب عدد الزيارات)
  const hotProducts = await db.query(`
    SELECT * FROM products
    ORDER BY view_count DESC
    LIMIT 1000
  `)

  // 2. كتابة دفعة في Redis
  for (const product of hotProducts) {
    const cacheKey = `product:${product.id}`
    const ttl = 1800 + Math.floor(Math.random() * 600)  // 30 دقيقة ± 5 دقائق
    await redis.setex(cacheKey, ttl, JSON.stringify(product))
  }

  console.log(`اكتمل التسخين المسبق للتخزين المؤقت، تم تحميل ${hotProducts.length} منتج رائج`)
}

// تنفيذ عند بدء تشغيل التطبيق
cacheWarmup()

الحل 3: الانصهار والتخفيض (Circuit Breaker)

javascript

// استخدام قاطع الدائرة لحماية قاعدة البيانات
const CircuitBreaker = require('opossum')

// إعداد قاطع الدائرة
const dbQueryBreaker = new CircuitBreaker(
  async (productId) => {
    return await db.query('SELECT * FROM products WHERE id = ?', [productId])
  },
  {
    timeout: 3000,  // مهلة 3 ثوانٍ
    errorThresholdPercentage: 50,  // انصهار عندما يتجاوز معدل الخطأ 50%
    resetTimeout: 30000  // محاولة الاستئناف بعد 30 ثانية
  }
)

// معالجة التخفيض بعد الانصهار
dbQueryBreaker.fallback(() => {
  console.log('انصهار قاعدة البيانات، إرجاع بيانات مخفضة')
  return {
    id: productId,
    name: 'الخدمة مشغولة، يرجى المحاولة لاحقًا',
    status: 'degraded'
  }
})

async function getProduct(productId) {
  const cacheKey = `product:${productId}`

  const cached = await redis.get(cacheKey)
  if (cached) {
    return JSON.parse(cached)
  }

  // استعلام قاعدة البيانات من خلال قاطع الدائرة
  const product = await dbQueryBreaker.fire(productId)

  if (product.status === 'degraded') {
    return product  // إرجاع بيانات مخفضة
  }

  await redis.setex(cacheKey, 1800, JSON.stringify(product))
  return product
}

👇 جرب بنفسك: العرض التوضيحي التالي يقارن بين سيناريوهات وحلول المشاكل الثلاث: الاختراق، والانهيار الموضعي، والانهيار الشامل:

What is cache penetration?

A request queries nonexistent data, such as malicious id=-1. The cache misses and the database also has no record, so every request hits the database.

Scenario simulation

🔥

Request id=-999

↓

❌

Cache miss

↓

🗄️

Database query (not found)

Database pressure

Solutions

1Bloom Filter

Add a filter before the cache to quickly decide that an id definitely does not exist.
Can prove absence, but may have false positives.

2Cache empty objects

When a record does not exist, cache a NULL value with a short TTL such as 5 minutes.

Problem comparison

Problem	Cause	Impact	Main fixes
Cache penetration	Querying nonexistent data	Higher database pressure	Bloom filter, cache empty objects
Cache breakdown	Hot data expires	Instant database pressure	Mutex lock, logical expiration
Cache avalanche	Many entries expire together	Database overload	Random TTL, cache warm-up

5. استراتيجية تناسق التخزين المؤقت: كيفية مزامنة التخزين المؤقت مع قاعدة البيانات

جوهر التخزين المؤقت هو نسخ البيانات، والنسخة والمصدر الأصلي (قاعدة البيانات) بينهما حتمًا نافذة زمنية من عدم التناسق. كيفية التحكم في هذه النافذة الزمنية هو التحدي الأساسي في تصميم التخزين المؤقت.

5.1 لماذا يحدث عدم تناسق بين التخزين المؤقت وقاعدة البيانات؟

🤔 تشبيه "الملصق والكتاب" لعدم التناسق

تخيل أنك كتبت على ملصق: "هاتف مينغ: 123456"، هذه نسخة من دليل هاتفك (قاعدة البيانات).

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

تحدِّث دليل الهاتف، وتغير هاتف مينغ إلى "7654321"
لكنك تنسى تحديث الملصق
في المرة القادمة عندما تبحث عن الرقم، تنظر إلى الملصق، وما زال القديم "123456"

المشكلة: الملصق (التخزين المؤقت) أصبح غير متسق مع دليل الهاتف (قاعدة البيانات).

السبب: حدثت البيانات الأصلية، لكن لم تتم مزامنة النسخة. في أنظمة الحاسوب، هذا يحدث لأن "تحديث قاعدة البيانات" و"تحديث التخزين المؤقت" عمليتان منفصلتان، بينهما نافذة زمنية قد تتداخل فيها عمليات أخرى.

سيناريو تزامن واقعي:

الوقت	الخيط A (تحديث عمر المستخدم)	الخيط B (استعلام المستخدم)	قاعدة البيانات	التخزين المؤقت
T1	بدء تحديث قاعدة البيانات	-	age=20	age=20
T2	تحديث قاعدة البيانات إلى age=25	استعلام التخزين المؤقت، إصابة age=20	age=25	age=20 ❌
T3	حذف التخزين المؤقت	-	age=25	-
T4	-	-	age=25	تحميل age=25 من قاعدة البيانات ✅

المشكلة: في لحظة T2، الخيط B قرأ القيمة القديمة 20 من التخزين المؤقت، بينما قاعدة البيانات كانت 25. هذا هو عدم تناسق التخزين المؤقت.

5.2 أفضل ممارسة: تحديث قاعدة البيانات أولاً، ثم حذف التخزين المؤقت

🤔 لماذا "الحذف" وليس "التحديث" للتخزين المؤقت؟

قد تتساءل: لماذا لا "نحدّث التخزين المؤقت" مباشرة، بل "نحذف التخزين المؤقت"؟

مشاكل تحديث التخزين المؤقت:

في حالة التحديث المتزامن، قد يحدث أن الخيط A يحدث التخزين المؤقت أولاً، ثم الخيط B يحدث قاعدة البيانات دون تحديث التخزين المؤقت
تكلفة تحديث التخزين المؤقت قد تكون عالية (مثل الحاجة لتجميع بيانات من جداول متعددة)
إذا حُذفت البيانات بعد التحديث، يكون الجهد ضائعًا

مزايا حذف التخزين المؤقت:

في المرة القادمة للاستعلام، يُحمَّل تلقائيًا أحدث البيانات من قاعدة البيانات (تحميل كسول)
تجنب البيانات القذرة الناتجة عن التحديث المتزامن
بسيط وموثوق، وهو أفضل ممارسة في الصناعة

السير القياسي:

javascript

// تحديث معلومات المنتج
async function updateProduct(productId, updateData) {
  // 1. تحديث قاعدة البيانات أولاً
  await db.query(
    'UPDATE products SET name = ?, price = ? WHERE id = ?',
    [updateData.name, updateData.price, productId]
  )

  // 2. ثم حذف التخزين المؤقت (وليس تحديثه!)
  await redis.del(`product:${productId}`)

  // 3. في المرة القادمة للاستعلام، فقدان في التخزين المؤقت، تحميل تلقائي لأحدث البيانات من قاعدة البيانات
  console.log('اكتمل التحديث، تم حذف التخزين المؤقت')
}

لماذا "تحديث قاعدة البيانات أولاً، ثم حذف التخزين المؤقت" هو الحل الأمثل

مقارنة بين ثلاث استراتيجيات للتحديث:

الاستراتيجية 1: تحديث التخزين المؤقت أولاً، ثم تحديث قاعدة البيانات ❌ غير موصى بها

javascript

// المشكلة: إذا فشل تحديث قاعدة البيانات، التخزين المؤقت يحمل القيمة الجديدة، وقاعدة البيانات تحمل القديمة، عدم تناسق
await redis.set('product:1', newProduct)  // نجح تحديث التخزين المؤقت
await db.query('UPDATE products SET ...')  // فشل تحديث قاعدة البيانات!
// النتيجة: التخزين المؤقت قيمة جديدة، قاعدة البيانات قيمة قديمة، عدم تناسق دائم!

الاستراتيجية 2: حذف التخزين المؤقت أولاً، ثم تحديث قاعدة البيانات ❌ غير موصى بها

javascript

// المشكلة: بين الحذف والتحديث، خيط آخر يستعلم، ويحمل البيانات القديمة إلى التخزين المؤقت
await redis.del('product:1')  // حذف التخزين المؤقت
// في هذه اللحظة، الخيط B يستعلم، يجد التخزين المؤقت فارغًا، يستعلم قاعدة البيانات (لا تزال القيمة القديمة)، يكتب في التخزين المؤقت
await db.query('UPDATE products SET ...')  // تحديث قاعدة البيانات
// النتيجة: التخزين المؤقت قيمة قديمة، قاعدة البيانات قيمة جديدة، عدم تناسق!

الاستراتيجية 3: تحديث قاعدة البيانات أولاً، ثم حذف التخزين المؤقت ✅ موصى بها

javascript

// المزايا: تحديث قاعدة البيانات يحصل على قفل الصف، الخيوط الأخرى يجب أن تنتظر، تجنب البيانات القذرة
await db.query('UPDATE products SET ...')  // تحديث قاعدة البيانات (يحصل على قفل الصف)
await redis.del('product:1')  // حذف التخزين المؤقت
// حتى لو فشل حذف التخزين المؤقت، فقط سيؤدي للرجوع للمصدر في الاستعلام التالي، دون التسبب في وجود بيانات قذرة لفترة طويلة

لماذا الاستراتيجية 3 هي الأمثل؟

حماية قفل قاعدة البيانات: عملية التحديث تحصل على قفل الصف، مما يجبر عمليات القراءة والكتابة الأخرى على الانتظار
تأثير فشل الحذف ضئيل: حتى لو فشل حذف التخزين المؤقت، فقط سيعود الاستعلام التالي للمصدر، دون التسبب في بيانات قذرة
بسيط وموثوق: لا حاجة لمنطق معقد إضافي

5.3 الحذف المزدوج المؤجل: ضمان التناسق في السيناريوهات القصوى

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

السير:

1. حذف التخزين المؤقت
2. تحديث قاعدة البيانات
3. انتظار فترة (مثل 500ms)
4. حذف التخزين المؤقت مرة أخرى

javascript

async function updateProduct(productId, updateData) {
  const cacheKey = `product:${productId}`

  // 1. الحذف الأول للتخزين المؤقت
  await redis.del(cacheKey)

  // 2. تحديث قاعدة البيانات
  await db.query(
    'UPDATE products SET name = ?, price = ? WHERE id = ?',
    [updateData.name, updateData.price, productId]
  )

  // 3. انتظار 500ms (للسماح باستكمال استعلامات الخيوط الأخرى)
  await new Promise(resolve => setTimeout(resolve, 500))

  // 4. الحذف الثاني للتخزين المؤقت (حذف البيانات القديمة التي ربما حمّلتها خيوط أخرى)
  await redis.del(cacheKey)

  console.log('اكتمل الحذف المزدوج المؤجل، تمت مزامنة البيانات')
}

مقارنة استراتيجيات التناسق الثلاث:

الاستراتيجية	مستوى التناسق	تأثير الأداء	التعقيد	السيناريو المناسب
تحديث قاعدة البيانات أولاً، ثم حذف التخزين المؤقت	تناسق نهائي (نافذة عدم تناسق < 100ms)	منخفض	منخفض	معظم السيناريوهات، موصى به كحل افتراضي
الحذف المزدوج المؤجل	تناسق نهائي قوي (نافذة عدم تناسق < 10ms)	متوسط (تأخير 500ms)	متوسط	السيناريوهات ذات متطلبات التناسق العالية (مثل المالية، المخزون)
حذف التخزين المؤقت أولاً، ثم تحديث قاعدة البيانات	ضعيف (نافذة عدم تناسق كبيرة)	منخفض	منخفض	❌ غير موصى به، عرضة لعدم التناسق

👇 جرب بنفسك: العرض التوضيحي التالي يقارن بين تأثيرات استراتيجيات التناسق الثلاث. اضغط على "تحديث البيانات"، ولاحظ تغير التناسق بين التخزين المؤقت وقاعدة البيانات:

Update DB, then delete cache

Low complexity and a short inconsistency window; works for most products.

Delayed double delete

Deletes cache twice to reduce stale reads in high consistency scenarios.

Avoid delete-before-update

Deleting cache first can reload old database values under concurrency.

6. تطبيق عملي: بناء نظام تخزين مؤقت كامل

بعد كل هذه المبادئ، لننظر إلى حالة واقعية: كيفية تصميم نظام تخزين مؤقت كامل لصفحة تفاصيل منتج في متجر إلكتروني.

6.1 تحليل سيناريو العمل

المتطلبات: عندما يزور المستخدم صفحة تفاصيل المنتج، يجب عرض معلومات المنتج الأساسية والسعر والمخزون والتقييمات وغيرها من البيانات.

الخصائص:

قراءة أكثر من الكتابة: 100 استعلام، تحديث واحد (نسبة القراءة/الكتابة 100:1)
تركز الرواج: 20% من المنتجات تساهم بـ 80% من الحركة
تعقيد البيانات: معلومات المنتج الأساسية + السعر + المخزون + تجميع التقييمات
متطلبات التناسق: السعر والمخزون يتطلبان تناسقًا قويًا، والباقي يمكن أن يكون تناسقًا نهائيًا

مؤشرات الأداء:

زمن استجابة P99 < 100ms (99% من الطلبات تعود خلال 100ms)
ذروة QPS لقاعدة البيانات < 5000
نسبة إصابة التخزين المؤقت > 95%

6.2 تصميم البنية

بنية تخزين مؤقت متعددة المستويات:

طلب المستخدم
  ↓
تخزين CDN المؤقت (الموارد الثابتة: الصور، CSS، JS)
  ↓ فقدان
تخزين Nginx المؤقت المحلي (تجميع معلومات المنتج الأساسية)
  ↓ فقدان
خادم التطبيق
  ↓
  ├─ L1: تخزين مؤقت محلي (Caffeine، المنتجات الرائجة)
  │   ↓ فقدان
  ├─ L2: تخزين Redis المؤقت (جميع بيانات المنتجات)
  │   ↓ فقدان
  └─ L3: قاعدة بيانات MySQL (جميع البيانات الكاملة)

6.3 تنفيذ الكود الأساسي

تنفيذ كامل للتخزين المؤقت متعدد المستويات (نسخة مبسطة):

javascript

const caffeine = require('caffeine')

// L1: تخزين مؤقت محلي (صلاحية 30 ثانية)
const localCache = new caffeine.Cache({
  max: 1000,
  ttl: 30,
})

// الحصول على تفاصيل المنتج (تخزين مؤقت متعدد المستويات)
async function getProduct(productId) {
  const cacheKey = `product:${productId}`

  // L1: تخزين مؤقت محلي (حوالي 0.1 ميلي ثانية)
  const localCached = localCache.get(cacheKey)
  if (localCached) {
    console.log('L1 إصابة')
    return localCached
  }

  // L2: تخزين Redis المؤقت (حوالي 1 ميلي ثانية)
  const redisCached = await redis.get(cacheKey)
  if (redisCached) {
    console.log('L2 إصابة، إعادة تعبئة L1')
    const product = JSON.parse(redisCached)
    localCache.set(cacheKey, product)
    return product
  }

  // L3: قاعدة البيانات (حوالي 10 ميلي ثانية، مع قفل موزع لمنع الانهيار الموضعي)
  const lockKey = `lock:${productId}`
  const lock = await redis.set(lockKey, '1', 'NX', 'EX', 10)

  if (lock === 'OK') {
    console.log('L3 إصابة، استعلام قاعدة البيانات')
    const product = await db.query(
      'SELECT * FROM products WHERE id = ?',
      [productId]
    )

    if (product) {
      // كتابة في Redis (30 دقيقة + TTL عشوائي)
      const ttl = 1800 + Math.floor(Math.random() * 600) - 300
      await redis.setex(cacheKey, ttl, JSON.stringify(product))
      // إعادة تعبئة التخزين المؤقت المحلي
      localCache.set(cacheKey, product)
    }

    await redis.del(lockKey)
    return product
  } else {
    // فشل الحصول على القفل، انتظار ثم إعادة المحاولة
    await new Promise(resolve => setTimeout(resolve, 50))
    return getProduct(productId)
  }
}

// تحديث معلومات المنتج (تحديث قاعدة البيانات أولاً، ثم حذف التخزين المؤقت)
async function updateProduct(productId, updateData) {
  const cacheKey = `product:${productId}`

  // 1. تحديث قاعدة البيانات
  await db.query(
    'UPDATE products SET name = ?, price = ? WHERE id = ?',
    [updateData.name, updateData.price, productId]
  )

  // 2. حذف التخزين المؤقت المحلي
  localCache.del(cacheKey)

  // 3. حذف تخزين Redis المؤقت
  await redis.del(cacheKey)

  console.log('اكتمل التحديث، تم حذف التخزين المؤقت')
}

👇 جرب بنفسك: العرض التوضيحي التالي يوضح سير العمل الكامل لنظام التخزين المؤقت متعدد المستويات. اضغط على "استعلام عن منتج"، ولاحظ كيفية تنقل الطلب بين مستويات التخزين المؤقت المختلفة:

E-commerce Cache Architecture Demo

Shows multi-level cache architecture in e-commerce systems, including product, inventory, and user caches.

E-commerce cache architecture demo placeholder - detailed interaction to be implemented

7. خلاصة ومسار التعلم

7.1 مراجعة النقاط المعرفية الأساسية

النقطة المعرفية	شرح بكلمة واحدة	المشكلة التي تحلها	نقاط عملية أساسية
إصابة التخزين المؤقت	البيانات موجودة في التخزين المؤقت	تحسين الأداء 10-100 ضعف	هدف نسبة الإصابة > 95%
اختراق التخزين المؤقت	استعلام بيانات غير موجودة، كل مرة تصل لقاعدة البيانات	انهيار قاعدة البيانات من الاستعلامات الخبيثة	مرشح بلوم + تخزين الكائن الفارغ
انهيار التخزين المؤقت الموضعي	انتهاء صلاحية البيانات الرائجة، وصول كميات كبيرة من الطلبات لقاعدة البيانات	زيادة مفاجئة في ضغط قاعدة البيانات	قفل متبادل + انتهاء صلاحية منطقي
انهيار التخزين المؤقت الشامل	انتهاء صلاحية كمية كبيرة من البيانات في نفس الوقت	سحق قاعدة البيانات	TTL عشوائي + تسخين مسبق
تخزين مؤقت متعدد المستويات	تخزين محلي + Redis + قاعدة بيانات	تحسين فائق للأداء	L1 نسبة إصابة 70%، L2 Redis نسبة إصابة 25%
تناسق التخزين المؤقت	مزامنة التخزين المؤقت مع قاعدة البيانات	دقة البيانات	تحديث قاعدة البيانات أولاً، ثم حذف التخزين المؤقت
الحذف المزدوج المؤجل	حذف التخزين المؤقت مرة قبل التحديث ومرة بعده	ضمان التناسق في السيناريوهات القصوى	انتظار 500ms ثم الحذف مرة أخرى

7.2 توصيات مسار التعلم

المرحلة 1: فهم المبادئ (1-2 يوم)

إتقان جوهر التخزين المؤقت (نسخ البيانات، مقايضة المساحة بالوقت)
فهم المفاهيم الأساسية: نسبة الإصابة، TTL، الإخلاء
فهم فروق الأداء بين وسائط التخزين المختلفة (الذاكرة مقابل القرص الصلب)

المرحلة 2: إتقان الأساسيات (2-3 أيام)

تعلم استخدام Redis للتخزين المؤقت (أوامر SET، GET، SETEX)
تنفيذ منطق القراءة والكتابة البسيط للتخزين المؤقت (استعلام التخزين المؤقت أولاً، ثم قاعدة البيانات عند الفقدان)
فهم لماذا "الحذف وليس التحديث" عند تعديل البيانات

المرحلة 3: حل المشاكل الكلاسيكية (أسبوع واحد)

حل اختراق التخزين المؤقت: تنفيذ مرشح بلوم أو تخزين الكائن الفارغ
حل انهيار التخزين المؤقت الموضعي: تنفيذ القفل المتبادل أو انتهاء الصلاحية المنطقي
حل انهيار التخزين المؤقت الشامل: تنفيذ TTL العشوائي والتسخين المسبق

المرحلة 4: التخزين المؤقت متعدد المستويات (1-2 أسبوع)

إدخال التخزين المؤقت المحلي (Caffeine/Guava)
تصميم بنية من مستويين: تخزين محلي + Redis
معالجة مشاكل التناسق في التخزين المؤقت متعدد المستويات

المرحلة 5: التطبيق العملي على مستوى الإنتاج (مستمر)

تصميم نظام تخزين مؤقت كامل لصفحة تفاصيل المنتج
بناء المراقبة (نسبة الإصابة، زمن الاستجابة)
إجراء اختبارات الضغط والتحقق وضبط الأداء

💡 كلمة أخيرة

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

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

آمل أن يساعدك هذا المقال في بناء فهم شامل لنظام التخزين المؤقت. وعندما تواجه مشاكل في الأداء في مشاريعك الفعلية، ستتمكن من التفكير: "هل يمكن حل هذه المشكلة بالتخزين المؤقت؟"

مستويات واستراتيجيات التخزين المؤقت ​

1. لماذا نحتاج إلى "التخزين المؤقت"؟ ​

1.1 التطور من "الاستعلام في كل مرة" إلى "تذكر البيانات الشائعة" ​

1.2 قصة واقعية عن فشل مؤلم: لماذا التخزين المؤقت هو طوق النجاة ​

2. المفاهيم الأساسية: ما هو التخزين المؤقت؟ ​

2.1 فهم المفاهيم الأساسية للتخزين المؤقت من خلال "تشبيه الحقيبة" ​

2.2 إصابة التخزين المؤقت مقابل فقدان التخزين المؤقت ​

2.3 دورة حياة التخزين المؤقت ​

3. رحلة تطور التخزين المؤقت: من الجهاز الواحد إلى الموزع ​

3.1 المرحلة الأولى: عصر بلا تخزين مؤقت — قاعدة البيانات عارية ​

3.2 المرحلة الثانية: إدخال Redis للتخزين المؤقت — تحسين الأداء 10 أضعاف ​

3.3 المرحلة الثالثة: بنية التخزين المؤقت متعددة المستويات — تحسين الأداء 5 أضعاف إضافية ​

3.4 صورة شاملة لتطور بنية التخزين المؤقت ​

4. المشاكل الكلاسيكية الثلاث للتخزين المؤقت: الاختراق، والانهيار الموضعي، والانهيار الشامل ​

4.1 اختراق التخزين المؤقت (Cache Penetration): الاستعلام عن بيانات غير موجودة ​

4.2 انهيار التخزين المؤقت الموضعي (Cache Breakdown): انتهاء صلاحية البيانات الرائجة ​

4.3 انهيار التخزين المؤقت الشامل (Cache Avalanche): انتهاء صلاحية كمية كبيرة من البيانات في نفس الوقت ​

5. استراتيجية تناسق التخزين المؤقت: كيفية مزامنة التخزين المؤقت مع قاعدة البيانات ​

5.1 لماذا يحدث عدم تناسق بين التخزين المؤقت وقاعدة البيانات؟ ​

5.2 أفضل ممارسة: تحديث قاعدة البيانات أولاً، ثم حذف التخزين المؤقت ​

5.3 الحذف المزدوج المؤجل: ضمان التناسق في السيناريوهات القصوى ​

6. تطبيق عملي: بناء نظام تخزين مؤقت كامل ​

6.1 تحليل سيناريو العمل ​

6.2 تصميم البنية ​

6.3 تنفيذ الكود الأساسي ​

E-commerce Cache Architecture Demo

7. خلاصة ومسار التعلم ​

7.1 مراجعة النقاط المعرفية الأساسية ​

7.2 توصيات مسار التعلم ​

مستويات واستراتيجيات التخزين المؤقت

1. لماذا نحتاج إلى "التخزين المؤقت"؟

1.1 التطور من "الاستعلام في كل مرة" إلى "تذكر البيانات الشائعة"

1.2 قصة واقعية عن فشل مؤلم: لماذا التخزين المؤقت هو طوق النجاة

2. المفاهيم الأساسية: ما هو التخزين المؤقت؟

2.1 فهم المفاهيم الأساسية للتخزين المؤقت من خلال "تشبيه الحقيبة"

2.2 إصابة التخزين المؤقت مقابل فقدان التخزين المؤقت

2.3 دورة حياة التخزين المؤقت

3. رحلة تطور التخزين المؤقت: من الجهاز الواحد إلى الموزع

3.1 المرحلة الأولى: عصر بلا تخزين مؤقت — قاعدة البيانات عارية

3.2 المرحلة الثانية: إدخال Redis للتخزين المؤقت — تحسين الأداء 10 أضعاف

3.3 المرحلة الثالثة: بنية التخزين المؤقت متعددة المستويات — تحسين الأداء 5 أضعاف إضافية

3.4 صورة شاملة لتطور بنية التخزين المؤقت

4. المشاكل الكلاسيكية الثلاث للتخزين المؤقت: الاختراق، والانهيار الموضعي، والانهيار الشامل

4.1 اختراق التخزين المؤقت (Cache Penetration): الاستعلام عن بيانات غير موجودة

4.2 انهيار التخزين المؤقت الموضعي (Cache Breakdown): انتهاء صلاحية البيانات الرائجة

4.3 انهيار التخزين المؤقت الشامل (Cache Avalanche): انتهاء صلاحية كمية كبيرة من البيانات في نفس الوقت

5. استراتيجية تناسق التخزين المؤقت: كيفية مزامنة التخزين المؤقت مع قاعدة البيانات

5.1 لماذا يحدث عدم تناسق بين التخزين المؤقت وقاعدة البيانات؟

5.2 أفضل ممارسة: تحديث قاعدة البيانات أولاً، ثم حذف التخزين المؤقت

5.3 الحذف المزدوج المؤجل: ضمان التناسق في السيناريوهات القصوى

6. تطبيق عملي: بناء نظام تخزين مؤقت كامل

6.1 تحليل سيناريو العمل

6.2 تصميم البنية

6.3 تنفيذ الكود الأساسي

7. خلاصة ومسار التعلم

7.1 مراجعة النقاط المعرفية الأساسية

7.2 توصيات مسار التعلم