تطبيقك يُنشئ استعلام قاعدة بيانات، وقاعدة البيانات تُنفّذه وتجلب البيانات وتُعيدها. هذا طبيعي تماماً. لكن ماذا لو تكرر نفس الاستعلام 500 مرة في الدقيقة — وأنتج نفس النتيجة في كل مرة؟ هذه 500 رحلة ذهاباً وإياباً لا داعي لها على الإطلاق.
هذه هي المشكلة التي يحلّها التخزين المؤقت للسيرفر. وعلى مدار سنوات، هيمنت أداتان على هذا المجال: Memcached وRedis. كلتاهما تحتفظان بالبيانات الأكثر استخداماً في الذاكرة حتى يتمكن تطبيقك من استرجاعها في ميكروثانية بدلاً من ميلي ثانية. لكنهما ليستا متبادلتين. اختيار الأداة الخاطئة لعبء العمل لديك قد يُضيّع عليك مكاسب أداء حقيقية.
إليك الفرق الفعلي بينهما — وكيف تقرر أيهما يناسب سيرفرك.
ما يشتركان فيه
قبل الخوض في الفروقات، من المفيد أن تفهم ما يجمع Memcached وRedis. كلتاهما مخازن بيانات من نوع مفتاح-قيمة تعمل في الذاكرة. وكلتاهما سريعتان للغاية — أوقات الاسترجاع عادةً أقل من 1ms في ظل الحمل الطبيعي. وكلتاهما أدوات ناضجة ومُختبرة مع مجتمعات كبيرة وتوثيق متين.
تنتهي أوجه التشابه عند هذا الحد تقريباً.
كيف يعمل Memcached (وأين يتفوق)
Memcached هو الأبسط من الاثنين. بُني لمهمة واحدة: تخزين الأشياء مؤقتاً بسرعة. تحفظ زوج مفتاح-قيمة، ثم تسترجعه. هذا هو جوهر الـ API بأكمله.
هذه البساطة هي أيضاً أكبر نقاط قوته. Memcached متعدد الخيوط (multi-threaded)، مما يعني أنه يمكنه الاستفادة الكاملة من نوى CPU المتعددة دون أي إعداد خاص. على سيرفر بـ 8 نوى، يستطيع Memcached توزيع عمليات القراءة والكتابة على جميعها. أما Redis فهو أحادي الخيط (single-threaded) بشكل افتراضي (رغم أن Redis 6 أضاف I/O متعدد الخيوط لعمليات الشبكة).
يستخدم Memcached أيضاً الذاكرة بكفاءة أعلى لتخزين النصوص البسيطة. إذا كان إعداد التخزين المؤقت للسيرفر لديك يقتصر على تخزين أجزاء HTML أو رموز الجلسات، فإن Memcached يستطيع التعامل مع مدخلات أكثر لكل غيغابايت من RAM مقارنةً بـ Redis.
نقاط ضعف Memcached:
- لا يدعم الحفظ الدائم. إذا أعيد تشغيل السيرفر، يختفي التخزين المؤقت.
- لا يدعم هياكل بيانات متقدمة بخلاف النصوص.
- لا يدعم النسخ المتماثل أو التجميع دون أدوات خارجية.
- لا يدعم رسائل pub/sub.
- لا يدعم Lua scripting.
للتخزين المؤقت للقراءة عالي الأداء على عقدة واحدة — خاصة حين تكون بياناتك نصوصاً بسيطة أو كائنات مُتسلسلة — يُعدّ Memcached خياراً ممتازاً. إنه خفيف وقابل للتنبؤ وسريع.
كيف يعمل Redis (ولماذا يُستخدم لأكثر من مجرد تخزين مؤقت)
بدأ Redis كأداة تخزين مؤقت ثم تطور ليصبح شيئاً أوسع بكثير. اليوم يعمل كأداة تخزين مؤقت، ووسيط رسائل، ومخزن جلسات، ومحرك لوحات صدارة، ومحدد معدل الطلبات — كل ذلك في واحد.
الفرق يكمن في هياكل البيانات. يدعم Redis بشكل أصلي:
- Strings — مثل Memcached
- Hashes — كمخزن مفتاح-قيمة صغير داخل مفتاح
- Lists — مجموعات مرتبة، مفيدة للطوابير
- Sets وSorted Sets — رائعة للوحات الصدارة وإزالة التكرار
- Bitmaps وHyperLogLogs — للتحليلات والعد التقريبي
- Streams — لمصادر الأحداث وطوابير الرسائل
هذا مهم لإعداد التخزين المؤقت للسيرفر لأن التطبيقات الحقيقية غالباً تخزّن أكثر من مجرد نصوص. صفحة منتج قد تخزّن hash من معرّفات المنتجات المرتبطة. لوحة تحكم المستخدم قد تخزّن sorted set من النشاطات الأخيرة. يتعامل Redis مع كل هذا بشكل أصلي دون الحاجة لتحويل الكائنات المعقدة إلى نصوص والعكس.
يدعم Redis أيضاً الحفظ الدائم. يمكنك إعداده للكتابة على القرص إما بشكل دوري (RDB snapshots) أو بإضافة كل عملية كتابة إلى سجل (AOF). هذا يعني أن التخزين المؤقت يبقى بعد إعادة التشغيل — وفي بعض الإعدادات، يمكن لـ Redis أن يعمل كمخزن بيانات رئيسي لا مجرد طبقة تخزين مؤقت.
بالنسبة لمعظم إعدادات التخزين المؤقت للسيرفر الحديثة، يُعدّ Redis الخيار الأكثر مرونة. فرق الأداء بين الاثنين ضئيل لمعظم أعباء العمل — كلاهما يعمل في نطاق أقل من الميلي ثانية. ما يُضيفه Redis هو العمق.
نستخدم Redis كأساس لتخزين كائنات WordPress مؤقتاً، إذ نحفظ نتائج استعلامات قاعدة البيانات في الذاكرة حتى تتخطى عمليات تحميل الصفحات المتكررة قاعدة البيانات كلياً. تحقق ذاكرة التخزين المؤقت المُسخّنة جيداً معدلات إصابة تتجاوز 80% في الغالب، مما يُترجم مباشرةً إلى TTFB أقل وتسليم أسرع للصفحات. يمكنك قراءة المزيد حول أهمية ذلك في لماذا يُكلّفك وقت استجابة السيرفر تحويلات مبيعاتك.
إعداد التخزين المؤقت للسيرفر: أيهما تختار
اختر Memcached إذا:
- احتياجات التخزين المؤقت لديك بسيطة — بيانات نصية، رموز جلسات، أجزاء HTML
- لديك سيرفر متعدد النوى وتريد الاستفادة القصوى من CPU لعمليات التخزين المؤقت
- تعمل في بيئة عالية التزامن حيث يمنح تعدد الخيوط ميزة قابلة للقياس
- لا تحتاج إلى الحفظ الدائم أو النسخ المتماثل أو هياكل بيانات متقدمة
- تريد أخف بصمة ذاكرة ممكنة للتخزين المؤقت البحت
اختر Redis إذا:
- تحتاج إلى أكثر من تخزين النصوص — hashes، lists، sets، sorted sets
- تريد الحفظ الدائم عبر عمليات إعادة التشغيل
- تبني طوابير، أو رسائل pub/sub، أو محددات معدل الطلبات جنباً إلى جنب مع التخزين المؤقت
- تحتاج إلى نسخ متماثل أصلي أو Redis Cluster لتوفر عالٍ
- تشغّل WordPress وتريد تخزين الكائنات مؤقتاً (يتكامل Redis مباشرةً عبر إضافات جاهزة)
- تريد أداة واحدة تتولى أدواراً متعددة للتخزين المؤقت
بالنسبة لمعظم تطبيقات الويب — وبالتأكيد لمعظم مواقع WordPress — Redis هو الخيار الصحيح. القدرات الإضافية لا تُضيف عبئاً يُذكر، والحفظ الدائم يعني أن التخزين المؤقت يبقى بعد إعادة التشغيل دون فترة إحماء مؤلمة.
نصائح عملية للإعداد
تحديد حد أقصى للذاكرة
أياً كانت الأداة التي تختارها، احرص دائماً على تحديد سقف للذاكرة. بدونه، قد يتنافس التخزين المؤقت المتنامي مع تطبيقك على RAM — وهذا لا ينتهي بشكل جيد.
لـ Redis، أضف هذا إلى ملف redis.conf:
maxmemory 512mb maxmemory-policy allkeys-lruسياسة allkeys-lru تُخبر Redis بحذف المفاتيح الأقل استخداماً حين تمتلئ الذاكرة. لطبقة تخزين مؤقت بحتة، هذا عادةً ما تريده. خيارات أخرى مثل volatile-lru (حذف المفاتيح التي لها TTL فقط) أفضل إذا كنت تمزج بيانات مؤقتة ودائمة في نفس نسخة Redis.
لـ Memcached، تُحدد الذاكرة عند التشغيل:
memcached -m 512تحديد TTL مناسب
كل عنصر مخزّن مؤقتاً يجب أن يكون له وقت انتهاء صلاحية. التخزين المؤقت القديم غالباً أسوأ من عدم التخزين — يرى المستخدمون بيانات قديمة وتضيع وقتك في تتبع ما يبدو وكأنه خطأ عشوائي.
نقطة بداية عامة:
- أجزاء صفحات HTML: 60–300 ثانية
- نتائج استعلامات قاعدة البيانات: 300–3600 ثانية حسب تكرار تغيير البيانات
- بيانات جلسات المستخدم: تطابق مهلة انتهاء الجلسة
- قيم الإعداد الثابتة: ساعات أو أكثر
راقب معدل الإصابة
إعداد التخزين المؤقت للسيرفر لا قيمة له إلا بمعدل إصابته. إذا كانت ذاكرة التخزين المؤقت تُصاب 40% من الوقت فقط، فأنت على الأرجح تضبط TTL قصيراً جداً، أو لا تخزّن الكائنات الصحيحة، أو تحذف بعدوانية زائدة.
لـ Redis، تحقق من معدل الإصابة في الوقت الفعلي:
redis-cli info stats | grep -E 'keyspace_hits|keyspace_misses'احسب معدل الإصابة هكذا: hits / (hits + misses). استهدف 80% أو أعلى. إذا كنت دون ذلك، راجع المفاتيح الأكثر طلباً وتأكد من أنها فعلاً مخزّنة مؤقتاً.
إذا كنت على استضافة مُدارة، فغالباً يظهر هذا النوع من المراقبة تلقائياً في لوحة التحكم — حتى تتمكن من متابعة معدلات الإصابة عبر الزمن دون تشغيل أوامر CLI يدوياً.
ماذا عن استخدام الاثنين معاً؟
ليس شائعاً، لكن بعض البيئات تشغّل Memcached وRedis جنباً إلى جنب — Memcached لتخزين الجلسات عالي الأداء وRedis لبيانات التطبيق. هذا يُضيف تعقيداً تشغيلياً دون فائدة عملية تُذكر لمعظم المواقع. اختر أداة واحدة، أعدّها جيداً، وراقبها. هذا سيتفوق دائماً على إعداد مزدوج غير محسّن.
للاطلاع على شرح أعمق حول تشغيل Redis بكفاءة على سيرفرك، راجع كيفية إعداد Redis على سيرفرك دون الإضرار بأي شيء. وإذا أردت فهم مكانة التخزين المؤقت في الصورة الأشمل للأداء، فإن تحسين سرعة الموقع: ما الذي يُحدث فارقاً حقيقياً يغطي الصورة الكاملة.
الخلاصة
Memcached أسرع في سيناريوهات محددة متعددة الخيوط وأبسط في الفهم. Redis أكثر قدرة ويدعم الحفظ الدائم وأكثر مرونة — ولمعظم إعدادات التخزين المؤقت للسيرفر في العالم الحقيقي، هو الخيار الافتراضي الأفضل.
إذا كنت غير متأكد، ابدأ بـ Redis. حدد حداً للذاكرة، اضبط TTL منطقياً، وراقب معدل الإصابة. يمكنك دائماً الضبط من هناك بمجرد أن ترى كيف يتصرف عبء العمل الخاص بك.
