بنية التخزين المؤقت والمراسلة

التوافر العالي في Redis

18 دقيقة الدرس 2 من 30

التوافر العالي في Redis

نسخة Redis المفردة تمثّل نقطة فشل واحدة. على نطاق الإنتاج الحقيقي — ملايين العمليات في الثانية، واتفاقيات مستوى الخدمة بأقل من ميلي ثانية، ونشر بدون توقف — تحتاج إلى هيكل قادر على تحمّل فشل العقد، وانقطاع الشبكة، وعمليات الترقية الدورية دون تدخل يدوي. يأتي Redis بآليتين متكاملتين للتوافر العالي: Sentinel لانتخاب القائد على زوج من الأساسي/النسخة الاحتياطية، وRedis Cluster للتوزيع المجزّأ والذاتي الإصلاح.

Redis Sentinel

Sentinel هو عملية مستقلة (أو مجموعة من العمليات) تراقب العقدة الأساسية ونسخها الاحتياطية، وتحدد متى تتعطل الأساسية، وتنتخب أساسية جديدة، وتعيد كتابة إعدادات الاتصال للعملاء. يُعدّ الخيار الأمثل عندما تسع مجموعة البيانات عقدة واحدة (عادةً أقل من ~100 غيغابايت من مجموعة العمل النشطة) وتريد تجاوز الأعطال تلقائيًا دون تجزئة البيانات.

الهيكل: شغّل عددًا فرديًا من نسخ Sentinel (ثلاث كحدٍّ أدنى، وعادةً ثلاث أو خمس) موزّعة عبر مناطق التوافر. يستخدم Sentinel تصويتًا قائمًا على النصاب: لا يبدأ تجاوز العطل إلا عندما يتفق quorum من نسخ Sentinel على أن الأساسية غير متاحة، ولا تُؤكَّد الأساسية الجديدة إلا بموافقة الأغلبية. تشغيل نسختين فقط لا يوفر أي حماية حقيقية.

هيكل Redis Sentinel عبر ثلاث مناطق توافر: ثلاثة Sentinels يراقبون الأساسية ونسختين احتياطيتين؛ يحلّ التطبيق عنوان الأساسية الحالية عبر أي Sentinel قبل الاتصال.

يبدو ملف إعداد Sentinel المبسّط (/etc/redis/sentinel.conf) على النحو التالي:

# /etc/redis/sentinel.conf  — نفس الملف على جميع عقد Sentinel الثلاث
bind 0.0.0.0
port 26379

sentinel monitor mymaster 10.0.1.10 6379 2        # النصاب = 2
sentinel down-after-milliseconds mymaster 5000     # 5 ثوانٍ للإعلان عن التعطل الظرفي
sentinel failover-timeout mymaster 60000           # 60 ثانية ميزانية تجاوز العطل الكاملة
sentinel parallel-syncs mymaster 1                 # نسخة احتياطية واحدة فقط تتزامن أثناء تجاوز العطل

sentinel auth-pass mymaster s3cr3tP@ss
requirepass s3cr3tR3nt1n3lP@ss                     # حماية Sentinel API نفسها

# خطّافات الإشعار
sentinel notification-script mymaster /opt/redis/notify.sh
sentinel client-reconfig-script mymaster /opt/redis/reconfig.sh

بعد تجاوز العطل، يُعيد Sentinel كتابة ملف إعداداته بعنوان الأساسية الجديدة ويبث +switch-master على قناة Pub/Sub الخاصة به. العملاء الذين يستخدمون نمط الاتصال المدرك لـ Sentinel (مثل redis-py أو JedisSentinelPool) يُعيدون الحل تلقائيًا. العملاء الذين يُثبّتون عنوان IP للأساسية ستتعطل اتصالاتهم — وهذا النمط هو أكثر أسباب الانقطاعات الإنتاجية شيوعًا مع Sentinel.

الدماغ المنقسم في Sentinel: إذا لم يتم تعيين min-replicas-to-write على الأساسية، يمكن للأساسية القديمة الاستمرار في قبول الكتابة خلال فترة الانتخاب، مما يتسبب في تباين البيانات. احرص دائمًا على تعيين min-replicas-to-write 1 وmin-replicas-max-lag 10 على الأساسية حتى ترفض الكتابة عند عزلها.

Redis Cluster

يُجزّئ Redis Cluster البيانات عبر ما يصل إلى 1,000 عقدة باستخدام 16,384 فتحة تجزئة. يرتبط كل مفتاح بفتحة عبر CRC16(key) % 16384. يمتلك كل جزء أساسي نطاقًا متواصلًا من الفتحات، وتمتلك كل أساسية نسخة احتياطية واحدة أو أكثر. يعالج الكلاستر نفسه أعطاله: يكتشف فشل العقد عبر البروتوكول الانتشاري (gossip)، ويُرقّي النسخ الاحتياطية تلقائيًا، ويُعيد الإعلان عن ملكية الفتحات دون تنسيق خارجي.

الحد الأدنى للكلاستر الإنتاجي القابل للتطبيق هو 6 عقد: 3 أساسية + 3 نسخ احتياطية، حيث توجد كل أساسية في منطقة توافر مختلفة عن نسختها الاحتياطية. فشل منطقة توافر واحدة لا يفقد أي أساسية.

Redis Cluster بثلاثة أجزاء وتوزيع النسخ الاحتياطية عبر مناطق التوافر: كل أساسية في منطقة مختلفة عن نسختها الاحتياطية لضمان عدم فقدان البيانات عند تعطل منطقة كاملة.

لإطلاق كلاستر من 6 عقد (العقد تعمل مسبقًا بتفعيل cluster-enabled yes):

# مقتطف redis.conf المطلوب على كل عقدة
cluster-enabled yes
cluster-config-file /var/lib/redis/nodes.conf
cluster-node-timeout 15000                  # بالميلي ثانية؛ الوقت قبل اعتبار العقدة معطّلة
cluster-require-full-coverage no            # الاستمرار في الخدمة عند فقدان جزء
cluster-replica-validity-factor 10          # يجب ألا يتأخر النسخ الاحتياطي أكثر من 10× مهلة النسخ
appendonly yes
appendfsync everysec

# إنشاء الكلاستر (Redis 7 وما بعده)
redis-cli --cluster create \
  10.0.1.10:6379 10.0.1.11:6379 10.0.1.12:6379 \
  10.0.2.10:6379 10.0.2.11:6379 10.0.2.12:6379 \
  --cluster-replicas 1 \
  -a <password>

# التحقق من توزيع الفتحات والحالة الصحية
redis-cli -c -h 10.0.1.10 -a <password> cluster info
redis-cli --cluster check 10.0.1.10:6379 -a <password>

سلوك تجاوز العطل بعمق

في كلا الهيكلين، يمر تجاوز العطل بنفس المراحل: التعطل الظرفي → التعطل الموضوعي → الانتخاب → الترقية → إعادة الإعلان عن الفتحات. المعاملات الأساسية التي تحدد وقت استعادة الخدمة (RTO):

cluster-node-timeout (Cluster) / down-after-milliseconds (Sentinel): المدة قبل اعتبار العقدة معطّلة. قيمة أقل تعني تجاوز عطل أسرع؛ لكن قيمة منخفضة جدًا تُسبّب إيجابيات كاذبة أثناء توقفات جمع القمامة (GC) أو اضطرابات الشبكة. النطاق المعتمد في الصناعة هو 5–15 ثانية.
تأخر النسخ الاحتياطي عند لحظة فشل الأساسية يحدد حجم البيانات المفقودة في النسخة المُرقَّاة. مع النسخ غير المتزامن الافتراضي، أي كتابة منذ آخر إزاحة مُؤكَّدة تُفقد. قيّس هذا عبر INFO replication ومقارنة master_repl_offset بـ slave_repl_offset.
في Redis Cluster، يتلقى العملاء إعادة توجيه MOVED (انتقال دائم للفتحة) أو ASKING (فتحة في منتصف الترحيل). العملاء المدركون للكلاستر مثل Lettuce وredis-py يتعاملون معها تلقائيًا؛ العملاء العامون لا يتعاملون معها.

تدريب تجاوز العطل الإنتاجي: نفّذ redis-cli DEBUG SLEEP 30 على الأساسية بينما تُراقب redis-cli -h <sentinel> -p 26379 SENTINEL masters في طرفية أخرى. قِس مدة تجاوز العطل الفعلية وتأكد من إعادة اتصال العملاء. جدوِل هذا التدريب كل ربع سنة — معرفة الهيكل تتلاشى مع الوقت.

Sentinel مقابل Cluster: اختيار النموذج الصحيح

البُعد	Sentinel	Cluster
حجم البيانات	تسع عقدة واحدة في الذاكرة	تجزئة أفقية
العمليات متعددة المفاتيح	جميع العمليات مدعومة	تحتاج علامات التجزئة `{}`
متطلبات العميل	عميل مدرك لـ Sentinel	عميل مدرك للكلاستر
تعقيد التشغيل	أقل	أعلى (إعادة التجزئة، ترحيل الفتحات)
إنتاجية الكتابة	سقف عقدة واحدة (~500 ألف عملية/ث)	يتوسع خطيًا مع الأجزاء

Redis HA المُدار: كل من ElastiCache (AWS) وCloud Memorystore (GCP) وAzure Cache for Redis تُغلّف Sentinel أو Cluster داخليًا. ما زلت بحاجة لفهم الآليات الأساسية لتهيئة أحجام العقد وعدد النسخ الاحتياطية وتعدد مناطق التوافر ونوافذ الصيانة بشكل صحيح — ولتفسير المقاييس المعروضة في CloudWatch أو Stackdriver.

على نطاق Google وMeta، تُشغّل الفرق عادةً Cluster بـ ≥ 9 أجزاء (3 لكل منطقة توافر) مع cluster-replicas 2 — نسختان احتياطيتان لكل جزء — بحيث لا يفقد فشل منطقة توافر أي أساسية ولا أي نسخة للقراءة. يُحدَّد عدد الأجزاء بناءً على ذروة إنتاجية الكتابة وحجم مجموعة العمل النشطة، لا إجمالي حجم البيانات: المفاتيح المُزالة بسياسة maxmemory-policy allkeys-lru تُفقد نهائيًا، لذا صمّم الكلاستر بحيث تسع الذاكرة مجموعة العمل الساخنة بهامش احتياطي 30%.