استراتيجيات التخزين المؤقت: Redis وHTTP وCDN دون تقديم بيانات فاسدة
طبقات ذاكرة التخزين المؤقت منفصلة من الحافة إلى التطبيق؛ تصميم TTL، والإبطال، والتدافع، وذاكرة التخزين المؤقت للمستخدم الخاص بشكل صحيح.
علي مرتضوي
مؤسس بارادايس كود
ذاكرة التخزين المؤقت ليست طبقة واحدة؛ إنه نظام القرار
CDN للأصول والصفحات العامة، وذاكرة التخزين المؤقت HTTP للوسطاء والمتصفحات، وRedis لبيانات التطبيقات المحسوبة أو ذات القراءة الثقيلة - كل منها له لغته الخاصة ووضع الفشل. تعامل معها على أنها "ذاكرة تخزين مؤقت واحدة" وإما أن تقوم بشحن بيانات قديمة خطيرة أو عدم الاتصال بها مطلقًا.
اسأل أولاً: إلى أي حد يمكن أن يكون هذا الأمر قديماً، وهل هو خاص، وأين مصدر الحقيقة؟
CDN والحافة
تخزين الأصول التي تحمل بصمات الأصابع لفترة طويلة؛ إبقاء HTML أقصر أو إعادة التحقق. بالنسبة للصفحات المخصصة، يعد "التحكم في ذاكرة التخزين المؤقت: خاص" أو تجاوز الحافة أمرًا إلزاميًا. الفشل الكلاسيكي هو تخزين استجابة المستخدم "أ" مؤقتًا للمستخدم "ب".
تطهير حافة السلك/وضع علامة على أحداث نشر المحتوى. التطهير اليدوي وحده لا يكفي للحوادث الخارجية.
رؤوس HTTP ذات أهمية فعلية
قم بتعيين "التحكم في ذاكرة التخزين المؤقت" و"ETag"/"آخر تعديل" و"Vary" عمدًا. قد يؤدي خطأ `Vary: Cookie` إلى إبطال التخزين المؤقت أو تعريضه للخطر. بالنسبة لواجهات برمجة التطبيقات العامة للقراءة، يكون s-maxage المنفصل عن max-age للمتصفح مفيدًا.
لا تقم بتخزين الأخطاء لفترة طويلة. تعد الصفحة الـ 500 المخزنة مؤقتًا أسوأ من الانقطاع.
Redis كذاكرة تخزين مؤقت للتطبيق
أنشئ مفاتيح بمساحات أسماء النطاقات والإصدارات: `tenant:42:pricing:v3`. أضف الارتعاش إلى TTLs حتى لا تتدافع فترات انتهاء الصلاحية معًا. في حالات الأخطاء الساخنة، استخدم قفلًا أو رحلة فردية حتى لا يؤدي كل طلب إلى سحق الأصل.
Redis ليس بديلاً لقاعدة البيانات. البيانات الهامة الموجودة فقط في ذاكرة التخزين المؤقت هي خطأ في انتظار إعادة التشغيل.
الإبطال أصعب من التعيين
نمطان صحيان: TTL قصير مع ثبات مقبول، أو إبطال يحركه الحدث مع علامات/مفاتيح دقيقة. تموت عبارة "ذاكرة التخزين المؤقت إلى الأبد حتى نتذكر التطهير" في الفرق المزدحمة. قم بتوثيق الأحداث التي تقتل المفاتيح.
بالنسبة للقوائم، غالبًا ما يكون إصدار مفتاح القائمة أرخص من حذف عضو تلو الآخر.
إمكانية الملاحظة والسلامة
مراقبة نسبة الدخول وزمن الوصول الأصلي والمعدلات القديمة. عادةً ما تعني حالات الهبوط المفاجئة نشرًا سيئًا أو إبطالًا واسع النطاق. احتفظ بالبيانات الحساسة بعيدًا عن شبكات CDN العامة؛ تعامل مع الأسرار ومعلومات تحديد الهوية الشخصية في Redis من خلال سياسة TTL والوصول الصارمة.
يظهر التخزين المؤقت الجيد كأصل هادئ ومستخدم سريع، دون خوف الفريق من صحة البيانات.
الأسئلة الشائعة
CDN أولاً أم Redis أولاً؟
CDN للمحتوى العام والأصول. Redis لبيانات التطبيق الديناميكية/المجمعة. في كثير من الأحيان كلاهما، في طبقات مختلفة.
هل تعتبر عملية إعادة التحقق التي لا معنى لها فكرة جيدة؟
ممتاز للمحتوى العام. يشكل خطرًا على المخزون الدقيق أو التسعير المباشر ما لم تكن القواعد واضحة.
كيف نقلل من حالات التدافع؟
ارتعاش TTL وقفل الطلب وتسخين المفاتيح المهمة قبل ذروة حركة المرور.
هل التخزين المؤقت لـ GraphQL صعب؟
نعم، لأن القفل معقد. عادةً ما تتغلب الاستعلامات المستمرة والتخزين المؤقت في طبقة بيانات واضحة على الاستجابات الكاملة للتخزين المؤقت بشكل أعمى.
المعرفة والمقالات
تحتاج تطبيق هذه المفاهيم في منتجك؟
بارادايس كود معك من الاستشارة حتى التسليم الكامل.