Redis صار في خمس عشرة سنة القطعة المركزية الصامتة لشبه كلّ معماريات backend الحديثة. في الأصل cache بسيط مفتاح-قيمة كتبه Salvatore Sanfilippo في 2009، تطوّر المشروع إلى محرّك بيانات متعدّد الأغراض — قادر على لعب دور cache موزَّع، broker رسائل، طابور غير متزامن، محرّك pub/sub لحظي، سجلّ أحداث مُرَتَّب، بل ومحرّك بحث في الذاكرة. حين يجب على تطبيق ويب خدمة آلاف الطلبات في الثانية تحت 10 ms، Redis إحصائيًّا حاضر في مكان ما.

يُخَطِّط هذا المقال منظومة Redis في 2026: نسخة 8.x المستقرّة (Redis 8.6 هي آخر minor للسلسلة Open Source)، عائلات الاستعمال في الإنتاج، أنماط caching الكلاسيكية، منظومة BullMQ لـ queues Node.js، نموذج pub/sub وStreams، وخيارات الإتاحة العالية (Sentinel وCluster). كلّ موضوع فرعي عملي له دليل خطوة بخطوة في هذه السلسلة.

عقد ونصف من التطوّر: من cache بسيط إلى محرّك بيانات متعدّد

Redis — اختصار REmote DIctionary Server — وُلِد في 2009 حين اصطدم Salvatore Sanfilippo، مؤسّس startup تحليلات ويب إيطالية، بحدود MySQL لتخزين عدّادات لحظية. نسخته الأولى، كُتبت بـ C في أسابيع قليلة، تتّسع في بضعة آلاف من أسطر C وعرضت ثلاث أنواع بيانات أوّلية — strings، lists، sets — تُوُسِّعت سريعًا بـ sorted sets وhashes. هذه البساطة الجذرية، مع أداء لا يُضاهى (أكثر من 100,000 عملية/ثانية على نواة واحدة)، رفعت المشروع إلى مرتبة أداة لا غنى عنها في أقلّ من سنتين.

تاريخ النسخ تبع مسارًا من التخصّص التدريجي. Redis 2.6 (2012) أدخل سكريبتات Lua لذرّية تسلسلات العمليات. Redis 3.0 (2015) جلب وضع Cluster مع sharding تلقائي وfailover. Redis 5.0 (2018) شكّل منعطفًا بوصول Streams، بنية بيانات تُحَوِّل Redis إلى بديل خفيف لـ Apache Kafka للاستعمالات تحت التيرابايت. Redis 6.0 (2020) أدخل multithreading I/O — دون كسر النموذج المنفرد monothread لتنفيذ الأوامر — وACL متعدّد المستخدمين.

Redis 7.0 (أبريل 2022) وَحَّد المجموع بـ دوالّ من جانب الخادم، ACL دقيق على مستوى الأمر، وامتداد بروتوكول RESP3. Redis 7.4 (2024) أضاف عدّادات مُهَشَّرة وعدّة أوّليات للبرمجة المتزامنة الموثوقة. سلسلة Redis 8، المنشورة منذ 2025، حوّلت الأداء جذريًّا: Redis 8.0 ضاعف throughput على أحمال مختلطة وأدخل محرّك بحث full-text وشعاعي مدمج (Redis Search) ولهجة JSON أصلية (Redis JSON). Redis 8.4 (مطلع 2026) أدخل دلالات compare-and-set أصلية، عمليات multi-key TTL بـ MSETEX، ومعالجة محسّنة لـ consumer groups في Streams. Redis 8.6، الصادر في أبريل 2026، هو النسخة الحالية الموصى بها لأيّ مشروع جديد.

نموذج التنفيذ: monothread، في الذاكرة، مع استمرارية

لماذا Redis سريع جدًّا

الأداء الاستثنائي يستند إلى ثلاث خيارات معمارية جذرية تبدو غير حدسية. أولًا: كلّ البيانات تعيش في RAM. القراءة/الكتابة في الذاكرة نمطيًّا 100,000 مرّة أسرع من قرص، و1,000 مرّة أسرع من SSD. ثانيًا: تنفيذ الأوامر صارمًا monothread. هذا يُلغي كلّ تزامن وكلّ قفل وكلّ كلفة تبديل سياق — كلّ أمر يُنَفَّذ ذرّيًّا من البداية إلى النهاية. ثالثًا: بروتوكول الشبكة RESP، مُصَمَّم ليكون مُختزَلًا، يُتيح pipelining (إرسال عدّة أوامر دون انتظار الردود).

هذه التوليفة تُنتج زمن استجابة median دون مللي ثانية على شبكة محلّية لمعظم العمليات. على خادم حديث، Redis يصمد throughput بمئات الآلاف من العمليات/ثانية على نواة واحدة. multithreading المُقَدَّم في Redis 6 يخصّ فقط I/O الشبكي؛ محرّك تنفيذ الأوامر يبقى أساسيًّا monothread.

الاستمرارية: RDB وAOF

طابع « في الذاكرة » لا يعني « متطاير ». Redis يعرض آليّتَي استمرارية مُتَكامِلَتَين تُتيحان النجاة من إعادة التشغيل دون فقدان الحالة. RDB (Redis Database) يُنتج دوريًّا snapshots ثنائية مُكَثَّفة لكامل dataset. سريعة التحميل عند إعادة التشغيل ومثالية للنسخ الاحتياطي، لكنّها تُدخل نافذة فقدان بيانات بين snapshotين — نمطيًّا بضع دقائق.

AOF (Append Only File) يُسَجِّل كلّ أمر كتابة في ملفّ نصّي يُعاد تشغيله عند الإقلاع. فقدان البيانات في الحدّ الأدنى (قابل للضبط على ثانية واحدة في الأسوأ) لكنّ الملفّ ينمو بلا حدود ويجب إعادة كتابته دوريًّا في الخلفية. الإعداد الموصى به في الإنتاج يجمع الاثنين: RDB للنسخ اليومية، AOF للديمومة الدقيقة. دليل تثبيت Redis 8 RDB+AOF يُفَصِّل الإجراء.

عائلات الاستعمال الثمانية في الإنتاج

Caching موزَّع (cache-aside)

الاستعمال التاريخي والمهيمن دائمًا هو cache أمام قاعدة بيانات علاقية. النمط الكلاسيكي، cache-aside، يستجوب Redis قبل القاعدة: إن كانت البيانات حاضرة (cache hit)، تُقَدَّم فورًا؛ إن غابت (cache miss)، التطبيق يقرأ القاعدة، يكتب النتيجة في Redis مع TTL، ويُقَدِّمها. على تطبيقات بحركة عالية، معدّل hit بـ 90% يُتيح نمطيًّا تخفيف الحِمل على القاعدة العلاقية بعشرة أضعاف.

الأنماط المتقدّمة (write-through، write-behind، invalidation بـ tags) مُغطّاة في أنماط cache بـ Redis 8.

جلسات HTTP مركزية

في معمارية أفقية حيث عدّة instances للتطبيق تخدم خلف load balancer، تخزين جلسات المستخدم في ذاكرة instance واحد يُسَبِّب مشكلة فور توجيه طلب إلى آخر. Redis يحلّ هذا باستضافة الجلسات فوق طبقة التطبيق، مُتاحة بانتظام لكلّ instances. زمن الاستجابة دون مللي ثانية يجعل هذا التوسيط غير مرئي للمستخدم.

Rate limiting وعدّادات ذرّية

الأوامر INCR وEXPIRE تُتيح تنفيذ rate limiter متين في تعليمتين: زيادة عدّاد مُحَدَّد بـ IP أو user-id، وتطبيق TTL بثانية أو دقيقة أو ساعة. إن تجاوزت القيمة المُرجَعة الحدّ المسموح، ارفض الطلب بـ 429 Too Many Requests. الطبيعة الذرّية لأوامر Redis تضمن ألّا يتسلّل أيّ طلب بين الزيادة والتحقّق.

طوابير غير متزامنة (BullMQ)

للمعالجات الثقيلة التي يجب ألّا تحجب ردّ HTTP — إرسال بريد، توليد PDF، تحويل فيديوهات، دفع غير متزامن — Redis يخدم broker لمكتبات مثل BullMQ (Node.js)، Sidekiq (Ruby)، أو RQ (Python). خادم الويب يدفع « jobs » في queue Redis، وpool من workers مستقلّة يستهلكها. BullMQ 5.76 (آخر نسخة في مايو 2026) تُضيف flow producers لتبعيّات DAG، rate limits لكلّ queue، dead letter queues، ودعم أصلي لـ OpenTelemetry. دليل BullMQ + Redis 8 يُغطّي الأنماط المتقدّمة.

Pub/Sub لحظي

Redis يعرض نظام publish/subscribe عبر الأوامر PUBLISH، SUBSCRIBE، PSUBSCRIBE. عميل يَنشر رسالة على قناة، وكلّ العملاء المُشترَكين يتلقّونها فورًا. آليّة مثالية لنشر أحداث بين عمليات التطبيق (مثلًا إبطال cache محلّي عند تغيّر بيانات)، تنفيذ chat لحظي، أو بثّ إشعارات WebSocket. خلافًا لـ Streams، pub/sub Redis بلا ذاكرة: إن لم يكن مشترَك يسمع وقت PUBLISH، الرسالة مفقودة.

Streams (سجلّ أحداث دائم)

Streams Redis، المُقَدَّمة في 5.0، تسدّ هذا الحدّ بدقّة. Stream بنية log مُرَتَّبة ودائمة، مع consumer groups تُتيح لعدّة workers توزيع الرسائل مع ضمان عدم معالجة رسالة مرّتين. النموذج قريب جدًّا من Kafka، لكن ببنية أبسط جذريًّا: binary Redis وحيد يحلّ محلّ Zookeeper + Kafka brokers + Schema Registry. لأحجام من بضعة ملايين إلى بضع مئات ملايين أحداث يوميًّا، يكفي تمامًا.

بحث وفهرسة (Redis Search)

منذ Redis 8، وحدة Redis Search مدمجة أصليًّا وتُوَفِّر محرّك بحث full-text وشعاعي. يفهرس مستندات JSON أو hashes، يدعم استعلامات boolean معقّدة، scoring TF-IDF / BM25، تجميعات بأسلوب SQL، وبحث بالتشابه الشعاعي لتطبيقات RAG. لكثير من التطبيقات التي كانت ستنشر cluster Elasticsearch مخصَّصًا، Redis Search يُمَثِّل الآن بديلًا مع تشغيل مُبَسَّط جذريًّا.

أقفال موزَّعة (Redlock)

حين يجب على عدّة عمليات تنسيق الوصول إلى مورد مشترك، قفل موزَّع ضروري. نمط Redlock، وَضَعه Salvatore Sanfilippo بنفسه، يستعمل SET NX EX لاكتساب قفل ذرّيًّا. التحرير يجب أن يتمّ بسكريبت Lua يتحقّق أنّ القفل ينتمي فعلًا للعملية المُتَّصِلة، لتجنّب أن يُسَبِّب timeout تحريرًا عرضيًّا.

منظومة العملاء: عميل لكلّ لغة

Redis له عملاء رسميّون أو شبه رسميّين لكلّ لغات الإنتاج عمليًّا. Node.js: ioredis (الأكثر شعبية، يدعم Cluster وSentinel أصليًّا) وnode-redis (العميل الرسمي). Python: redis-py. Java: Jedis للوضع المتزامن، Lettuce للوضع غير المتزامن (تكامل أصلي مع Spring Boot). Go: go-redis. PHP: امتداد phpredis أعلى أداءً من Predis.

كلّ هذه العملاء تُنَفِّذ pipelining، معاملات تفاؤلية عبر MULTI/EXEC، سكريبتات Lua، وربط بـ cluster sharded أو Sentinel HA. التوافق التصاعدي ممتاز: عميل مكتوب لـ Redis 5 يعمل دون تعديل مع Redis 8.

الإتاحة العالية: Sentinel أم Cluster

Sentinel للـ failover التلقائي

Redis Sentinel نظام مراقبة موزَّع يُراقب maître Redis وعدّة replicas. إن صار الـ maître غير قابل للوصول، Sentinel ينتخب maître جديدًا تلقائيًّا من الـ replicas ويُعيد تهيئة العملاء. هذه الآلية تُناسب النشرات المعتدلة (حتى بضع مئات جيغا) حيث التحمّل للأعطال أولى من التوسيع الأفقي. النشر الأدنى ثلاثي Sentinels (للـ quorum) يُشرف على maître وواحد أو اثنين replicas. دليل Redis Sentinel وCluster يُغطّي الإعداد الكامل.

Cluster للتوسيع الأفقي

ما فوق بضعة تيرابايت من dataset، أو حين يتجاوز throughput المطلوب قدرات maître وحيد، وضع Cluster يُتيح sharding تلقائي للبيانات على عدّة maîtres. Redis Cluster يستعمل 16,384 slots hash مُوَزَّعة بين الـ maîtres، مع بروتوكول gossip لنشر تغييرات الطوبولوجيا. كلّ maître يمكن أن يكون له replicas خاصّة. تعقّد التشغيل يرتفع — يلزم إدارة resharding، rebalancing، وزمن inter-DC — لكنّ النموذج يتوسّع خطّيًّا.

اختيار نسخة Redis

ثلاثة فروع مدعومة في مايو 2026:

Redis 8.6 (أبريل 2026) — آخر minor مستقرّة، موصى بها لأيّ مشروع جديد. تجلب Redis Search أصلي، Redis JSON، أداء مضاعَف.
Redis 7.4.6 (فبراير 2026) — فرع LTS مُجَرَّب. متوافق مع غالبية منظومات العملاء دون تعديل. الخيار المحافظ للهجرة من Redis 6.
Redis 6.2 — مدعوم للنشرات القائمة لكن لا يجب استعماله لمشاريع جديدة.

المشروع انتقل تحت ترخيص SSPLv1 + RSALv2 في 2024 للنسخ ≥ 7.4، ممّا يمنع مزوّدي السحاب من إعادة بيع Redis كخدمة مُدارة دون عقد مع Redis Inc. للنشرات الذاتية أو عبر Redis Cloud الرسمي، هذا لا يُغيِّر شيئًا. بديل مفتوح المصدر، Valkey، fork BSD-3-Clause لـ Redis 7.2.4 أُطلق في مارس 2024 بـ AWS، Ericsson، Oracle، وGoogle تحت حكم Linux Foundation، مَصون نشطًا — خيار للاعتبار إن كان الترخيص عائقًا قانونيًّا.

دلائل السلسلة

الدلائل الستّة التالية تُعَمِّق كلّ جانب، بخطوات مُرَقَّمة وكود مُختبَر ضدّ Redis 8.6:

أخطاء شائعة

الخطأ	السبب	الحلّ
استعمال Redis كقاعدة بيانات رئيسية دون استمرارية	RDB وAOF مُعَطَّلان	فعِّل AOF مع `appendfsync everysec` على الأقلّ
تخزين كائنات JSON في مفتاح string بسيط	تجاهل البنى المتخصّصة	استعمل `HSET` للكائنات، `SADD` للمجموعات الفريدة
كشف Redis عامّيًّا دون توثيق	الإعداد الافتراضي بلا `requirepass` ولا ACL	فعِّل ACL أو `requirepass`، وbind على 127.0.0.1
عدم تحديد TTL على مفاتيح cache	نموّ ذاكرة بلا حدود	استعمل دائمًا `SET key value EX seconds`
استعمال `KEYS *` في الإنتاج	يحجب Redis طوال الفحص الكامل	استعمل `SCAN` تكراريًّا
تشغيل أوامر فُرادى بدل pipelining	كلفة شبكية متراكمة	اجمع الأوامر عبر `pipeline()` أو `MULTI`/`EXEC`
تخزين قيم > 512 ميغا في مفتاح	حدّ صارم على حجم القيمة	جَزِّئ إلى قطع أو استعمل بنية مناسبة (list، hash)

FAQ

Redis أم Memcached لـ cache صرف؟ Memcached أسرع قليلًا وأبسط لـ cache صارم بلا استمرارية. Redis يعرض أكثر بكثير: استمرارية، بنى بيانات غنية، pub/sub، streams، Lua. لمشروع جديد، Redis تقريبًا دائمًا الخيار الصحيح.

Redis يحلّ محلّ Apache Kafka؟ لأحجام دون تيرابايت/يوم، Redis Streams يُغَطّي معظم الاحتياجات ببنية أبسط بكثير. ما فوق ذلك — multi-DC، أحجام ضخمة، احتفاظ بأشهر — Kafka يبقى أعلى. Redis وKafka يتعايشان غالبًا.

ماذا نفعل إن كانت RAM غير كافية؟ ثلاثة خيارات: (1) زيادة RAM — Redis يتوسّع عموديًّا جيّدًا حتى بضع مئات جيغا؛ (2) تهيئة سياسة eviction (maxmemory-policy allkeys-lru)؛ (3) الانتقال إلى Cluster لـ sharding.

Pub/Sub أم Streams؟ Pub/Sub إن قبلنا فقدان الرسائل حين لا يسمع مُستهلِك. Streams إن أردنا استمرارية، تتبّع تقدّم بـ consumer group، وضمان عدم تفويت رسالة. لإشعار push UI لحظي، pub/sub. لحدث عمل (طلب أُنشئ، دفع تلقّي)، streams.

هل Redis آمن للبيانات الحسّاسة؟ يُشَفِّر في حالة السكون عبر تشفير نظام الملفّات، والنقل عبر TLS منذ Redis 6. التوثيق بـ ACL متعدّد المستخدمين. الخادم نفسه لا يُشَفِّر المحتوى في الذاكرة — اعتمد على تشفير تطبيقي إن لزمت السرّية على مستوى العملية.

استضافة ذاتية أم خدمة مُدارة؟ لفريق تقني متواضع، Redis مُدار (Redis Cloud، AWS ElastiCache، Upstash) أغلى مطلقًا لكن يتفادى عبء الإدارة. لأحجام كبيرة أو قيود سيادة، الاستضافة الذاتية على VPS سهلة جدًّا.

مراجع

التوثيق الرسمي Redis — مرجع الأوامر والوحدات والإعداد
ملاحظات إصدارات Redis على GitHub
توثيق BullMQ
مدوّنة Redis Inc.
Valkey — fork مفتوح من Redis 7.2 مَصون من Linux Foundation
مرجع أوامر Redis

Redis 8: caching، queues، pub/sub، وstreams لتطبيقات الإنتاج