قم بتخزين البيانات التي يكون إنتاجها مكلفًا، وتُقرأ بتكرار، وتتغير نادرًا — هذا هو المكان الذي يحقق فيه التخزين المؤقت أكبر فائدة. TTL (مدة البقاء) هي توازن بين الحداثة (مدى حالية البيانات المطلوبة) وتحمل العفوية (مدى الخطأ المسموح به وللمدة الزمنية).
مرشح التخزين المؤقت الجيد يسجل درجات عالية في المجالات الثلاثة:
لا تقم بتخزين البيانات الرخيصة الحساب، أو كثيفة الكتابة، أو البيانات السرية لكل مستخدم التي يجب أن تكون حداثتها دقيقة تمامًا (مثل أرصدة الحسابات في لحظة معاملة).
Staleness tolerance → TTL:
config / static reference data → long (hours to days)
product listings, article body → medium (minutes)
prices, stock, leaderboards → short (seconds)
must always be exact → don't cache, or use explicit invalidation
للحصول على دقة البيانات التي تتغير بطريقة غير متوقعة، اجمع TTL مع الإبطال الصريح: write-through أو delete-on-write بحيث يتم مسح المخزن المؤقت في اللحظة التي تتغير فيها المصدر، بدلاً من انتظار انتهاء الصلاحية.
on update(record):
db.save(record)
cache.delete(key(record)) // invalidate now, don't serve stale until TTL
hit ratio = hits / (hits + misses)
high (>90%) → cache is doing its job
low → TTL too short, keys too granular, or data not cacheable
راقب نسبة إصابات التخزين المؤقت لضبط TTLs: نسبة منخفضة تعني أنك بالكاد تقوم بالتخزين المؤقت؛ وإذا كانت النسبة مرتفعة مع شكاوى من البيانات العفوية، فهذا يعني أن TTLs طويلة جدًا.
إن الحصول على الخيارات الصحيحة لما يجب تخزينه مؤقتًا و TTL هو جوهر التخزين المؤقت الفعال. إذا قمت بتخزين الأشياء الخاطئة مؤقتًا، فأنت تضيف التعقيد دون فائدة؛ وإذا ضبطت TTLs طويلة جدًا، فستقدم بيانات عفوية؛ وإذا كانت قصيرة جدًا، فستفقد الفائدة. استخدام تحمل العفوية لاختيار TTLs، وإضافة الإبطال الصريح للحصول على الدقة، ومراقبة نسبة الإصابة يمنحك طريقة مبدئية وقابلة للقياس للتخزين المؤقت.