اعمل طبقة كاش بـ Redis في Node.js: نزّل زمن الاستجابة من 820 لـ 5 مللي ثانية

import Redis from "ioredis";
import { Pool } from "pg";

const redis = new Redis();   // بيتصل بـ localhost:6379 افتراضيًا
const db = new Pool();       // بياخد إعدادات PostgreSQL من متغيرات البيئة

async function getProduct(id) {
  const key = `product:${id}`;

  // 1) دوّر في الكاش الأول
  const cached = await redis.get(key);
  if (cached) return JSON.parse(cached);   // HIT: رجّعنا في ~5ms من الذاكرة

  // 2) MISS: اقرأ من قاعدة البيانات مرة واحدة بس
  const { rows } = await db.query(
    "SELECT id, name, price FROM products WHERE id = $1",
    [id]
  );
  const product = rows[0];
  if (!product) return null;

  // 3) خزّنه في Redis بمهلة صلاحية 300 ثانية
  await redis.set(key, JSON.stringify(product), "EX", 300);
  return product;
}

ركّز في سطر set(... "EX", 300): ده اللي بيخلّي المفتاح يعيش 5 دقائق بس ثم يختفي لوحده. من غيره الكاش هيمتلئ ويحتفظ ببيانات قديمة.

4) و 5) الصلاحية وإبطال الكاش عند التعديل

الافتراض إن سعر المنتج بيتغيّر أحيانًا. لو غيّرته في الداتابيز بس، الكاش هيفضل يرجّع السعر القديم لحد ما الـ TTL يخلص. عشان كده امسح المفتاح مع كل تعديل:

6) قِس الفرق بنفسك

على جدول فيه 10 آلاف منتج وبدون فهرس مناسب، أول طلب (MISS) ممكن ياخد حوالي 820 مللي ثانية. كل طلب بعده على نفس المنتج (HIT) بيرجع في حوالي 5 مللي ثانية، أي أسرع بحوالي 160 مرة. لو 90% من الطلبات hits، متوسط زمن الاستجابة بينزل بشكل واضح، والحمل على PostgreSQL بيقل لأن أغلب القراءات مبتوصلوش له أصلًا.

الـ trade-offs: بتكسب إيه وبتخسر إيه

• بتكسب: سرعة قراءة بالمللي ثانية، وحمل أقل بكتير على قاعدة البيانات.
• بتخسر: احتمال إن البيانات تبقى قديمة (stale) لمدة الـ TTL — 300 ثانية في مثالنا — لو نسيت تبطّل الكاش. وكمان ذاكرة زيادة: 10 آلاف منتج بحجم ~1 كيلوبايت للواحد يعني حوالي 10 ميجابايت في Redis.
• الافتراض هنا إن القراءة أكتر بكتير من الكتابة، وإن تأخير بسيط في تحديث البيانات مقبول. لو ده مش وضعك، الكاش ممكن يعملك مشاكل أكتر مما يحل.

متى لا تستخدم هذه الطريقة

• بيانات لازم تكون دقيقة 100% في كل لحظة، زي رصيد بنكي أو كمية مخزون وقت الشراء. الـ stale هنا خطر حقيقي.
• بيانات بتتقري مرة واحدة ومبتتكررش. الكاش بيفيد مع التكرار؛ من غير تكرار انت بتضيف تعقيد بدون مكسب.
• الاستعلام أصلًا سريع (أقل من 10 مللي ثانية) لأن عندك فهرس كويس. ساعتها ابدأ بالفهرس، مش بالكاش.

التحقق من أنه يعمل

افتح redis-cli وشغّل MONITOR، وانت بتطلب نفس المنتج مرتين. المرة الأولى هتشوف GET يليه SET (miss ثم تخزين)، والمرة التانية هتشوف GET بس (hit). لو شفت SET في كل مرة، يبقى في مشكلة في المفتاح أو الـ TTL.

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

خُد أبطأ endpoint قراءة عندك دلوقتي، لفّه بدالة getProduct اللي فوق، وشغّل autocannon عليه قبل وبعد. لو الزمن نزل بشكل واضح والحمل على الداتابيز قلّ، الكاش شغّال صح؛ ابدأ بالمفتاح الأكثر طلبًا وبس.

المصادر

• توثيق أمر SET وخيار EX في Redis: redis.io/docs/latest/commands/set
• أنماط الكاش (cache-aside / lazy loading) — AWS ElastiCache: docs.aws.amazon.com
• عميل ioredis الرسمي: github.com/redis/ioredis
• عميل node-postgres (pg): node-postgres.com
• أداة قياس الحِمل autocannon: github.com/mcollina/autocannon