21 سبتمبر 2025·8 دقيقة
تفكير إريك بروير في CAP: لماذا تضطر الأنظمة الموزعة للمقايضات
تعرّف على مبدأ CAP لإريك بروير كنموذج ذهني عملي: كيف يشكل الاتساق والتوفر والانقسامات قرارات تصميم الأنظمة الموزعة.
تعرّف على مبدأ CAP لإريك بروير كنموذج ذهني عملي: كيف يشكل الاتساق والتوفر والانقسامات قرارات تصميم الأنظمة الموزعة.
عندما تخزن نفس البيانات على أكثر من آلة، تكسب سرعة وتحملًا للأخطاء—لكنك تكتسب أيضًا مشكلة جديدة: الخلاف. قد تتلقى خدمتان تحديثات مختلفة، قد تتأخر الرسائل أو لا تصل أبدًا، وقد يقرأ المستخدمون إجابات مختلفة اعتمادًا على النسخة التي يخدمهم. أصبح CAP شائعًا لأنه يعطي المهندسين وسيلة واضحة للحديث عن هذه الواقع الفوضوي بدون تبريرات سطحية.
أدخل إريك بروير، عالم الحاسوب ومؤسس مشارك لشركة Inktomi، الفكرة الأساسية عام 2000 كبيان عملي حول الأنظمة المكررة تحت الفشل. انتشرت بسرعة لأنها كانت تطابق ما كانت الفرق تواجهه في الإنتاج: الأنظمة الموزعة لا تفشل فقط عبر التوقف؛ بل تفشل عبر الانقسام.
CAP يصبح أكثر فائدة عندما تسوء الأمور—خاصة عندما لا يتصرف الشبك كما ينبغي. في يوم صحي، قد تبدو العديد من الأنظمة متسقة ومتاحة بما يكفي. اختبار الضغط هو عندما لا تستطيع الآلات التواصل بشكل موثوق ويتوجب عليك أن تقرر ماذا تفعل بالقراءات والكتابات بينما النظام منقسم.
هذا التأطير هو سبب التحول إلى نموذج ذهني شائع: لا يتعارض CAP حول أفضل الممارسات؛ بل يفرض سؤالًا ملموسًا—ما الذي سنضحّي به أثناء الانقسام؟
بنهاية هذا المقال، يجب أن تكون قادرًا على:
يدوم CAP لأنه يحول كلام "التوزيع صعب" غير المحدد إلى قرار يمكنك اتخاذه والدفاع عنه.
نظام موزع هو، ببساطة، عدة حواسب تحاول أن تتصرف كواحد. قد يكون لديك عدة خوادم في رفوف مختلفة أو مناطق أو سحابات، لكن للمستخدم هو "التطبيق" أو "قاعدة البيانات".
لكي يعمل ذلك النظام المشترك على مقياس العالم الحقيقي، نُجري غالبًا تكرارًا: نحتفظ بنسخ متعددة من نفس البيانات على آلات مختلفة.
النسخ المتماثل شائع لأسباب عملية ثلاثة:
حتى الآن، يبدو التكرار مكسبًا واضحًا. المشكلة أن التكرار يخلق مهمة جديدة: إبقاء كل النسخ متفقة.
لو استطاعت كل نسخة دائمًا أن تتحدث مع كل نسخة أخرى فورًا، لكان بالإمكان تنسيق التحديثات والبقاء متوافقين. لكن الشبكات الحقيقية ليست مثالية. قد تتأخر الرسائل، تُفقد، أو تُعاد توجيهها حول أعطال.
حين يكون الاتصال سليمًا، عادة ما تتبادل النسخ التحديثات وتتقارب على نفس الحالة. لكن عندما ينكسر الاتصال (ولو مؤقتًا)، قد ينتهي بك الأمر إلى نسختين تبدوان صحيحتين من “الحقيقة”.
مثال: يغير مستخدم عنوان الشحن. تستقبل النسخة A التحديث، ولا تستقبله النسخة B. الآن يتوجب على النظام الإجابة على سؤال بسيط: ما هو العنوان الحالي؟
هذا الفرق بين:
تفكير CAP يبدأ هنا بالضبط: بمجرد وجود التكرار، الخلاف تحت فشل الاتصال ليس حالة حافة—إنه المشكلة التصميمية المركزية.
CAP هو نموذج ذهني لما يشعر به المستخدمون فعليًا عندما يمتد النظام عبر آلات متعددة (غالبًا في أماكن مختلفة). لا يصف CAP أنظمة "جيدة" أو "سيئة"—بل التوتر الذي يجب عليك إدارته.
الاتساق يتعلق بالاتفاق. إذا قمت بتحديث شيء، هل ستعكس القراءة التالية (من أي مكان) ذلك التحديث؟
من منظور المستخدم، الفرق بين "لقد غيرته والكل يرى القيمة الجديدة" و"بعض الناس لا يزالون يرون القيمة القديمة للحظة".
التوفر يعني أن النظام يستجيب للطلبات—قراءات وكتابات—بنتيجة ناجحة. ليس "الأسرع الممكن"، بل "لا يرفض خدمتك".
أثناء المشكلات (خادم متوقف، خلل في الشبكة)، يستمر النظام المتاح في قبول الطلبات، حتى لو اضطر للإجابة ببيانات قديمة قليلًا.
الانقسام هو عندما تنقسم الشبكة: الآلات تعمل، لكن الرسائل بين بعضها لا تصل أو تتأخر جدًا لتكون مفيدة. في الأنظمة الموزعة، لا يمكنك التعامل مع هذا كأمر مستحيل—يجب أن تعرف كيف يتصرف النظام عند حدوثه.
تخيل متجرين يبيعان نفس المنتج ويشتركان في "عداد مخزون واحد". يشتري زبون آخر آخر قطعة في المتجر A، فيكتب المتجر A المخزون = 0. في نفس الوقت، يمنع انقسام الشبكة المتجر B من سماع ذلك.
إذا حافظ المتجر B على التوفر، فقد يبيع قطعة لم يعد يملكها (قبول البيع أثناء الانقسام). إذا فرض المتجر B الاتساق، فقد يرفض البيع حتى يتأكد من أحدث المخزون (رفض الخدمة أثناء الانقسام).
الـ"انقسام" ليس مجرد "الإنترنت معطل". إنه أي حالة حيث أجزاء من نظامك لا تستطيع التحدث مع بعضها بشكل موثوق—ورغم ذلك، قد يستمر كل جزء في العمل جيدًا.
في نظام مكرر، تتبادل العقد باستمرار رسائل: كتابات، إقراريات، نبضات حياة، انتخابات قائد، طلبات قراءة. الانقسام يحدث عندما تتوقف تلك الرسائل عن الوصول (أو تصل متأخرة جدًا)، ما يخلق خلافًا حول الواقع: "هل تمت الكتابة؟" "من القائد؟" "هل العقدة B على قيد الحياة؟"
قد يفشل الاتصال بطرق فوضوية وجزئية:
النقطة المهمة: الانقسامات غالبًا ما تكون تدهورًا، لا انقطاعًا نظيفًا. من منظور التطبيق، "بطيء بما يكفي" قد لا يختلف عن "معطل".
كلما أضفت آلات أكثر، شبكات أكثر، مناطق أكثر، ومكونات متحركة أكثر، زادت فرص انقطاع الاتصال مؤقتًا. حتى لو كانت المكونات الفردية موثوقة، النظام ككل يختبر فشلاً لأنه يملك اعتمادات أكثر وتنسيقًا بين عقد أكثر.
لا تحتاج إلى افتراض معدل فشل محدد لتقبل الواقع: إذا عمل نظامك طويلاً وامتد عبر بنية تحتية كافية، ستحدث الانقسامات.
تحمّل الانقسامات يعني أن نظامك مصمم ليستمر في العمل أثناء الانقسام—حتى عندما لا تستطيع العقد الاتفاق أو تأكيد ما رآه الجانب الآخر. هذا يفرض اختيارًا: إما الاستمرار في تقديم الطلبات (مع مخاطرة عدم الاتساق) أو التوقف/رفض بعض الطلبات (لحفظ الاتساق).
بمجرد أن يكون لديك تكرار، الانقسام هو ببساطة كسر في الاتصال: جزآن من نظامك لا يستطيعا التحدث لبعضهما بشكل موثوق لمدة ما. النسخ لا تزال تعمل، المستخدمون لا يزالون يضغطون أزرارًا، والخدمة لا تزال تستقبل طلبات—لكن النسخ لا تستطيع الاتفاق على أحدث الحقيقة.
هذا هو توتر CAP في جملة واحدة: أثناء الانقسام، يجب عليك اختيار تفضيل الاتساق (C) أو التوفر (A). لا يمكنك الحصول على كلاهما في نفس الوقت.
أنت تقول: "أفضل أن أكون صحيحًا على أن أكون سريعًا." عندما لا يستطيع النظام التأكد أن الطلب سيبقي جميع النسخ متزامنة، يجب أن يفشل أو ينتظر.
التأثير العملي: بعض المستخدمين سيرون أخطاء، مهلات، أو رسائل "حاول مرة أخرى"—خصوصًا للعمليات التي تغير البيانات. هذا شائع حين تفضل رفض دفع مرتين بدلًا من مخاطرة الشحن المزدوج، أو حجز مقعد بدلًا من الإفراط في البيع.
أنت تقول: "أفضل أن أستجيب بدل أن أحجب." سيستمر كل جانب من الانقسام في قبول الطلبات، حتى لو لم يستطع التنسيق.
التأثير العملي: يحصل المستخدمون على استجابات ناجحة، لكن البيانات التي يقرأونها قد تكون قديمة، وقد تحدث تعارضات في التحديثات المتزامنة. تعتمد بعدها على المصالحة لاحقًا (قواعد دمج، آخر كتابة تفوز، مراجعة يدوية، إلخ).
ليس هذا دائمًا إعدادًا عالميًا واحدًا. تمزج العديد من المنتجات استراتيجيات:
اللحظة الحرجة هي اتخاذ قرار—لكل عملية—ما الأسوأ: حجب المستخدم الآن، أم تصحيح الحقيقة المتعارضة لاحقًا.
شعار "اختر اثنين" لافت للانتباه، لكنه يضلل الناس بالاعتقاد أن CAP قائمة ميزات يمكنك الاحتفاظ باثنتين منها للأبد. CAP يتعلق بما يحدث عندما يرفض الشبك التعاون: أثناء الانقسام (أو أي شيء يبدو كهذا)، يجب على النظام الموزع الاختيار بين إعطاء إجابات متسقة والبقاء متاحًا لكل طلب. لا يمكنك كليهما في كل الحالات.
في أنظمة العالم الحقيقي، الانقسامات ليست إعدادًا يمكنك تعطيله. إذا امتد نظامك عبر آلات، رفوف، مناطق أو داتا سنترز، فبإمكان الرسائل أن تُؤخر، تفقد، تعاد ترتيبها، أو تُوجَّه بشكل غريب. هذا هو الانقسام من منظور البرنامج: العقد لا تستطيع الاتفاق بشكل كافٍ على ما يحدث.
حتى لو كانت الشبكة الفيزيائية بخير، أعطال أخرى تخلق نفس الأثر—عقد مثقلة، توقفات جمع النفايات (GC)، جيران مزعجون، مشاكل DNS، موازنات حمل متقلبة. النتيجة نفسها: بعض أجزاء النظام لا تستطيع التحدث إلى بعضها بمقدار كافٍ للتنسيق.
التطبيقات لا ترى "انقسام" كحدث ثنائي ومرتب. ترى قفزات في الكمون وانتهاء مهلات. إذا انتهت مهلة الطلب بعد 200 ملّيغ ثانية، فلا يهم إن وصلت الحزمة بعد 201 ملّيغ ثانية أو لم تصل على الإطلاق: التطبيق يجب أن يقرر التالي. من منظور التطبيق، الاتصال البطيء غالبًا لا يختلف عن المعطل.
العديد من الأنظمة الحقيقية تكون في الغالب متسقة أو في الغالب متاحة، اعتمادًا على الإعداد وظروف التشغيل. مهلات، سياسات إعادة المحاولة، أحجام النصاب، وخيارات "اقرأ كتاباتك" يمكن أن تغير السلوك.
في الظروف العادية، قد تبدو قاعدة بيانات قوية الاتساق؛ في ظل الضغط أو مشاكل عبر المناطق، قد تبدأ في رفض الطلبات (تفضيل الاتساق) أو إعادة بيانات قديمة (تفضيل التوفر).
CAP أقل عن تسمية المنتجات وأكثر عن فهم المقايضة التي تقوم بها عندما يحدث الخلاف—خاصة إن كان السبب بطء عادي.
نقاشات CAP غالبًا ما تجعل الاتساق يبدو ثنائيًا: إما "مثالي" أو "كل شيء مسموح". الأنظمة الحقيقية تقدم قائمة من الضمانات، كل منها يمنح تجربة مستخدم مختلفة عندما تختلف النسخ أو ينكسر رابط الشبكة.
الاتساق القوي (غالبًا "قابل للخطية") يعني أن الكتابة المُؤكدة تُقرأ لاحقًا من أي نسخة.
ما يكلفه: أثناء انقسام أو إذا كانت أقلية من النسخ غير متاحة، قد يؤخر أو يرفض النظام القراءات/الكتابات لتجنب إظهار حالات متضاربة. يلاحظ المستخدمون هذا كمهلات، "حاول مرة أخرى"، أو سلوك للقراءة فقط مؤقتًا.
الاتساق النهائي يعد بأنه إذا توقفت التحديثات، ستتقارب النسخ جميعها. لا يعد بأن مستخدمين اثنين يقرءان الآن سيرون نفس الشيء.
ما قد يلاحظه المستخدمون: صورة الملف الشخصي التي تم تحديثها مؤخرًا قد "تعود"، العدّادات تتأخر، أو رسالة مرسلة لا تظهر على جهاز آخر لجزء من الزمن.
يمكنك غالبًا الحصول على تجربة أفضل دون طلب الاتساق القوي الكامل:
تتوافق هذه الضمانات مع طريقة تفكير الناس ("لا تُظهر لي تغييري وكأنه اختفى") وقد تكون أسهل للحفاظ أثناء فشل جزئي.
ابدأ بوعود المستخدم، لا بالمصطلحات:
الاتساق قرار منتجي: حدّد ما الذي يُعتبر "خاطئًا" للمستخدم، ثم اختر أضعف ضمان يمنع ذلك.
التوفر في CAP ليس مقياس تفاخر ("خمس نُهُر")—إنه وعد تقدمه للمستخدمين حول ما يحدث عندما لا يستطيع النظام التأكد.
عندما لا تستطيع النسخ الاتفاق، تختار غالبًا بين:
يشعر المستخدمون بهذا على شكل "التطبيق يعمل" مقابل "التطبيق صحيح". لا أحدهما أفضل عالميًا؛ الخيار يعتمد على معنى "الخطأ" في منتجك.
سلوكان شائعان يظهران أثناء عدم اليقين:
هذا ليس قرارًا فنيًا بحتًا؛ بل سياسة يجب أن يحددها المنتج حول ما الذي يُقبل وما الذي لا يجوز التخمين به.
التوفر نادرًا ما يكون كل شيء أو لا شيء. أثناء الانقسام، قد ترى توفرًا جزئيًا: بعض المناطق أو المجموعات تنجح بينما تفشل أخرى. يمكن أن يكون ذلك تصميمًا متعمدًا (الخدمة المحلية تحافظ على العمل) أو نتيجةً لحالة عرضية (توازن توجيه، اختلافات في الوصول إلى النصاب).
حل وسط عملي هو وضع التدهور: استمر في تقديم إجراءات آمنة مع تقييد الخطرة. على سبيل المثال، اسمح بالتصفح والبحث، لكن عطّل مؤقتًا "نقل أموال"، "تغيير كلمة المرور" أو عمليات حيث تكون الصحة والخصوصية حرجة.
CAP يبدو مجردًا حتى تربطه بما يختبره المستخدم أثناء انقسام الشبكة: هل تفضّل أن يستمر النظام في الرد، أم أن يتوقف لتجنّب إرجاع/قبول بيانات متضاربة؟
تخيّل مركزين يقبلان الطلبات دون أن يتواصلا.
إذا أبقيت تجربة الدفع متاحة، قد يبيع كل طرف "آخر قطعة" وتُفرَط في البيع. هذا مقبول للسلع منخفضة الأهمية (تعوّض أو تعتذر)، لكن مؤلم لإصدار محدود.
إذا اخترت الاتساق أولًا، قد تحجب الطلبات الجديدة عندما لا يمكنك التأكد من المخزون عالميًا. يرى المستخدمون "حاول لاحقًا"، لكن تتجنب بيع شيء لا يمكنك الوفاء به.
المال هو المجال الكلاسيكي حيث الخطأ مكلف. إذا قبلت نسختان سحبا بشكل مستقل أثناء الانقسام، قد يصبح الحساب سالبًا.
غالبًا ما تفضل الأنظمة الاتساق أثناء الكتابات الحرَجية: رفض أو تأخير الإجراء إذا لم تستطع التأكد من الرصيد الأخير. ستتبادل بعض التوفر (فشل مؤقت للمدفوعات) مقابل الصحة والثقة وقابلية التدقيق.
في الدردشة وخلاصات وسائل التواصل، عادة ما يتسامح المستخدمون مع عدم الدقة الصغيرة: رسالة تصل بعد ثوانٍ، عدد الإعجابات غير دقيق، مقياس العرض يتأخر.
هنا، التصميم للتوفر غالبًا خيار جيد، طالما أنك واضح بشأن أي عناصر "تصحح لاحقًا" ولديك طرق لدمج التحديثات بسلاسة.
الخيار الصحيح يعتمد على تكلفة الخطأ: استردادات، مسؤولية قانونية، ثقة المستخدم، أو فوضى تشغيلية. قرّر أين يمكنك قبول الخلاف المؤقت—وأين يجب أن تفشل مغلقًا.
بمجرد أن تقرر ما ستفعل أثناء انقسام الشبكة، تحتاج آليات تجعل ذلك الاختيار واقعًا. تظهر هذه الأنماط عبر قواعد البيانات، أنظمة الرسائل، وواجهات برمجة التطبيقات—حتى لو لم يذكر المنتج "CAP".
النصاب ببساطة يعني "أغلبية النسخ توافق". إذا كانت لديك 5 نسخ من البيانات، الأغلبية هي 3.
بالمطالبة بأن تقرأ وتكتب إلى أغلبية، تقلل احتمال إرجاع بيانات قديمة أو متضاربة. على سبيل المثال، إذا وجب تأكيد كتابة من 3 نسخ، يصعب أن يقبل مجموعتان معزولتان حقائق مختلفة.
المقايضة هي السرعة والوصول: إذا لم تستطع الوصول لأغلبية (بسبب انقسام أو أعطال)، قد يرفض النظام العملية—مفضلًا الاتساق على التوفر.
العديد من قضايا "التوفر" ليست فشلًا صارمًا بل استجابات بطيئة. تحديد مهلة قصيرة يجعل النظام سريعًا للشعور، لكنه يزيد احتمال أن تعامل النجاحات البطيئة كفشل.
إعادة المحاولة قد تعيد الأمور من العثرة العابرة، لكن المحاولات العدوانية قد تثقل خدمةً بالفعل متأزمة. التراجع (الانتظار أطول بين المحاولات) والـjitter (عشوائية) يساعدان على منع تحوّل إعادة المحاولات إلى موجة أحمال.
المفتاح هو مواءمة الإعدادات مع وعدك: "دائمًا نستجيب" يعني عادة مزيدًا من المحاولات والبدائل؛ "لا نكذب أبدًا" يعني حدودًا أضيق وأخطاء واضحة.
إذا اخترت البقاء متاحًا أثناء الانقسامات، قد تقبل النسخ تحديثات مختلفة ويجب أن تُصالِح لاحقًا. النهج الشائعة تشمل:
إعادة المحاولة قد تخلق مكررات: خصم بطاقتين، أو تقديم نفس الطلب مرتين. تمنع عدم التكرار ذلك.
نمط شائع هو مفتاح عدم التكرار (idempotency key) يُرسل مع كل طلب. يخزن الخادم النتيجة الأولى ويعيدها للتكرارات—فبذلك تجعل المحاولات توفر التوفر دون تلف البيانات.
معظم الفرق "تختار" موقف CAP على اللوح—ثم تكتشف في الإنتاج أن النظام يتصرف بشكل مختلف تحت الضغط. التحقق يعني خلق الشروط التي تصبح فيها مفاضلات CAP مرئية، والتأكد أن النظام يتصرف كما صممت.
لا تحتاج لقطع كابل حقيقي لتتعلم. استخدم حقن الأعطال المتحكم فيه في البيئات التجريبية (وبحذر في الإنتاج) لمحاكاة الانقسامات:
الهدف هو الإجابة على أسئلة ملموسة: هل تُرفض الكتابات أم تُقبل؟ هل القراءات تخدم بيانات قديمة؟ هل يتعافى النظام تلقائيًا، وكم تستغرق المصالحة؟
إذا أردت التحقق مبكرًا (قبل استثمار أسابيع في ربط الخدمات)، قد يساعدك إنشاء نموذج مبدئي واقعي سريعًا. على سبيل المثال، تستخدم فرق كثيرة Koder.ai لبدء خدمة صغيرة (عادة Go backend مع PostgreSQL وواجهة React) ثم تكرار سلوكيات مثل المحاولات، مفاتيح عدم التكرار، وتدفقات "وضع التدهور" في بيئة رملية.
فحوصات الجاهزية التقليدية لن تلتقط "متاح لكن خاطئ". راقب:
يحتاج المشغلون لإجراءات معدة مسبقًا عند حدوث انقسام: متى تجمّد الكتابات، متى تفعل تبديل الخدمة، متى تخفض الميزات، وكيف تتحقق من أمان إعادة الاندماج.
خطط أيضًا لسلوك واجهة المستخدم. إذا اخترت الاتساق، قد تكون الرسالة "لا يمكننا تأكيد تحديثك الآن—الرجاء المحاولة لاحقًا." إذا اخترت التوفر، كن صريحًا: "قد يستغرق تحديثك بضع دقائق ليصل إلى كل مكان." صياغة واضحة تقلل عبء الدعم وتحافظ على الثقة.
عندما تتخذ قرارًا نظاميًا، يكون CAP الأكثر فائدة كاستفتاء سريع "ما الذي ينكسر أثناء الانقسام؟"—لا نقاش نظري. استخدم هذه القائمة قبل اختيار ميزة قاعدة بيانات، استراتيجية تخزين مؤقت، أو وضع تكرار.
اسأل هذه الأسئلة بالترتيب:
إذا حدث انقسام، فأنت تقرر أيًّا من هذه الحماية ستعطيه الأولوية.
تجنب إعدادًا عالميًا واحدًا مثل "نحن نظام AP". بدلاً من ذلك، قرر حسب:
مثال: أثناء الانقسام، قد تمنع الكتابات إلى payments (تفضل الاتساق) لكن تحتفظ بالقراءات لـproduct_catalog متاحة باستخدام بيانات مخبأة.
دوّن ما يمكنك تحمله، مع أمثلة:
إذا لم تستطع وصف اللااتساق بأمثلة بسيطة، ستجد صعوبة في اختباره وشرح الحوادث.
المواضيع التالية التي تتناغم مع هذه القائمة: إجماع (/blog/consensus-vs-cap)، نماذج الاتساق (/blog/consistency-models-explained)، وSLOs/ميزانية الأخطاء (/blog/sre-slos-error-budgets).
CAP هو نموذج ذهني لأنظمة النسخ المتماثل تحت فشل الاتصال. يكون مفيدًا عندما يكون الشبكة بطيئة أو متقلبة أو منقسمة؛ لأن ذلك يجعل النسخ المتماثل غير قادر على الاتفاق بشكل موثوق، ما يجبرك على الاختيار بين:
يساعد هذا النموذج على تحويل عبارة «التوزيع صعب» إلى قرار هندسي ومنتجي ملموس.
حالة CAP الحقيقية تتطلب كلا الأمرين:
إذا كان نظامك على عقدة واحدة أو لا يكرر الحالة، فمقايضات CAP ليست المحور المركزي.
الانقسام هو أي حالة لا تستطيع فيها أجزاء من النظام التواصل بشكل موثوق أو ضمن حدود زمنية مطلوبة—حتى لو كانت كل الآلات تعمل. عمليًا، «الانقسام» يظهر كـ:
من منظور التطبيق، «بطيء جدًا» غالبًا ما يكون مكافئًا لـ«معطل».
الاتساق (C) يعني أن القراءات تعكس آخر كتابة تمّ تأكيدها من أي مكان. يختبره المستخدم كـ"غيرت شيئًا والكل يراه".
التوفر (A) يعني أن كل طلب يحصل على استجابة ناجحة (ليس بالضرورة أحدث البيانات). يختبره المستخدم كـ"التطبيق يعمل" وربما يعرض بيانات قديمة.
أثناء الانقسام، عادة لا يمكنك ضمان كلا الضمانين لجميع العمليات في آنٍ واحد.
لأن الانقسامات ليست اختيارية في الأنظمة الموزعة التي تمتد عبر آلات، رفوف، مناطق أو داتا سنترز. إذا كنت تكرر الحالة، يجب أن تحدد سلوك النظام عندما لا تستطيع العقد التنسيق.
بالتالي "تحمّل الانقسامات" يعني عمليًا: عند انهيار الاتصال، يملك النظام سلوكًا محددًا—إما برفض/تأخير بعض العمليات (تفضيل الاتساق) أو بتقديم استجابات تقديرية (تفضيل التوفر).
إذا فضّلت الاتساق، فعادة ما تقوم بـ:
هذا شائع في المدفوعات، حجز المخزون، وتغييرات الأذونات—حيث أن الخطأ أسوأ من عدم التوفر المؤقت.
إذا فضّلت التوفر، فعادة ما تقوم بـ:
المستخدمون يرون أخطاء أقل قاطعة، لكن قد يرون بيانات قديمة أو تأثيرات مكررة إذا لم تُستخدم مفاتيح عدم التكرار.
يمكنك اختيار سلوك مختلف لكل نقطة نهاية/نوع بيانات. استراتيجيات شائعة:
هذا يمنع وسم النظام ككل بأنه AP أو CP فقط، وهو نادرًا ما يعكس احتياجات المنتج الحقيقية.
خيارات مفيدة تتضمن:
تحقق عن طريق خلق ظروف تجعل الخلاف مرئيًا:
وضع خطط تشغيل ورسائل للمستخدم تتوافق مع السلوك الذي اخترته (فشل مغلق مقابل فشل مفتوح).
اختر أضعف ضمان يمنع "الخطأ" الظاهر للمستخدم الذي لا يمكنك تحمله.