Cap Theorem

 نبدأ الأول بتعريف الاختصارات ال C هي  اختصار  لكلمة Consistency وال a هي اختصار لكلمة  Availability وال p هى اختصار لكلمة Partition tolerance .

 عند بناء distributed system  يكون هدفنا هو زيادة كفاءة ال  system  بشكل عام ، وهنا يمكن طرح سؤال بديهي ، ما هى علاقة الـ distributed system بال cap theorem ؟

بعيداً عن الكلام النظري والتعريفات تعالى نشوف مع بعض ايه علاقة الـ  cap بال distributed system .

تخيل أن احنا عملنا مشروع بسيط وهو عبارة عن ATM Machine وعملنا برنامج  والبرنامج يتم عمل ليه تسطيب على الـ ATM machine .

المستخدم ببساطة ممكن يعمل التالي من خلال الـ ATM  

1-يسحب فلوس من حسابه

2-يودع فلوس فى حسابه

ال software يقوم بالعملية المطلوبة من قبل المستخدم ويتم تحديث البيانات الخاصة بال User  بالتالي كل المعلومات الخاصة بالمستخدم موجودة على مستوى الـ Atm Machine. 

تمام  عملنا Atm Machine  واحده  بال software  الخاصه بها و اصبحت موجوده مثلاً فى مكان عام , الإقبال زاد وفى مستخدمين كتير بيستخدموا ال atm machine .حلو الكلام دا ,بس فى نقطه مهمه لازم  تفكر فيها و تلاحظها بسهولة ، مع  زيادة عدد المستخدمين يزداد الضغط والزحام على الـ atm بالتالى الشخص ممكن ينتظر مدة طويلة عشان يعمل عملية سحب او ايداع بالتالى المستخدم هيضطر يستنى مدة طويلة.

وعدد العمليات التي تتم  فى اليوم هتقل أو هتفضل محصورة عند نسبة معينة ،لو انت لك نسبة معينة عن كل عملية  فنسبة أرباحك هتفضل محصورة في نقطة معينة ، لأن بالرغم أن عدد المستخدمين زاد فأنت غير قادر انك تستفيد من هذه الزيادة بل بالعكس التجربة للمستخدم بقت اسوأ لأنه  محتاج وقت طويل علشان يعمل عملية سحب أو إيداع واحدة.

ما هو  الحل لهذه  المشكلة؟

  فى الاول لم نكن نتوقع  أن عدد المستخدمين هيزيد , فكان ال  Hardware  الخاص بال  atm  بسيط، بمعنى أن  ال  Processor كان بإمكانيات متواضعة وهكذا ال  Ram  وبما  أن عملية الإيداع والسحب عملية معقدة جداً , بهزر طبعاً :) ، بس تخيل انها معقدة وتحتاج وقت عشان تتنفذ. ولنفترض أن المشكلة فعلاً بسبب أمكانيات ال Atm Machine فبالتالى لما نزود امكانياتها هيفرق معانا فى وقت التنفيذ وبالتالي العمليات هتتنفذ بشكل أسرع  فبالتالى  وقت الأنتظار يقل فالبتالي  عدد  العمليات التى يقوم بها المستخديمن هتزيد فالبالتالى احنا نكسب اكتر .

بس ثانيه هل دا حل مناسب ؟ هو حل مناسب  بس لحد امتى ؟ هل لو عدد المستخدمين فضل فى زياده مستمره هنفضل نزود  من إمكانيات الـ atm بس هل ال hardware  ليس له limit  ؟ 

بالتأكيد ال hardware ليه حدود وكل م الإمكانيات بقت اعلى هتتكلف فلوس اكتر واكتر وهكذا.

ما هو  الحل المناسب  فى حالة لو زيادة أمكانيات ال  hardware  ليها limit  معين وتكلفة غاليه وفى نفس الوقت لن تساهم  فى حل المشكلة  بشكل كبير .

الحل  ان يتم  صنع   Atm Machine  ثانيه حتى لو بامكانيات متوسطه  فبالتالى عدد المستخدمين هيتقسم  بين اكثر من  machine وبهذا الحل هنقدر  نوزع الشغل المطلوب بين اكتر من machine  فبالتالى قادرين نتعامل مع عدد مستخدمين اكثر حتى لو امكانيات ال machine  متواضعه  .

ما تم عمله  ببساطة نقدر نقول عليه  distributed system ، ال sytem  هدفه يساعد المستخدم أنه يعمل عملية ايداع وسحب، من أجل  حل  مشكلة زيادة عدد المستخدمين والضغط الكبير على الـ system  قررنا ندخل  machine جديده معانا فى الخدمه حتى لو لو كانت ال machines  إمكانياتها متواضعة.

بس فى نقطه مهمه ، الأن عندنا Atm1 و Atm 2 فالبتالي انا لو رصيدى 100 وعملت عملية سحب 50 بواسطة  A1 فرصيدى هيكون 50  فى At1، فأحنا عاوزين  الرصيد يبقى 50 كذلك فى At2 .

حاجه منطقيه جداً  أن البيانات الموجوده فى  A1 لازم تكون هى نفسها   فى A2 ، أى  لازم يحصل تزامن للبيانات بين at1 و at 2 .

الحل سهل  هنوصل  ال machines  ببعض عن طريق ال  network فالبالتى  لو فى  عمليه حصلت  فى  at1  هتبعت event  أو ممكن أشاره إلى at2 علشان at2 تحدث البيانات الخاصة بها .

حلو الكلام دا , احنا كان عندنا system  بسيط فزاد عدد المستخدمين فزودنا  أمكانيات ال hardware  والحل دا  نفع بشكل مؤقت معانا , فغيرنا  تفكيرنا وقررنا نصنع كمان machine  علشان نحل المشكله، بس كان لازم نعمل مزامنة البيانات بين ال machines  ولهذا  استخدمنا ال network .

بس للأسف زى أى حل بسيط بنستخدمه علشان نحل مشكله  معينه , فالحل البسيط ذات نفسه هيجيب ليا مشكله او مجموعه من المشاكل 😂

تخيل لو بلال عمل  عملية سحب بأستخدام at1  وفى نفس اللحظة كانت at2 حصل فيها عطل او مثلاً لسبب ما ال network حصل فيها مشكلة.

انت لو فضلت  تفكر وتعد الأسباب التى  تمنع أن يحصل تواصل بين ال  two machines  هتلاقىها لا تعد ولا تحصى , لذلك لو ال system كان  distributed فلازم المشكله دى    هتحصل .

ومن النقطه دى هنبدأ مع أخر حرف من ال CAP وهو ال P وP اختصاراً لكلمة Partion وهنا المقصود هل ال system  متقسم  او فى اكتر من machine بتعمل run لل system .

لو الاجابه أيوا فال system يعتبر distributed  فاكيد هيحصل مشكله تواصل بين ال  machines اياً كان السبب , هتحصل امتى وازاى وليه منعرفش نحددها ,المهم انها هتحصل .

أول حرف من  cap  وهو Consistency

وهنا المقصود لو رصيد محمود 100، هل لو محمود شاف رصيده فى at1 و at2 هيلاقيه 100 ولو ممكن يلاقى فى at1 الرصيد 60 وat2 الرصيد 100.

ال consistent بتقول ان لازم رصيد محمود يكون هو نفسه بين at1و at2  ومينفعش يختلف .

بالتالى فى ال  system الخاص بينا لو محمود قرر يعمل ايداع فى حسابه ب 50 بأستخدام at1 , ف at1 لن تقوم بأكمال العمليه  الأ لما تتاكد أن at2  استقبلت ال event منها .

ال a من  cap  وهو availability

لو ال  system  كان  distributed قالبتاكيد هنقدر نقول أنه بيحقق شرط ال P

ال availability معناها أنه من غير المقبول أن محمود  يعمل ايداع  فى at1 أو سحب والطلب بتاعه يترفض لأن  at2 فيها مشكله، لأن  ال   system  فى هذه الحاله بقى unavailable بالنسبه لل user  ،على الرغم أن مفيش مشكله فعلياً من وجهة نظر المستخدم .

ممكن  نحقق الشرط دا بأن احنا نسمح بأكمال   عملية السحب والإيداع الخاصة بمحمود , وأول لما تكون at1  عرفت تتواصل مع at2 فهتبعت ليها  كل العمليات التى  تمت بنجاح  حتى تقوم بعمل التخديثات اللازمه.

بس بهذه الطريقه  لم  نحقق ال  Consistency لأن البيانات بقت مختلفة بين at1 وat2  واختارنا أن ال  system  يكون  available  عوضاً أنه يكون   consistent .

بالتالى  نظرية  ال CAP المكونه من 3 حروف  بأختصار أن لو ال system  معمول ليه  partition فنستنج أنه هيحصل  ليه partition failure ، فانت  فلازم تختار بين أن ال  system  يكون   consistent  او يكون   available.