يتضمن Django إطار عمل تخزين مؤقت مرن يدعم مستويات متعددة من التخزين المؤقت (صفحات كاملة، نتائج العروض، أجزاء النموذج، أو بيانات عشوائية) وعدة خوادم خلفية (ذاكرة في الذاكرة، Redis، Memcached، قاعدة البيانات). يتجنب التخزين المؤقت تكرار العمل المكلف — وهو أحد أعلى التحسينات تأثيراً على الأداء.
CACHES = {
: {
: ,
: ,
}
}
# 1. Per-view caching — cache an entire view's output
from django.views.decorators.cache import cache_page
@cache_page(60 * 15) # cache this view's response for 15 minutes
def article_list(request):
...
<!-- 2. Template fragment caching — cache part of a template -->
{% load cache %}
{% cache 500 sidebar %}
... expensive sidebar rendering ... <!-- cached for 500 seconds -->
{% endcache %}
# 3. Low-level cache API — cache ANY data, full control
from django.core.cache import cache
def get_stats():
stats = cache.get("dashboard_stats") # check cache first
if stats is None: # cache MISS
stats = compute_expensive_stats() # do the work
cache.set("dashboard_stats", stats, 3600) # store for 1 hour
return stats
يسمح لك Django بالتخزين المؤقت على مستويات دقة متعددة: الصفحات الكاملة (cache_page)، أجزاء النموذج ({% cache %})، والبيانات العشوائية عبر واجهة برمجية منخفضة المستوى (cache.get/cache.set — نمط get-or-compute المرن). هناك أيضاً تخزين مؤقت لكامل الموقع عبر البرنامج الوسيط.
# when underlying data changes, the cache must be updated or cleared, or users see stale data
def update_article(article):
article.save()
cache.delete("article_list") # invalidate affected cache entries
# strategies: TTL (accept brief staleness), explicit deletion on writes, versioned keys,
# or signals to invalidate on model save/delete
Cache invalidation is the classic hard problem: when data changes, stale cached
values must be cleared/refreshed. Approaches: short TTLs (accept some staleness),
explicit cache.delete on writes, or cache versioning/key schemes.
✓ Expensive queries/computations, rendered pages/fragments that change infrequently
✓ Aggregations, external API responses, session data
✗ Highly personalized or rapidly-changing data (or use very short TTLs / vary per user)
✗ Don't cache sensitive data carelessly (consider who can read the cache)
التخزين المؤقت هو أحد أعلى التحسينات تأثيراً على الأداء لتطبيقات Django، وإطار عمل التخزين المؤقت الشامل متعدد المستويات في الإطار يجعله في متناول الجميع — فهمه هو معرفة قيّمة على مستوى أعلى لبناء تطبيقات سريعة وقابلة للتوسع.
القيمة الأساسية هي تجنب تكرار العمل المكلف: استعلامات قاعدة البيانات والحسابات المعقدة واستدعاءات API الخارجية وعرض النماذج يمكن تخزينها مؤقتاً بحيث يتم تقديم الطلبات اللاحقة بسرعة، مما يقلل بشكل كبير من زمن التأخير وحمل قاعدة البيانات/الخادم.
توفر مرونة Django عبر مستويات تخزين مؤقت متعددة (الصفحات الكاملة مع cache_page، أجزاء النموذج مع {% cache %}، والبيانات العشوائية عبر نمط get-or-compute في واجهة برمجية منخفضة المستوى) تخزيناً مؤقتاً في المستوى المناسب تماماً لكل موقف، والخوادم الخلفية القابلة للتوصيل (خاصة Redis لتخزين مؤقت مشترك عبر عدة خوادم — مهم لأن ذاكرات التخزين المؤقت في الذاكرة لكل عملية لا تُشارك عند التوسع أفقياً) تناسب احتياجات النشر المختلفة.
معرفة كيفية تكوين التخزين المؤقت واختيار المستوى المناسب واختيار الخادم الخلفي الصحيح للنشر هي معرفة عملية ومطلوبة بشكل متكرر.
من المهم بنفس القدر فهم الصعوبة المركزية للتخزين المؤقت — إلغاء الصلاحية (مشكلة إزالة أو تحديث البيانات المخزنة مؤقتاً عندما تتغير البيانات الأساسية، عبر TTLs أو الحذف الصريح عند الكتابة أو إصدار المفتاح، لتجنب تقديم بيانات قديمة) — حيث أن القيام بذلك بشكل خاطئ هو فشل التخزين المؤقت الكلاسيكي الذي يعرض للمستخدمين معلومات قديمة.
كما أن معرفة ما يجب تخزينه مؤقتاً (بيانات مكلفة وغير متغيرة بشكل متكرر) مقابل ما لا يجب (بيانات ديناميكية جداً أو حساسة) مفتاح لاستخدام التخزين المؤقت بفعالية.
لأن التخزين المؤقت يوفر مكاسب أداء رئيسية لكنه يتطلب إلغاء صلاحية حذرة، فإن إتقان إطار عمل التخزين المؤقت في Django — المستويات والخوادم الخلفية والاستراتيجيات الخاصة بإلغاء الصلاحية بشكل خاص — هو معرفة مهمة لبناء تطبيقات أداء عالي وقابلة للتوسع وشارة مميزة للمطورين الذين يمكنهم جعل تطبيقات Django سريعة تحت الحمل الفعلي.