نگاهی به قضیه CAP

قبل از پیاده سازی یک سیستم توزیع شده باید مشخص شود که چه مشخصه هایی برای سیستم اهمیت بیشتری دارد. برای مثال :

1. آیا صحت داده ها اهمیت بیشتری دارد یا پاسخ دهی به موقع؟
2. آیا در دسترس بودن سیستم اهمیت بیشتری دارد یا اجماع داده ها در تمام سیستم؟

یکی از قضیه‌های مطرح شده در حوزه سیستم‌های توزیع شده قضیه CAP است. این تئوری توسط Eric Brewer در اواخر دهه 1990 مطرح شد که تئوری Brewer نیز نامیده می‌شود.

در سیستم‌های توزیع شده، قضیه CAP بیانگر این است که تنها میتوان دو گزینه از سه گزینه Consistency و Availability و Partition tolerance را فراهم کرد و گزینه سوم به همراه دو گزینه انتخاب شده، قابلیت پیاده سازی ندارد .

این سه ویژگی، به‌صورت زیر تعریف می‌شود.

1. اجماع Consistency:

تمام گره‌ها باید داده‌های یکسان و قابل اطمینان داشته باشند. فرض کنید یک تراکنش دارای چند قسمت باشد، نتیجه نهایی زمانی بین تمام گره‌ها ثبت می‌شود که آن تراکنش به‌طور کامل انجام شده باشد اگر یک تراکنش به‌طور ناقص انجام شود طبق اصل CAP ما آن را ثبت نمی‌کنیم یا همه یا هیچ. اگر در بین اجرای تراکنش مشکلی پیش بیاید، کل تراکنش باید به عقب برگردد.. در اینجا ما اطمینان داریم که تمام گره‌های یک سیستم توزیع شده داده‌های یکسانی دارند.

2. دسترس پذیری Availability:

در هر لحظه برای هر درخواست باید پاسخی وجود داشته باشد. بر این اساس یک سیستم توزیع شده همیشه باید فعال باشد. صرف نظر ای اینکه یک یا چند گره از دسترس خارج شده باشند یا دچار مشکل باشند سیستم باید در دسترس و پاسخگو باشد و هر گره باید عملیات خواندن و نوشتن و پردازش را در زمان معقول پاسخ بدهد. یکی از راه‌های در دسترس بودن داده در سیستم‌های توزیع شده به‌کارگیری تکنیک replication است. یعنی یک کپی از داده در همه گره‌ها باشد. اگر یکی از گره‌ها خراب شد، داده‌ها از دیگر گره‌ها در دسترس باشد. اما این موضوع با Consistency مغایرت دارد. چون اگر نود خراب به سیستم برگردد داده ی به روز شده ندارد.

3. تحمل پارتیشن Partition Tolerance:

چنانچه یک‌گره دچار مشکل شود یا بخشی از شبکه دچار خطا شود همه سیستم نباید دچار مشکل بشود. سیستمی که دارای تحمل پارتیشن باشد باید به‌سرعت بعد از خرابی خودش را بازیابی کند.

در ابتدا گفتیم که تنها دو تا از این سه ویژگی را می‌توانیم به‌صورت همزمان داشته باشیم اما در محیط عملیاتی Partition Tolerance نمی‌تواند اختیاری باشد و باید به‌طور کامل حفظ شود بنابراین از نظر تئوری، ما می‌توانیم تنها CP یا AP را حفظ کنیم. بنابراین پایبندی به قضیه CAP همیشه به یک انتخاب بین ثبات بالا و در دسترس بودن بالا تبدیل شد. با توجه به مشکلات شبکه‌ای که در هر سیستم‌ای امکان بروز آن وجود دارد، توصیه متخصصین انتخاب قطعی Partition tolerance به‌عنوان یکی از فاکتورهای گزینش شده است. انتخاب گزینه بعدی از بین Consistency و Availability کاملاً به ماهیت نرم‌افزار و اولویت‌های آن بستگی دارد

انتخاب AP

اگر Availability را در کنار Partition tolerance انتخاب کنید این بدان معناست که تمام درخواست‌ها به موقع پاسخ داده می‌شوند و پاسخ‌ها تا اندازه‌ای شامل آخرین نسخه از اطلاعات هستند. از طرفی امکان نوشتن در لحظه اطلاعات در تمام گره‌ها وجود ندارد اما در پایان ثبت اطلاعات در سیستم به‌طور کامل انجام می‌شود.

انتخاب CP

گزینش Consistency و Partition tolerance یعنی تمام درخواست‌های که به هر گره ارسال می‌شود به‌طور حتم باید دارای آخرین نسخه از اطلاعات باشند. این بدان معنی است که اگر درخواست مشابه به دو گره از سیستم ارسال بشود هر دو پاسخ یکسان و کامل را برمیگردانند. مشکل افزایش Consistency این است که Latency ثبت و دریافت داده‌ها افزایش خواهد یافت. و سرعت پاسخ دهی سیستم کاهش میابد.

انتخاب AP یا CP کاملاً به ماهیت نرم‌افزار بستگی دارد.

منابع:

https://medium.com/cstech/the-cap-theorem-8b1b94b1586c

https://en.wikipedia.org/wiki/CAP_theorem

https://edisciplinas.usp.br/pluginfile.php/2541318/mod_resource/content/1/TeoremaDeBrewer.pdf

https://ai.bigdataworld.ir/lessons/%D8%AF%D8%B1%D8%B3-%D8%AF%D9%88%D9%85-%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%D9%86%D8%B8%D8%B1%DB%8C%D9%87-cap-theorem/

https://chistio.ir/%D8%AA%D8%A6%D9%88%D8%B1%DB%8C-cap-%D8%AF%D8%B1-%D8%B3%DB%8C%D8%B3%D8%AA%D9%85-%D8%AA%D9%88%D8%B2%DB%8C%D8%B9-%D8%B4%D8%AF%D9%87/

https://www.educative.io/blog/what-is-cap-theorem