كيف يعمل الاستمرارية في Redis (RDB مقابل AOF)؟

Question

Accepted Answer

على الرغم من أن Redis موجود في الذاكرة، إلا أنه يمكنه **الاحتفاظ بالبيانات على القرص** بحيث تبقى البيانات موجودة بعد إعادة التشغيل. يوفر آليتين — **RDB** (لقطات في نقطة زمنية معينة) و **AOF** (سجل إضافي للعمليات) — مع مقايضات مختلفة بين المتانة والأداء.

## RDB — لقطات في نقطة زمنية معينة

```text
RDB takes SNAPSHOTS of the dataset at intervals, saving a compact binary file.
  ✓ Compact single-file backups; fast restarts (load the snapshot)
  ✓ Good for backups and disaster recovery; less impact on performance
  ✗ You can LOSE data since the last snapshot (e.g. last few minutes) if Redis crashes
→ Configure save points: e.g. "save after 900s if ≥1 change, 300s if ≥10 changes"
```

يحفظ RDB مجموعة البيانات بالكاملة بشكل دوري إلى ملف مضغوط — فعال وممتاز للنسخ الاحتياطية، لكن في حالة حدوث عطل يتم فقدان التغييرات التي تمت منذ آخر لقطة.

## AOF — سجل إضافي

```text
AOF logs EVERY write operation to a file; on restart, Redis replays the log to rebuild data.
  ✓ More DURABLE — less data loss (can fsync every second, or every write)
  ✓ The log can be rewritten/compacted to stay manageable
  ✗ Larger files; can be slower than RDB; restart (replay) can be slower
→ fsync policies: always (safest, slowest), everysec (good balance), no (fastest, riskiest)
```

يسجل AOF كل عملية كتابة، ويعيد تشغيلها لإعادة بناء البيانات عند إعادة التشغيل — أكثر متانة (فقدان بيانات أقل) لكن مع ملفات أكبر وأداء/إعادة تشغيل محتملة أبطأ.

## RDB مقابل AOF — المقايضة

```text
RDB → better performance, compact backups, faster restart, BUT more potential data loss
AOF → better durability (minimal data loss), BUT larger files, slower

BEST PRACTICE: use BOTH together → RDB for backups + AOF for durability
  → Redis can use both; AOF for recovery, RDB for snapshots/backups
OR: pure cache use → you may DISABLE persistence entirely (data is recreatable)
```

## لماذا يهم هذا

فهم استمرارية Redis مهم **لضمان متانة البيانات** بشكل مناسب عندما يحتفظ Redis ببيانات مهمة، لذا فهو معرفة قيمة لاستخدام Redis بشكل صحيح.

على الرغم من أن Redis في الأساس موجود في الذاكرة، فإن حقيقة أنه **يمكنه الاحتفاظ بالبيانات على القرص** (بحيث تبقى البيانات موجودة بعد إعادة التشغيل والأعطال) مهمة للفهم، إلى جانب الآليتين والمقايضات الخاصة بهما. **RDB** (لقطات في نقطة زمنية معينة) توفر نسخ احتياطية مضغوطة وإعادة تشغيل سريعة وتأثير أداء منخفض، لكنها تخاطر **بفقدان البيانات منذ آخر لقطة** في حالة حدوث عطل — جيدة للنسخ الاحتياطية ومقبولة عندما يكون فقدان بعض البيانات محتملاً. **AOF** (تسجيل كل عملية كتابة، معاد التشغيل عند إعادة التشغيل) توفر **متانة أفضل** (فقدان بيانات أقل، قابل للتكوين عبر سياسات fsync) لكن مع ملفات أكبر وأداء/إعادة تشغيل محتملة أبطأ.

فهم **المقايضة** (RDB للأداء والنسخ الاحتياطية المضغوطة مقابل AOF للمتانة) و**الممارسة الشائعة الأفضل باستخدام كليهما معاً** (RDB للقطات/النسخ الاحتياطية بالإضافة إلى AOF للمتانة) يعكس حكماً سليماً في التكوين.

من المهم أيضاً الاعتراف بأنه بالنسبة لاستخدام **الذاكرة المؤقتة البحتة** (حيث يمكن إعادة إنشاء البيانات من المصدر)، يمكن تعطيل الاستمرارية بالكامل — Redis لا يحتاج دائماً إلى المتانة.

اختيار تكوين الاستمرارية المناسب بناءً على حالة الاستخدام (احتياجات المتانة مقابل الأداء، أو لا شيء للذاكرة المؤقتة البحتة) هو المهارة العملية الرئيسية.

نظراً لأن متانة البيانات مهمة عندما يحتفظ Redis ببيانات مهمة (الجلسات والطوابير والبيانات الأساسية)، ونظراً لأن فهم RDB و AOF والمقايضات الخاصة بهما والممارسات الأفضل (كليهما معاً، أو لا شيء للذاكرة المؤقتة) ضروري لتكوين Redis بشكل مناسب، فإن فهم استمرارية Redis هو معرفة قيمة وعملية ذات صلة لاستخدام Redis بمسؤولية — ضمان المستوى الصحيح من المتانة للبيانات التي يحتفظ بها Redis، وهو موضوع يعكس فهماً لـ Redis يتجاوز الذاكرة المؤقتة البسيطة.