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

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

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

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

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

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

1. اجماع Consistency:

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

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

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

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

اگر بخشی از شبکه یا یک Node‌ با مشکل مواجه شود، کل سیستم نباید از کار بیفتد. سیستمی که Partition tolerance دارد، باید بتواند پس از خرابی، خود را به‌سرعت بازیابی کرده و به فعالیت ادامه دهد.

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

انتخاب AP

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

انتخاب CP

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

مثال‌هایی از انتخاب مدل CAP

• دیتابیس Apache Cassandra:
  این پایگاه داده توزیع‌شده بر مدل AP تأکید دارد. همیشه در دسترس است و حتی در شرایط پارتیشن‌بندی شبکه هم پاسخگو می‌ماند، اما ممکن است داده‌ها در لحظه به‌طور کامل همگام نباشند.
• دیتابیس MongoDB:
  این پایگاه داده، وابسته به تنظیمات انتخاب‌شده، می‌تواند سطحی از Consistency یا Availability را فراهم کند. معمولاً انعطاف‌پذیری خوبی در تعیین حد میانه بین AP و CP دارد.

انتخاب AP یا CP کاملاً به ماهیت نرم‌افزار بستگی دارد.
انتخاب بین AP یا CP کاملاً به نیازمندی‌ها، ماهیت نرم‌افزار، اولویت‌ها و محیط عملیاتی شما بستگی دارد. سیستم‌هایی که بر سرعت پاسخگویی، دسترس‌پذیری مداوم و مقیاس‌پذیری بالا تأکید دارند، غالباً به سمت مدل AP متمایل می‌شوند. در مقابل، سیستم‌هایی که حساسیت بالایی بر صحت و اجماع داده‌ها دارند (مانند سیستم‌های مالی و بانکی)، از مدل CP استفاده می‌کنند.

منابع:
The CAP Theorem on Medium
CAP Theorem on Wikipedia
Teorema de Brewer (PDF)
AI Bigdataworld - CAP Theorem
Chistio - تئوری CAP<br/>Educative - What is CAP Theorem