كيفية إعداد التخزين المؤقت باستخدام Redis على السيرفر دون تعطيل أي شيء

موقعك بطيء. لقد ضغطت الصور وصغّرت ملفات CSS، ومع ذلك — وقت استجابة السيرفر لا يزال متأخراً. في تسعة من كل عشرة حالات، المشكلة تكمن في قاعدة البيانات. كل تحميل للصفحة يُطلق عشرات الاستعلامات، وقاعدة البيانات تُجيب على نفس الأسئلة مراراً وتكراراً.

Redis يحل هذه المشكلة. فهو يخزّن نتائج تلك الاستعلامات في الذاكرة، بحيث يحصل الطلب التالي على إجابة فورية بدلاً من انتظار قاعدة البيانات. والنتيجة هي أوقات استجابة أسرع بشكل ملحوظ — غالباً ما تنخفض معالجة السيرفر بنسبة 50% أو أكثر.

لكن كثيراً من المطورين يترددون لأنهم سمعوا قصصاً مخيفة: بيانات قديمة، جلسات معطوبة، تسميم الكاش. هذا الدليل يأخذك خطوة بخطوة عبر إعداد التخزين المؤقت للسيرفر باستخدام Redis — ما الذي تضبطه، وما الذي تنتبه إليه، وكيف تطلقه دون أن تُوقف موقعك.

ما الذي يفعله Redis فعلاً (ولماذا يختلف عن تخزين الصفحات المؤقت)

Redis هو مخزن بيانات يعمل في الذاكرة. يعيش في RAM، مما يجعل عمليات القراءة والكتابة أسرع بمراحل من قواعد البيانات التي تعتمد على القرص مثل MySQL أو PostgreSQL.

من المهم أن تفهم أين يقع Redis في طبقات التخزين المؤقت لديك:

• تخزين الصفحات المؤقت يحفظ HTML المُصيَّر بالكامل ويقدمه مباشرة للزوار. وهو الطبقة الخارجية.
• تخزين الكائنات المؤقت (وهو ما يتولاه Redis عادةً) يحفظ نتائج استعلامات قاعدة البيانات الفردية واستدعاءات الدوال. يقع بين تطبيقك وقاعدة بياناتك.
• تخزين الكود المُترجَم المؤقت (مثل OPcache في PHP) يحفظ كود PHP المُترجَم حتى لا يُعيد السيرفر تحليل الملفات في كل طلب.

Redis يتولى الطبقة الوسطى. تطبيقك لا يزال يعمل، لكن بدلاً من الاتصال بقاعدة البيانات 40 مرة في كل تحميل للصفحة، قد يتصل بها 4 مرات فقط — ويسحب الباقي من الذاكرة.

قبل أن تلمس أي شيء: قِس أداءك الحالي

لا تضبط التخزين المؤقت دون قياس مسبق. قبل أن تبدأ، قِس وضعك الحالي. تحتاج إلى نقطة مرجعية لتتأكد أن الإعداد يُحسّن الأداء فعلاً — وتكتشف بسرعة إن حدث خطأ ما.

شغّل موقعك عبر هذه الأدوات أولاً:

• WebPageTest — يعطيك تفصيلاً كاملاً للتحميل ووقت أول بايت (TTFB)
• GTmetrix — يُظهر وقت استجابة السيرفر إلى جانب مقاييس الواجهة الأمامية
• New Relic أو Datadog — إن أردت رؤية تفصيلية على مستوى استعلامات قاعدة البيانات

دوّن قيم TTFB ومتوسط وقت استجابة السيرفر. هذه هي الأرقام التي سيُغيّرها Redis.

تثبيت Redis على السيرفر

على سيرفر Debian/Ubuntu، التثبيت بسيط:

sudo apt update sudo apt install redis-server

على CentOS/RHEL:

sudo yum install redis sudo systemctl enable redis sudo systemctl start redis

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

redis-cli ping # يجب أن يُعيد: PONG

أمّن Redis قبل أي خطوة أخرى

بشكل افتراضي، يستمع Redis على جميع الواجهات دون أي مصادقة. هذا خطر أمني جدي. قبل أن تربط تطبيقك به، افعل هذه الأشياء الثلاثة:

1. اربط Redis بـ localhost فقط. افتح /etc/redis/redis.conf واضبط:

bind 127.0.0.1

2. عيّن كلمة مرور قوية. في نفس ملف الإعداد:

requirepass your_strong_password_here

3. عطّل الأوامر الخطرة. أضف هذه الأسطر لإعادة تسمية الأوامر التي يمكن استخدامها لمسح الكاش أو قراءة بيانات الإعداد:

rename-command FLUSHALL "" rename-command CONFIG ""

أعد تشغيل Redis بعد أي تغيير في الإعداد:

sudo systemctl restart redis

إعداد التخزين المؤقت للسيرفر مع WordPress

WordPress هو أكثر حالات الاستخدام شيوعاً لتخزين كائنات Redis المؤقت، وهو المكان الذي ستلاحظ فيه أكبر تحسن. WordPress يُجري الكثير من استدعاءات قاعدة البيانات — القوائم، والودجات، وبيانات المستخدمين، وبيانات المنشورات — ومعظمها يتكرر في كل تحميل للصفحة.

لربط WordPress بـ Redis، تحتاج إلى شيئين: إضافة PHP Redis وملف كاش خاص.

تثبيت إضافة PHP Redis

sudo apt install php-redis sudo systemctl restart php8.2-fpm # عدّل حسب إصدار PHP لديك

تأكد من تحميله:

php -m | grep redis

إعداد WordPress لاستخدام Redis

أضف تفاصيل اتصال Redis إلى wp-config.php:

define('WP_REDIS_HOST', '127.0.0.1'); define('WP_REDIS_PORT', 6379); define('WP_REDIS_PASSWORD', 'your_strong_password_here'); define('WP_REDIS_DATABASE', 0); define('WP_REDIS_TIMEOUT', 1); define('WP_REDIS_READ_TIMEOUT', 1);

قيم المهلة الزمنية مهمة. إن توقف Redis، لا تريد أن يظل WordPress منتظراً — مهلة ثانية واحدة تعني أنه سيعود إلى قاعدة البيانات بشكل سلس بدلاً من انتهاء المهلة أمام زوارك.

على الاستضافة المُدارة، غالباً ما تتم هذه العملية كلها تلقائياً. نحن نثبّت ملف كاش Redis تلقائياً عند تفعيل تخزين الكائنات المؤقت، لذا لا حاجة لتعديل الملفات يدوياً أو تثبيت الإضافات — يعمل مباشرة.

كيف تعرف أن إعداد التخزين المؤقت للسيرفر يعمل

بمجرد ربط Redis، تحتاج إلى التأكد من أنه يُخزّن فعلاً — وليس مجرد جالس دون فائدة.

تحقق من معدل الإصابة (Hit Rate)

معدل الإصابة يُخبرك بنسبة الطلبات التي يُقدّمها Redis من الذاكرة مقابل تلك التي تصل إلى قاعدة البيانات. شغّل هذا في redis-cli:

redis-cli info stats | grep -E 'keyspace_hits|keyspace_misses'

احسب معدل الإصابة: hits / (hits + misses) × 100.

معدل إصابة فوق 80% يُعدّ جيداً. إن كان أقل من 60% فعليك التحقيق — قد يكون الكاش صغيراً جداً، أو ينتهي بسرعة، أو لا يُملأ بشكل صحيح.

تبدأ معدلات الإصابة منخفضة وترتفع مع الوقت مع دفء الكاش. لا تقلق إن رأيت 30% في الساعة الأولى. تحقق مجدداً بعد 24 ساعة من حركة المرور الطبيعية.

راقب استخدام الذاكرة

redis-cli info memory | grep used_memory_human

حدد حداً للذاكرة في إعداد Redis لمنعه من استهلاك كل RAM المتاح:

maxmemory 256mb maxmemory-policy allkeys-lru

سياسة allkeys-lru تُخبر Redis بحذف المفاتيح الأقل استخداماً عند الوصول إلى حد الذاكرة. هذه هي السياسة المناسبة لأعباء التخزين المؤقت — تحتفظ بالبيانات الساخنة وتتخلص من الباردة.

الأخطاء الشائعة التي تُعطّل الأمور

تخزين بيانات خاصة بالمستخدم

إن كان موقعك يضم مستخدمين مسجّلين، كن حذراً بشأن ما يُخزَّن. تقديم بيانات جلسة مستخدم لمستخدم آخر خطأ فادح. تأكد من أن مفاتيح الكاش تتضمن معرّفات المستخدمين حيثما كان ذلك مناسباً، واستثنِ الصفحات التي تتطلب تسجيل الدخول من التخزين المؤقت الكامل للصفحة.

عدم تحديد وقت انتهاء الصلاحية

كل كائن مُخزَّن يجب أن يكون له TTL (وقت للعيش). بدونه، يمكن أن تبقى البيانات القديمة في Redis إلى أجل غير مسمى. لمعظم حالات استخدام كاش كائنات WordPress، TTL بين ساعة واحدة و24 ساعة معقول حسب مدى تكرار تغيير محتواك.

نسيان مسح الكاش بعد النشر

عند رفع تغييرات في الكود أو تحديث المحتوى، قد تكون بياناتك المُخزَّنة قديمة. أضف خطوة مسح الكاش إلى عملية النشر لديك:

redis-cli FLUSHDB # يمسح قاعدة البيانات الحالية فقط، وليس كل Redis

استخدم FLUSHDB بدلاً من FLUSHALL إن كنت تشغّل تطبيقات متعددة على نفس نسخة Redis.

كيف يبدو إعداد التخزين المؤقت الجيد في الواقع

إعداد التخزين المؤقت للسيرفر المُهيَّأ بشكل صحيح يُحقق عادةً:

• انخفاض TTFB من 400–800ms إلى أقل من 100ms على الطلبات المُخزَّنة
• انخفاض استخدام CPU لقاعدة البيانات بنسبة 40–70%
• القدرة على التعامل مع ارتفاعات حركة المرور دون أن تصبح قاعدة البيانات عائقاً

هذه ليست أرقاماً نظرية. هذا ما تراه عندما يكون Redis دافئاً بشكل صحيح وتطبيقك يستخدمه بالشكل الصحيح.

المفتاح هو الصبر والمراقبة. اضبط التخزين المؤقت، راقب معدل الإصابة لمدة 48 ساعة، وقارن TTFB بالقياس المرجعي الذي أخذته قبل البدء. البيانات ستُخبرك إن كان يعمل — وأين تضبط الأمور بعد ذلك.