نظرية CAP

نظرية CAP

في عام 2000، اقترح إريك برور ما أصبح يُعرف بنظرية CAP: لا يستطيع أي مخزن بيانات موزَّع توفير أكثر من اثنتين من الضمانات الثلاث التالية في آنٍ واحد — الاتساق والتوافر وتحمّل التجزئة. بعد عامين، أثبت غيلبرت ولينش ذلك رياضياً. فهم نظرية CAP لا يعني مجرد اختيار تذييل في قائمة؛ بل يعني التفكير بوضوح في سلوك نظامك عند حدوث الأعطال.

الضمانات الثلاث

• الاتساق (C): كل عملية قراءة تُعيد أحدث عملية كتابة — أو تُعيد خطأ. تَرى جميع العقد البيانات ذاتها في الوقت ذاته. هذا ما يُعرف بـ"وهم النظام الواحد": تتصرف مجموعة الأجهزة كأنها جهاز واحد متزامن تماماً.
• التوافر (A): كل طلب يحصل على استجابة (وليس خطأ)، وإن كانت البيانات المُعادة ليست بالضرورة الأحدث. يظل النظام يعمل حتى لو كانت بعض العقد معطّلة.
• تحمّل التجزئة (P): يستمر النظام في العمل رغم فقدان الرسائل أو تأخيرها بشكل تعسفي بين العقد. التجزئة الشبكية تعني أن بعض العقد لا تستطيع الوصول إلى عقد أخرى — تسقط الرسائل أو تتأخر إلى أجل غير مسمى.

لماذا تحمّل التجزئة أمر لا غنى عنه

تجزئات الشبكة حقيقة واقعة: تتعطل الأجهزة، وتسوء سلوكيات المحوّلات، وتُصاب روابط مراكز البيانات بالازدحام. في أي نظام موزع حقيقي، يجب عليك تحمّل التجزئات — التخلي عن P ممكن فقط في الأنظمة ذات العقدة الواحدة أو المتوثقة ارتباطاً شديداً حيث تتحكم في الشبكة كلها (وحتى هنا أنت تجعل احتمال التجزئة صغيراً جداً، لا صفراً). إذاً الخيار الحقيقي هو: عند حدوث التجزئة، هل تُضحّي بـ C أم بـ A؟

أنظمة CP — الاتساق على حساب التوافر

يرفض نظام CP الاستجابة (يُعيد خطأ أو مهلة زمنية) بدلاً من إعادة بيانات قد تكون قديمة. أثناء التجزئة، يُوقف الطرف الأقل عدداً عمليات الكتابة — أو جميع الكتابات — حتى يعود النصاب.

• HBase وApache ZooKeeper: يضمن بروتوكول انتخاب قائد ZooKeeper أن عقدة واحدة فقط تُجيب في كل لحظة. إذا لم تستطع العقدة التابعة الوصول إلى القائد، رفضت خدمة طلبات القراءة.
• MongoDB مع writeConcern: majority: يجب أن تُقرّ أغلبية أعضاء مجموعة النسخ المتماثلة بعملية الكتابة قبل تأكيدها. أثناء تجزئة تمنع الابتدائي من الوصول إلى عدد كافٍ من الثانويين، تتوقف الكتابات.
• Etcd: يستخدمه Kubernetes لتخزين الإعدادات؛ يُقدّم الاتساق على ما عداه — يجب أن يوافق نصاب قبل نجاح أي قراءة أو كتابة.

متى تختار CP: دفاتر الحسابات المالية، عدد المخزون، حجز المقاعد، أي مجال يكون فيه عرض بيانات قديمة أسوأ من عرض رسالة خطأ (مثل بيع تذاكر طيران زائدة).

أنظمة AP — التوافر على حساب الاتساق

يستمر نظام AP في الاستجابة لكل طلب حتى أثناء التجزئة، لكن عقداً مختلفة قد تُعيد قيماً مختلفة (قديمة). فور اندمال التجزئة، تتوافق العقد — وهذا أساس مفهوم الاتساق المُؤجَّل.

• Apache Cassandra: مع عامل نسخ 3 ومستوى اتساق ONE، تستطيع أي عقدة منفردة الإجابة. أثناء التجزئة، يخدم جانبا العنقود القراءات والكتابات باستقلالية، ثم يتزامنان حين تعود الاتصالية.
• Amazon DynamoDB (افتراضياً): القراءات ذات الاتساق المُؤجَّل هي الافتراضية؛ القراءات ذات الاتساق الشديد اختيارية وتكلف ضعف وحدات سعة القراءة.
• DNS: مثال كلاسيكي على AP — ينتشر تحديث DNS خلال دقائق إلى ساعات، لكن خوادم DNS تُجيب دوماً، وقد تحصل على IP قديم لفترة قصيرة.

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

زاوية CA — حالة خاصة

تذكر الكتب المدرسية أنظمة CA (متسقة + متاحة، بلا تحمّل للتجزئة) وتضرب قواعد البيانات العلائقية التقليدية مثالاً. هذا صحيح في إعداد العقدة الواحدة — نسخة PostgreSQL مستقلة متسقة ومتاحة في آنٍ معاً لأنه لا توجد تجزئة. لكن بمجرد إدخال النسخ المتماثل (نسخ القراءة، الاستعداد متعدد المناطق)، تُصبح التجزئات ممكنة. القول بأن نظاماً موزعاً هو "CA" غالباً ما يكون تمنياً. من الناحية العملية، اختر بين CP وAP.

ما وراء الثنائية — نموذج PACELC

نظرية CAP تتحدث فقط عن سلوك وقت التجزئة. في عام 2012، وسّع دانييل أبادي النموذج بـPACELC: "إذا وُجدت تجزئة (Partition)، اختر بين التوافر (Availability) والاتساق (Consistency)؛ وإلا (Else) في التشغيل الاعتيادي، اختر بين زمن الاستجابة (Latency) والاتساق (Consistency)." حتى بدون تجزئة، يتطلب الاتساق الشديد تنسيقاً بين العقد مما يُضيف زمن استجابة. تُقدّم Cassandra (AP/EL) قابلية الضبط لخفض زمن الاستجابة على حساب الاتساق. تتيح جداول DynamoDB العالمية الضبط لكل جدول على حدة. لهذا كشفت كثير من الأنظمة الحديثة عن مستويات اتساق قابلة للضبط بدلاً من خيار ثابت.