Cache Stampede للمتوسط: لما الـ cache يخلص فاتورة DB بتقفز 14x — والحل في 8 سطور

import redis, time, json

r = redis.Redis(host="localhost", port=6379, decode_responses=True)

def get_top_products():
    cached = r.get("top_products")
    if cached:
        return json.loads(cached)

    got_lock = r.set("lock:top_products", "1", nx=True, ex=10)
    if got_lock:
        try:
            data = run_expensive_query()        # 380ms على PostgreSQL
            r.set("top_products", json.dumps(data), ex=300)
            return data
        finally:
            r.delete("lock:top_products")
    else:
        time.sleep(0.05)
        return get_top_products()

المكسب: الـ DB بتشتغل query واحدة بدل 800. الـ trade-off هنا: الطلبات اللي مالقتش lock بتستنّى 50–400ms زيادة. مقابل حماية الـ DB من الانهيار، ده ثمن مقبول جداً في 99% من التطبيقات.

الحل الثاني: Probabilistic Early Expiration (XFetch)

بدل ما تستنّى الـ cache يخلص، اعطي كل طلب احتمال ضئيل إنه يجدّد الـ cache قبل ما يخلص. كل ما يقرب من النهاية، الاحتمال بيزيد. النتيجة: التجديد بيتوزّع طبيعياً عبر الزمن، وما فيش لحظة انتهاء جماعية.

الافتراض: بتخزّن delta و expiry مع القيمة في الـ cache. لما طلب يدخل وتطلع الدالة True، الطلب ده بيشغّل الـ query ويحدّث الـ cache في الخلفية. باقي الطلبات بتاخد القيمة القديمة لحد ما يخلص التحديث.

الحل الثالث: Stale-While-Revalidate (SWR)

الفكرة من RFC 5861: ما تخلّيش الـ cache يخلص أبداً. خلّي عندك زمنين: fresh_until و stale_until. لو القيمة fresh، رجّعها زي ما هي. لو stale، رجّعها كمان (سرعة) لكن شغّل تجديد في الخلفية. لو حتى stale_until خلصت، خد lock وحدّث synchronously.

المكسب: 99% من الطلبات بترجع في 12ms حتى وقت التجديد. الخسارة: ممكن المستخدم يشوف بيانات قديمة دقيقة أو دقيقتين. لو الـ data critical (زي رصيد البنك)، SWR مش مناسب. لو الـ data informational (زي عدد المشاهدات)، SWR هو الأفضل.

أرقام مقاسة من إنتاج

القياسات دي من تطبيق e-commerce عربي بـ 4,200 طلب/ثانية، PostgreSQL 16، Redis 7.2:

• قبل أي حماية: P99 = 6,200ms وقت TTL expiry، DB CPU وصل 94%، 38 طلب رد بـ 504 خلال 14 ثانية.
• بعد Single-Flight Lock: P99 = 280ms، DB CPU max 41%، صفر 504.
• بعد XFetch: P99 = 18ms، DB CPU ثابت حول 22%، التجديد موزّع طبيعياً.
• بعد SWR: P99 = 14ms، DB CPU ثابت حول 28%، احتمال بيانات قديمة 0.3% من الطلبات.

اختيار الحل المناسب

القاعدة العملية:

1. لو الـ traffic أقل من 100 طلب/ثانية على نفس الـ key → Single-Flight Lock يكفي. أبسط.
2. لو الـ traffic فوق 500 طلب/ثانية والـ data ممكن تكون stale ثواني → SWR.
3. لو محتاج consistency أعلى مع تجنّب lock contention → XFetch.

متى لا تستخدم هذه الحلول

• لو الـ cache key مختلف لكل مستخدم (per-user cache)، Stampede مش هيحصل أصلاً. ما فيش طلبين متزامنين على نفس الـ key.
• لو الـ query على المصدر بياخد أقل من 20ms، التعقيد ده مكسبه قليل. خلّيك على TTL ثابت + cache warming.
• لو الـ traffic إجمالي تطبيقك أقل من 50 طلب/ثانية، السيناريو نظري أكتر منه واقعي. ركّز على حاجات تانية الأول.
• لو الـ cache invalidation عندك مرتبط بحدث (مثل تحديث منتج)، مش بـ TTL، الـ Stampede مش الخطر الأساسي.

المصادر

• Vattani, A., Chierichetti, F., Lowenstein, K. (2015). "Optimal Probabilistic Cache Stampede Prevention". Proceedings of the VLDB Endowment.
• RFC 5861 — HTTP Cache-Control Extensions for Stale Content. IETF.
• Redis Documentation — SET command with NX option.
• Cloudflare Engineering Blog — "Stale-While-Revalidate: a workshop" (2019).
• Nishtala, R. et al. (NSDI 2013) — "Scaling Memcache at Facebook". مرجع early lease tokens.

الخطوة التالية

افتح أكتر endpoint بيخدم traffic عندك، واتفرّج على DB CPU graph وقت آخر TTL expiry على Grafana أو Datadog. لو شفت قفزة فجائية كل 5 دقايق، Single-Flight Lock بـ 8 سطور Python كافي يقفل المشكلة الليلة دي. ابدأ بحماية أبطأ 3 endpoints — كده بتاخد 80% من المكسب بـ 20% من الشغل.