بعد «السترة والكاش لـ 10 ثوانٍ»

لو استخدامك الوحيد لريديس هو SET key value EX 60 بغرض الكاش، فأنت بتستخدم جزءًا ضئيلًا من قيمته. في مشروعين عندي (redisjobs وأ fastapi-forge)، ريديس هو منطق النظام نفسه، مش مجرد مخزن: القوائم الذرية، المصنفات، الأقفال، والعدادات هي اللي بتعمل الشغل.

الطوابير — القصة الكاملة

أوضح مثال: redisjobs. عايز طابور مهام موثوق بين عمليات منفصلة من غير نظام وسيط. الحل كان قائمة ريديس مع أمر ذرّي واحد:

LPUSH queue <task>          # المنتِج
BLMOVE queue processing 1 queue 10   # ذري: ياخد من queue ويحط في processing

نقطة الفوز: لو المستهلك مات وسط الشغل، المهمة واقفة في processing، و الـ reaper بيرجّعها للمعالجة (delivery من نوع at-least-once). هنا الذرية إلزامية: لأن LMOVE بتحجز المهمة في خطوة واحدة، مستهلكان لا يمكن أن يلتقطا نفس المهمة معًا أبدًا.

القفل الموزّع

لأي مهمة «مرة واحدة على مستوى النظام» (إعادة إنتاج ملف، إنشاء وصل، مهمة تسعير مشتركة) — SET NX PX مع ملكية:

ok = await redis.set(key, token, nx=True, px=30000)
if not ok:
    raise LockBusyError

والإفراج بذريّة «قارن واحذف» عشان محدش يفرج قفل مش بتاعه. ده مثال مباشر لـ «التزامن الأصلي أولاً»: الذرية عملت كل المزامنة نيابة عنك.

المصنّفات — لكل أمر مرتب

ZSET (Sorted Set) بتحل مسائل أعمق من ترتيب بسيط: الجدولة المؤجلة (enqueue_at بتترجم لدرجة = وقت التنفيذ) والـ DLQ (الرسائل الميتة مرتبة بوقت انتهاء المحاولات) ونافذة محدد المعدل. نفس البنية بتخدم «أي مشكلة ليها وقت وترتيب».

الـ pipeline — رحلة واحدة بدل عشرات

من مشروع fastapi-forge، أول رد فعل لقراءة مفاتيح متعددة كان asyncio.gather على عشرات GET — صحيح تقنيًا، غلط هندسيًا (كل أمر سفر ذهاب وإياب). البديل الأصلي:

pipe = client.pipeline()
for key in keys:
    pipe.get(key)
values = await pipe.execute()   # طلب شبكة واحد

الجلسات والعدادات

زخم الاستخدام الأخير: جلسات — نفس منطق الكاش بس بقيمة JSON نشطة لكل مستخدم، وعدادات ومصّنفات للـ rate limiting. كلها أوامر واحدة بسيطة، كلها من غير عملية وسيطة تانية.

الخلاصة

Redis مش كاش — صندوق أدوات. لما تشتغل بذرة أوامره الأصلية، بتحصل على توزيع كامل (طوابير، أقفال، عدادات، جدولة) من غير طبقات زائدة ولا نظام وسيط بتحتاج صيانته.