استراتيجيات التخزين المؤقت: التخزين المؤقت لـ Redis وCDN وHTTP لتطبيقات الويب

التخزين المؤقت هو الأسلوب الوحيد الأكثر فعالية لتحسين أداء التطبيق. يمكن لذاكرة التخزين المؤقت المصممة جيدًا تقليل تحميل قاعدة البيانات بنسبة 90%، وتقليل أوقات الاستجابة من 200 مللي ثانية إلى 2 مللي ثانية، وتوفير آلاف الدولارات من تكاليف البنية التحتية شهريًا. ومع ذلك، فإن التخزين المؤقت هو أيضًا أحد أكثر المجالات التي يساء فهمها في هندسة البرمجيات - حيث تؤدي أخطاء الإبطال إلى إنشاء بيانات قديمة، وتتسبب عمليات التدافع في ذاكرة التخزين المؤقت في إسقاط الخوادم، كما أن TTLs التي تم اختيارها بشكل سيئ إما تهدر الذاكرة أو تقدم محتوى قديمًا.

الوجبات الرئيسية

• تصميم التخزين المؤقت في الطبقات: من المتصفح إلى CDN إلى التطبيق (Redis) إلى ذاكرة التخزين المؤقت لاستعلام قاعدة البيانات - تعالج كل طبقة خصائص بيانات مختلفة
• يعد نمط Redis لذاكرة التخزين المؤقت هو النمط الافتراضي الأكثر أمانًا: القراءة من ذاكرة التخزين المؤقت، والرجوع إلى قاعدة البيانات، وملء ذاكرة التخزين المؤقت في حالة عدم وجودها
• تعمل رؤوس ذاكرة التخزين المؤقت لـ HTTP (Cache-Control، وETag، وVary) على التخلص من الطلبات غير الضرورية تمامًا - فالطلب الأسرع هو الطلب الذي لا يصل أبدًا إلى الخادم الخاص بك
• يعد إبطال ذاكرة التخزين المؤقت أصعب من التخزين المؤقت - استخدم انتهاء الصلاحية المستند إلى TTL كاستراتيجية أساسية والإبطال المستند إلى الحدث لحداثة البيانات المهمة

---

التسلسل الهرمي لذاكرة التخزين المؤقت

يعمل التخزين المؤقت الفعال في طبقات، مع تحسين كل طبقة لمتطلبات زمن الوصول والسعة والحداثة المختلفة.

الطبقة الأولى: ذاكرة التخزين المؤقت للمتصفح

تعد ذاكرة التخزين المؤقت للمتصفح هي أسرع وأرخص ذاكرة تخزين مؤقت لأنها تلغي طلب الشبكة بالكامل. تتحكم رؤوس HTTP Cache-Control في سلوك التخزين المؤقت للمتصفح.

بالنسبة للأصول الثابتة ذات أسماء الملفات المجزأة للمحتوى (مثل مخرجات إنشاء Next.js)، قم بتعيين Cache-Control: public, max-age=31536000, immutable. تضمن تجزئة المحتوى في اسم الملف حصول المحتوى الذي تم تغييره على عنوان URL جديد، بحيث يمكنك تخزينه مؤقتًا بقوة دون القلق بشأن المحتوى القديم.

بالنسبة لصفحات HTML واستجابات واجهة برمجة التطبيقات (API)، استخدم TTLs أقصر مع إعادة التحقق من الصحة: ​​Cache-Control: public, max-age=60, stale-while-revalidate=300. يؤدي هذا إلى عرض المحتوى المخزن مؤقتًا لمدة 60 ثانية، ثم يتم إعادة التحقق من صحته في الخلفية مع الاستمرار في تقديم المحتوى القديم لمدة تصل إلى 5 دقائق.

الطبقة الثانية: ذاكرة التخزين المؤقت لحافة CDN

تقوم شبكة CDN بتخزين المحتوى مؤقتًا على خوادم الحافة الموزعة عالميًا، مما يقلل زمن الوصول من خلال تقديم المحتوى من الموقع الأقرب إلى كل مستخدم. بالنسبة لقاعدة المستخدمين العالمية، يقلل التخزين المؤقت لـ CDN متوسط ​​زمن الوصول من 200-500 مللي ثانية (ذهابًا وإيابًا للخادم الأصلي) إلى 10-50 مللي ثانية (أقرب حافة).

ما يجب تخزينه مؤقتًا على CDN:

• جميع الأصول الثابتة (JavaScript، CSS، الصور، الخطوط)
• صفحات التسويق العامة (مع TTL قصيرة لنضارة المحتوى)
• صفحات كتالوج المنتجات (مدة البقاء من 5 إلى 15 دقيقة للتجارة الإلكترونية)
• استجابات واجهة برمجة التطبيقات (API) للبيانات العامة (قوائم المنتجات ومحتوى المدونة)

ما لا يجب تخزينه مؤقتًا على CDN:

• استجابات API المصادق عليها (بيانات خاصة بالمستخدم)
• عربة التسوق وصفحات الخروج
• صفحات لوحة الإدارة
• نقاط النهاية Webhook
• أي استجابة برؤوس Set-Cookie

الطبقة الثالثة: ذاكرة التخزين المؤقت للتطبيق (Redis)

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

الطبقة الرابعة: ذاكرة التخزين المؤقت لاستعلام قاعدة البيانات

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

---

أنماط التخزين المؤقت لـ Redis

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

ذاكرة التخزين المؤقت جانبا (تحميل كسول)

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

المزايا:

• يتم تخزين البيانات المطلوبة فقط مؤقتًا (لا توجد ذاكرة مهدرة على البيانات غير المستخدمة)
• يؤثر فشل قاعدة البيانات فقط على الأخطاء في ذاكرة التخزين المؤقت، وليس على نتائج ذاكرة التخزين المؤقت
• سهولة التنفيذ والسبب

عيوب:

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

الكتابة من خلال

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

المزايا:

• ذاكرة التخزين المؤقت حديثة دائمًا - ولا توجد نافذة بيانات قديمة
• أداء القراءة سريع دائمًا (لا توجد ذاكرة تخزين مؤقت مفقودة بعد الكتابة الأولية)

عيوب:

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

الكتابة الخلفية (إعادة الكتابة)

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

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

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

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

استراتيجيات الوقاية:

1. Stale-while-revalidate -- يقدم بيانات قديمة قليلاً بينما يقوم طلب واحد بإعادة بناء ذاكرة التخزين المؤقت في الخلفية
2. قفل Mutex - استخدم Redis SETNX للتأكد من أن طلبًا واحدًا فقط يعيد بناء ذاكرة التخزين المؤقت بينما ينتظر الآخرون أو يقدمون بيانات قديمة
3. انتهاء محتمل مبكر - إعادة الحساب بشكل عشوائي قبل انتهاء صلاحية TTL، ونشر عمليات إعادة البناء بمرور الوقت بدلاً من تركيزها عند انتهاء الصلاحية

---

تصميم استراتيجية TTL

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

TTL المنزلق مقابل TTL الثابت

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

---

نظرة عميقة على رؤوس ذاكرة التخزين المؤقت لـ HTTP

يعد التخزين المؤقت لـ HTTP قويًا لأنه يعمل في كل طبقة - كل من المتصفح وCDN والوكلاء وموازنات التحميل يفهمون نفس الرؤوس.

توجيهات التحكم في ذاكرة التخزين المؤقت

• عام - قد تقوم أي ذاكرة تخزين مؤقت (متصفح، CDN، وكيل) بتخزين الاستجابة
• خاص - يمكن للمتصفح فقط تخزين ذاكرة التخزين المؤقت (وليس CDN أو الوكلاء) - يُستخدم للاستجابات المصادق عليها
• no-cache -- قم بتخزين الاستجابة مؤقتًا ولكن قم بإعادة التحقق من صحتها مع الخادم قبل استخدامها (اسم مضلل - يتم تخزين الاستجابة مؤقتًا)
• لا يوجد متجر -- لا تقم بتخزين البيانات مؤقتًا على الإطلاق (البيانات الحساسة مثل الصفحات المصرفية)
• max-age=N -- ذاكرة التخزين المؤقت صالحة لمدة N ثانية
• s-maxage=N - مدة ذاكرة التخزين المؤقت لـ CDN/الوكيل (تتجاوز الحد الأقصى لعمر ذاكرة التخزين المؤقت المشتركة)
• stale-while-revalidate=N - عرض محتوى قديم لمدة N ثانية أثناء إعادة التحقق من الصحة في الخلفية
• غير قابل للتغيير - لن يتغير المحتوى أبدًا (استخدمه مع عناوين URL المجزأة للمحتوى)

ETag والطلبات المشروطة

توفر علامات ETag التحقق من صحة ذاكرة التخزين المؤقت المستندة إلى المحتوى. يقوم الخادم بإنشاء تجزئة لمحتوى الاستجابة ويرسلها كرأس ETag. في الطلبات اللاحقة، يرسل المتصفح ETag في رأس If-None-Match. إذا لم يتغير المحتوى، يستجيب الخادم بـ 304 غير معدل (بدون نص)، مما يوفر عرض النطاق الترددي.

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

يختلف الرأس

يخبر رأس Vary ذاكرات التخزين المؤقت أن الاستجابة تعتمد على رؤوس طلبات محددة. على سبيل المثال، Vary: Accept-Encoding يعني أنه يتم تخزين إصدارات gzip وBrotli بشكل منفصل. Vary: Accept-Language يقوم بتخزين إصدارات اللغات المختلفة بشكل منفصل.

كن حذرًا مع Vary - فكل مجموعة فريدة من الرؤوس المتنوعة تنشئ إدخالاً منفصلاً في ذاكرة التخزين المؤقت. Vary: Cookie يعطل التخزين المؤقت بشكل فعال لأن كل مستخدم لديه ملفات تعريف ارتباط مختلفة.

---

استراتيجيات إبطال ذاكرة التخزين المؤقت

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

انتهاء الصلاحية على أساس TTL

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

إبطال يحركه الحدث

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

استخدم الإبطال المستند إلى الحدث للبيانات الهامة مثل أعداد المخزون والتسعير، واعتمد على TTL في كل شيء آخر.

الإبطال القائم على العلامات

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

---

الأسئلة المتداولة

كيف أحدد ما سيتم تخزينه مؤقتًا؟

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

ماذا يحدث عندما يتعطل Redis؟

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

ما مقدار الذاكرة التي يجب تخصيصها لـ Redis؟

مراقبة نسبة ضرب ذاكرة التخزين المؤقت واستخدام الذاكرة. تشير نسبة الإصابة التي تزيد عن 95% مع استخدام الذاكرة أقل من 80% إلى الحجم الجيد. إذا انخفضت نسبة الدخول إلى أقل من 90%، فإما أنك تحتاج إلى المزيد من الذاكرة أو أن مدة البقاء (TTL) قصيرة جدًا. ابدأ بسعة تتراوح من 1 إلى 2 غيغابايت لمعظم التطبيقات ثم قم بالتوسيع بناءً على بيانات المراقبة.

هل يجب أن أستخدم Redis أو Memcached؟

Redis هو الخيار الافتراضي الأفضل لمعظم التطبيقات. وهو يدعم المزيد من أنواع البيانات، وخيارات الثبات، وpub/sub للإبطال المستند إلى الحدث، والبرمجة النصية Lua للعمليات الذرية. Memcached أبسط وأسرع قليلًا للتخزين المؤقت للقيمة الرئيسية على نطاق واسع، لكن Redis يغطي المزيد من حالات الاستخدام.

كيف يمكنني منع عرض البيانات القديمة بعد النشر؟

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

---

ما هو التالي

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

للحصول على الصورة الكاملة لتحسين الأداء، راجع دليلنا الأساسي حول توسيع نطاق النظام الأساسي لأعمالك. لتحسين مصدر البيانات الذي يغذي ذاكرة التخزين المؤقت الخاصة بك، اقرأ دليلنا حول تحسين استعلام قاعدة البيانات.

تطبق ECOSIRE بنيات التخزين المؤقت للأنظمة الأساسية التي تعمل على Odoo ERP وShopify. اتصل بفريقنا لمراجعة إستراتيجية التخزين المؤقت.

---

تم النشر بواسطة ECOSIRE — لمساعدة الشركات على التوسع باستخدام الحلول المدعومة بالذكاء الاصطناعي عبر Odoo ERP، وShopify eCommerce، وOpenClaw AI.