كيفية تثبيت Redis وتحسينه على VPS: دليل شامل لعام 2026

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

يغطي هذا الدليل نسخة Redis واحدة على VPS بنظام Debian أو Ubuntu نفسه الذي يعمل عليه تطبيقها، مثبَّتة من مستودعات التوزيعة ومتاحة عبر loopback فقط. ويتضمن فحصًا وظيفيًا صغيرًا، وإعداد ذاكرة كائنات مؤقتة (object cache) لـ WordPress، ومثالًا مستقلًا بـ Node.js. وهو ليس دليلًا للوصول عن بُعد أو للتوافر العالي أو لنشر قاعدة بيانات دائمة.

قبل أن تبدؤوا: حدّدوا ما سيخزّنه Redis#

الذاكرة المؤقتة القابلة لإعادة البناء تحتوي على بيانات يستطيع تطبيقكم إعادة إنشائها من قاعدة بياناته المرجعية أو من مصدر آخر. يجب أن تكون حالات غياب الكاش (cache misses) والانتهاء والإخلاء (eviction) وإعادة التشغيل آمنة: على التطبيق أن يجلب البيانات الأصلية ويعيد بناء الكاش. حدّدوا قيم TTL وقواعد إبطال مناسبة، وتجنبوا تقديم بيانات خاصة مخزّنة مؤقتًا إلى المستخدم الخطأ.

قد تكون لدى الجلسات والمهام في الطوابير والسجلات المرجعية متطلبات مختلفة للفقدان والاستعادة. لا تخلطوها في نسخة قد تُخلي أي مفتاح. استخدموا نسخة Redis منفصلة واستراتيجية دوام ونسخ احتياطي واستعادة مصمَّمة عن قصد عندما يجب أن تنجو البيانات من الأعطال. إن Redis Pub/Sub ليس طابور مهام دائمًا.

تشرح وثائق الإخلاء في Redis لماذا يمكن لـ allkeys-lru إزالة أي مفتاح. وعلى العكس، يتسبب noeviction في فشل عمليات الكتابة المتأثرة عند بلوغ حد الذاكرة؛ وهو لا يوفر نسخًا احتياطية ولا ديمومة.

المتطلبات والنطاق#

• إصدار مدعوم من Debian أو Ubuntu يستخدم systemd، ووصول SSH، وصلاحيات sudo.
• VPS تجريبي جديد أو نافذة صيانة معتمدة. تحققوا من وجود خدمة Redis قائمة وتطبيقات تعتمد عليها قبل تغيير أي شيء.
• سعة ذاكرة RAM وقرص مناسبة لحِمل عملكم، بما في ذلك نظام التشغيل وقاعدة البيانات وPHP أو Node.js وعبء Redis وأي عمليات دوام. لا توجد صيغة عامة آمنة لذاكرة RAM في VPS.
• تطبيق على المضيف نفسه. للحاويات فضاءات أسماء شبكية خاصة بها: العنوان 127.0.0.1 داخل حاوية لا يشير عادةً إلى المضيف.

الخطوات أدناه إجراء ينبغي التحقق منه على إصدارتكم المختارة، وليست ادعاءً بأن التثبيت اختُبر على كل إصدار من Debian أو Ubuntu. تختلف إصدارات حزم التوزيعة؛ ولا يعد هذا الدليل بإصدار محدد من خادم Redis.

الخطوة 1: ثبّتوا حزم التوزيعة#

حدّثوا فهرس الحزم، ثم افحصوا الحزم المرشحة ومصادر مستودعاتها:

sudo apt update
apt-cache policy redis-server redis-tools

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

sudo apt install redis-server redis-tools
systemctl status redis-server --no-pager
systemctl cat redis-server
redis-server --version
redis-cli --version

راجعوا التغييرات التي يقترحها APT قبل التأكيد. قد تشغّل الحزم Redis تلقائيًا. توضح وحدة الخدمة أي ملف إعدادات يُحمَّل؛ والمسار المعتاد هو /etc/redis/redis.conf، كما توثّقه صفحة دليل Redis في Debian وصفحة دليل Redis في Ubuntu. وإذا اختلفت الوحدة أو المسار، فاستخدموا الإعدادات المثبَّتة فعليًا بدلًا من إنشاء نسخة ثانية.

الخطوة 2: أبقوا Redis محليًا واحموا الوصول#

خذوا نسخة احتياطية من الإعدادات قبل تعديلها. في تثبيت جديد يستخدم المسار المعتاد:

sudo cp -a /etc/redis/redis.conf /etc/redis/redis.conf.before-local-cache
sudoedit /etc/redis/redis.conf

حدّثوا التوجيهات الموجودة بدلًا من إلحاق نسخ مكررة عشوائيًا. بالنسبة إلى إعداد loopback عبر IPv4 فقط المستخدم في هذا الدليل:

bind 127.0.0.1
protected-mode yes

افحصوا الملفات المضمَّنة وخيارات سطر أوامر الخدمة بحثًا عن تجاوزات. وإذا أبقيتم عمدًا على loopback عبر IPv6، فتحققوا من أنه ::1 فقط، وليس مستمعًا IPv6 على جميع الواجهات. لا تربطوا على 0.0.0.0 أو ::.

لا تفتحوا المنفذ 6379 للإنترنت العام. راجعوا جدار حماية المضيف وأي جدار حماية لدى المزوّد. وإذا كان UFW مثبَّتًا، فيمكن للأمر sudo ufw status verbose أن يعرض قواعده الحالية؛ ولا تفعّلوا جدار حماية أو تعيدوا ضبطه بشكل أعمى عبر SSH. يقلّل loopback التعرض للشبكة لكنه لا يعزل Redis عن العمليات المحلية الأخرى. كلمة المرور ليست بديلًا عن قيود الشبكة، كما أن AUTH لا يشفّر الحركة، كما يوضح دليل أمان Redis.

المصادقة والأسرار#

بالنسبة إلى نسخة مخصّصة لتطبيق واحد، يمكنكم ضبط التوجيه requirepass الموجود بسرّ قوي وفريد. عيّنوه عبر محرر محمي أو آلية الأسرار في أداة إدارة الإعدادات لديكم؛ ولا تلصقوا أسرارًا حقيقية في أوامر الطرفية أو التسجيلات أو التحكم بالإصدارات أو هذا الدرس. قيّدوا الوصول إلى ملف الإعدادات للمسؤول وحساب خدمة Redis.

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

الخطوة 3: اختاروا إعدادات ذاكرة الكاش والدوام#

عيّنوا maxmemory محدودًا يناسب سعتكم الفعلية وحِمل عملكم. فمثلًا، ما يلي توضيح للإعدادات فقط، وليس توصية بالحجم:

maxmemory 256mb
maxmemory-policy allkeys-lru

استخدموا سياسة الإخلاء هذه فقط لبيانات الكاش القابلة لإعادة البناء. إن maxmemory ليس حدًّا صارمًا على إجمالي ذاكرة عملية Redis: فعبء المخصِّص (allocator) وبعض المخازن المؤقتة ونشاط الدوام قد تتطلب هامشًا إضافيًا. قيسوا الذاكرة المقيمة لـ Redis وضغط المضيف عمومًا إلى جانب استخدام التطبيق.

قرّروا الدوام بشكل منفصل. قد لا تحتاج ذاكرة مؤقتة قابلة للتخلص منها إلى دوام على القرص، شريطة أن يتحمل التطبيق إعادة تشغيل بارد. وإذا اخترتم عمدًا عدم الدوام في نسخة جديدة للكاش فقط، فالإعدادات ذات الصلة هي:

save ""
appendonly no

لا تطبّقوا هذه الإعدادات على نسخة تحتوي بيانات تحتاجون إلى الحفاظ عليها. قد يقلل الدوام عمل تسخين الكاش، لكن لقطات RDB وAOF لهما مفاضلات مختلفة. وتفعيل AOF ليس ضمانًا مطلقًا للديمومة، كما أن ملفات الدوام ليست بديلًا عن النسخ الاحتياطية خارج المضيف والاستعادة المختبرة.

طبّقوا إعداداتكم المراجَعة خلال نافذة صيانة مناسبة:

sudo systemctl restart redis-server
systemctl is-active redis-server
sudo ss -lntp '( sport = :6379 )'

تحققوا من أن المستمع هو 127.0.0.1:6379، دون أي مستمع عام أو على جميع الواجهات. وإذا فشلت الخدمة أو كان المستمع غير متوقع، فتوقفوا هنا وافحصوا sudo journalctl -u redis-server -n 50 --no-pager. تعاملوا مع السجلات على أنها قد تكون حساسة. ولا تعالجوا مشكلة اتصال محلية بفتح منفذ عام.

الخطوة 4: أجروا فحصًا وظيفيًا صغيرًا#

على نسختكم التجريبية، افتحوا جلسة CLI محلية. وإذا كانت المصادقة مفعّلة، فاستخدموا مطالبة كلمة المرور:

redis-cli -h 127.0.0.1 -p 6379 --askpass

بالنسبة إلى نسخة اختبار محلية دون مصادقة، احذفوا --askpass. داخل CLI، استخدموا مفتاحًا تجريبيًا غير مستخدم:

PING
SET sharpheberg:demo:cli hello EX 60
GET sharpheberg:demo:cli
TTL sharpheberg:demo:cli
DEL sharpheberg:demo:cli
EXIT

السلوك المتوقع، وهو ليس مخرجات اختبار مسجَّلة، هو PONG لـ PING، وOK لـ SET، وhello لـ GET قبل الانتهاء. ينبغي أن يكون TTL موجبًا إذا فُحص سريعًا؛ فالقيمة -2 تعني أن المفتاح لم يعد موجودًا، و-1 تعني أنه بلا انتهاء. ويُرجع DEL القيمة 1 إذا كان المفتاح لا يزال موجودًا، أو 0 إذا كان قد انتهى بالفعل. يثبت هذا الوصول الأساسي إلى الأوامر، وليس تحميلًا أسرع للصفحات أو أداء الاستضافة.

الخطوة 5: اربطوا تطبيقكم#

WordPress: ذاكرة كائنات مؤقتة دائمة، لا ذاكرة مؤقتة للصفحة الكاملة#

توفّر إضافة Redis Object Cache واجهة خلفية دائمة لواجهة object-cache في WordPress. و«دائمة» هنا تعني أن الكائنات المخزَّنة مؤقتًا يمكن إعادة استخدامها عبر طلبات PHP؛ ولا تعني أن دوام Redis على القرص مفعّل. ولا تخزّن الإضافة تلقائيًا جميع استعلامات SQL ولا تنتج ذاكرة مؤقتة لصفحات HTML كاملة.

1. خذوا نسخة احتياطية من إعدادات WordPress وتحققوا مما إذا كان drop-in لذاكرة الكائنات مثبَّتًا بالفعل.
2. ثبّتوا Redis Object Cache وفعّلوه على موقع staging أولًا.
3. وفّروا كلمة مرور Redis عبر آلية إدارة الأسرار في بيئة تشغيل PHP لديكم. في المثال أدناه، اسم متغير البيئة هو REDIS_PASSWORD؛ ويستلمه WordPress عبر الثابت WP_REDIS_PASSWORD.
4. أضيفوا ما يلي إلى ملف wp-config.php الفعلي لموقعكم، قبل أن يحمّل WordPress الملف wp-settings.php. استخدموا بادئة (prefix) فريدة لهذا الموقع.

$redisPassword = getenv('REDIS_PASSWORD');
if ($redisPassword === false || $redisPassword === '') {
    throw new RuntimeException('Redis secret is not available to PHP.');
}

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 0);
define('WP_REDIS_PREFIX', 'example-site:');
define('WP_REDIS_PASSWORD', $redisPassword);
unset($redisPassword);

يفشل هذا المثال المصادَق عليه عمدًا بوضوح إذا كان السر مفقودًا؛ اضبطوا بيئة التشغيل أولًا وتحققوا في staging لتجنب تعطيل موقع حي. لا يجعل التصدير (export) في الصدفة وحده المتغير متاحًا لـ PHP-FPM أو Apache عادةً. وفّروه صراحةً لمجمع عمال PHP أو الخدمة الصحيحة عبر إعدادات محمية أو تكامل أسرار، ثم أعيدوا تحميل بيئة التشغيل تلك حسب الحاجة. وتأكدوا من أن WP-CLI يتلقى السر نفسه عند استخدامه. لا تكشفوا قيم البيئة عبر صفحات التصحيح العامة أو السجلات.

وإذا كانت نسخة Redis المعزولة لديكم بلا مصادقة عن قصد، فاحذفوا كتلة تحميل كلمة المرور وWP_REDIS_PASSWORD معًا؛ ولا تضعوا سرًّا فارغًا في المثال المصادَق عليه. وبالنسبة إلى مستخدم ACL، اتبعوا صيغة اسم المستخدم/كلمة المرور الموثّقة في الإضافة.

افتحوا Settings → Redis، وفعّلوا ذاكرة الكائنات المؤقتة، وتحققوا من حالة الاتصال ومن أن drop-in نشط. راجعوا خيارات الإعداد وتعليمات التثبيت من المشرفين على الإضافة لإصداركم المثبَّت. تساعد البادئة الفريدة وقاعدة البيانات المختارة على تجنب التصادمات؛ لكنهما ليسا حدودًا أمنية، ويجب مراجعة سلوك مسح الكاش قبل مشاركة نسخة بين عدة مواقع.

اختبروا السلوك للمستخدم المسجَّل والزائر، وإبطال الكاش، واستجابة التطبيق عند عدم توفر Redis. أما الذاكرة المؤقتة للصفحة الكاملة فطبقة منفصلة لها متطلباتها الخاصة في التوافق والإبطال.

Node.js: مثال مستقل باستخدام node-redis v5#

استخدموا إصدار Node.js مدعومًا ومتوافقًا مع الحزمة. في تطبيقكم أو في مجلد تجريبي منفصل، ثبّتوا الإصدار الرئيسي v5 وسجّلوا الإصدار الذي تم حله:

npm install redis@5
npm ls redis

احتفظوا بملف القفل (lockfile) المولَّد لضمان قابلية التكرار. احفظوا ما يلي باسم node-example.cjs. ينتظر الاتصال الفعلي، ويستخدم مفتاحًا ينتهي وفريدًا لهذا التشغيل، ويتحقق من قيمته وTTL، ويحذف مفتاح العرض التوضيحي هذا فقط. ولا يعتمد على قاعدة بيانات وهمية.

'use strict';

const { createClient } = require('redis');
const { randomUUID } = require('node:crypto');
const assert = require('node:assert/strict');

async function main() {
  const client = createClient({
    url: process.env.REDIS_URL || 'redis://127.0.0.1:6379',
    socket: { connectTimeout: 5000, reconnectStrategy: false }
  });
  client.on('error', () => console.error('Redis client error; check service and connection settings.'));
  const key = `sharpheberg:demo:node:${randomUUID()}`;

  try {
    await client.connect();
    assert.equal(await client.set(key, 'hello', { EX: 60 }), 'OK');
    const value = await client.get(key);
    assert.equal(value, 'hello');
    const ttl = await client.ttl(key);
    assert.ok(ttl > 0 && ttl <= 60, 'Demo key must have a positive TTL');
    console.log('GET:', value);
    console.log('TTL (seconds):', ttl);
    assert.equal(await client.del(key), 1);
    assert.equal(await client.get(key), null);
    console.log('Demo key deleted.');
  } finally {
    if (client.isReady) {
      try {
        await client.del(key);
        await client.close();
      } finally {
        if (client.isOpen) client.destroy();
      }
    } else if (client.isOpen) {
      client.destroy();
    }
  }
}

main().catch(() => {
  console.error('Redis demo failed; no credentials are printed.');
  process.exitCode = 1;
});

شغّلوا node node-example.cjs. العنوان الافتراضي هو redis://127.0.0.1:6379. وبالنسبة إلى نسخة مصادَق عليها، مرّروا REDIS_URL عبر بيئة التشغيل أو مدير الأسرار لديكم؛ تدعم صيغته اسم مستخدم وكلمة مرور، ويجب ترميز محارفهما المحجوزة بصيغة URL. لا تكتبوا عنوانًا يحمل بيانات اعتماد في سجل الصدفة، ولا ترفعوه إلى التحكم بالإصدارات، ولا تطبعوه. أبقوا الوجهة محلية في هذا الدليل.

يوثّق دليل الترحيل إلى node-redis v5 أن close() بديل quit() وأن destroy() هي طريقة قطع الاتصال الفوري. هنا يُغلق العميل بعد الأوامر المنتظَرة ويُدمَّر إذا تعذّر إتمام التنظيف بشكل طبيعي. وقد عُطّلت إعادة الاتصال التلقائي في هذا الفحص القصير حتى لا يؤدي خادم غير قابل للوصول إلى محاولات اتصال لا تنتهي. أما تطبيقات الإنتاج فتحتاج إلى سياسات خاصة بها لإعادة المحاولة والمهلة والرجوع إلى الكاش والإيقاف. وتغطي وثائق استخدام العميل عناوين الاتصال وأحداث الأخطاء.

نطاق الفحص الوظيفي: جرى فحص دورة PING/SET/GET/TTL/DEL ومثال Node.js مع Redis 8.0.2 على Debian 13 وnode-redis 5.12.1 في عملية تجريبية للتخلص منها على loopback فقط. استُخرجت الحزم إلى مجلد اختبار ولم تُثبَّت كخدمة على المضيف. لا تتحقق هذه الفحوصات من كل إصدار توزيعة، ولا من تثبيت systemd، ولا من تكامل WordPress، ولا من أداء الإنتاج.

الخطوة 6: راقبوا الكاش دون اختبار حِمل#

في جلسة CLI محلية مصادَق عليها، افحصوا هذه الأقسام:

INFO stats
INFO memory
INFO clients

من الحقول المفيدة keyspace_hits وkeyspace_misses وevicted_keys وexpired_keys وused_memory_human وused_memory_rss وconnected_clients. لا يوجد حقل عام باسم hit_rate يمكن استخراجه من INFO.

خلال فترة مراقبة محددة، سجّلوا التغيّر في عدد الإصابات (hits) والإخفاقات (misses). فقط إذا كان مجموعهما موجبًا، احسبوا delta_hits / (delta_hits + delta_misses) × 100. تجاهلوا الفترات التي تعبر إعادة ضبط للعدّادات أو إعادة تشغيل. هذه نسبة بحث عن المفاتيح على مستوى النسخة كلها، وليست نسبة إصابة لكاش الصفحات ولا مقياسًا مباشرًا لانخفاض استعلامات SQL.

قيسوا أزمنة استجابة التطبيق وحِمل قاعدة البيانات والأخطاء واستخدام الموارد قبل التكامل وبعده في ظل حركة مرور مماثلة. ميّزوا بين الكاش البارد والدافئ ووثّقوا الإصدارات والظروف. فاختبار إنتاجية اصطناعي لـ SET/GET لا يمكنه إثبات سرعة صفحات WordPress، كما أن نجاح PING أو هذا العرض التوضيحي لا يثبت أي اتفاقية مستوى خدمة (SLA) للاستضافة.

استكشاف الأخطاء وإصلاحها وضبط متقدم اختياري#

• رفض الاتصال: افحصوا حالة الخدمة والسجلات وعنوان الربط والمنفذ الفعليين، وما إذا كان التطبيق داخل حاوية. أبقوا على تصميم loopback فقط؛ ولا تضيفوا استثناءً عامًا في جدار الحماية.
• فشل المصادقة: تأكدوا من أن التطبيق يتلقى السر المقصود ويستخدم مستخدم Redis الصحيح. لا تكشفوا كلمات المرور أثناء التصحيح.
• مفاتيح الكاش المفقودة: افحصوا قيم TTL والإبطال وعدّادات الإخلاء والبادئات واختيار قاعدة البيانات. ينبغي أن تكون حالات غياب الكاش آمنة للبيانات القابلة لإعادة البناء.
• ضغط الذاكرة: افحصوا الذاكرة المقيمة لـ Redis وذاكرة المضيف والإخلاء وسلوك التطبيق. أعيدوا النظر في التحجيم بدلًا من اعتبار رفع maxmemory حلًا تلقائيًا.
• العمليات البطيئة: تجنبوا مسح المفاتيح الواسع والأعمال الحاجبة الكبيرة على نسخة مشغولة. استخدموا SCAN التدريجي عند الحاجة إلى التعداد وفكروا في UNLINK للحذف الكبير. ولا تمسحوا البيانات المشتركة أبدًا كاختصار لاستكشاف الأخطاء.

ضبط النواة ليس خطوة تثبيت مطلوبة. توصي إرشادات زمن الاستجابة في Redis بتعطيل Transparent Huge Pages (THP). وإذا كان ذلك ذا صلة بحِمل عملكم المقيس، فرتّبوه مع مضيفكم أو مسؤول نظام التشغيل، واستخدموا طريقة دائمة تدعمها التوزيعة، وخطّطوا لإعادة تشغيل Redis. والكتابة المؤقتة إلى /sys لا تنجو من إعادة الإقلاع. راجعوا overcommit وغيره من تغييرات sysctl بشكل منفصل؛ ولا تنسخوا قيم backlog أو مخازن الشبكة العامة إلى VPS مشترك.

لا تفحصوا حدود واصفات الملفات إلا إذا برّر ذلك طلب الاتصالات الملاحَظ أو الأخطاء:

systemctl show redis-server -p LimitNOFILE

بالنسبة إلى Redis المُدار عبر systemd، استخدموا تجاوز [Service] مراجَعًا بقيمة LimitNOFILE= مقيسة عند الحاجة، ثم أعيدوا تحميل systemd وجدولوا إعادة تشغيل منضبطة. إن تغيير ulimit في الصدفة أو حدود PAM وحدهما لا يكفي لتلك الخدمة. ويشرح توثيق حدود الموارد في systemd إعدادات الخدمة.

خطّطوا لنشر Redis على VPS#

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

قارنوا الموارد والميزات المدرجة حاليًا في خطط VPS Linux من SharpHeberg لاختيار بيئة لتطبيقكم وذاكرة Redis المؤقتة المحلية. حجّموا للمنظومة بأكملها، وأبقوا هامشًا في السعة، وتحققوا من الإعدادات على نظام التشغيل الذي اخترتموه قبل أي نشر في الإنتاج.