تئوری CAP چیست؟ مقایسه در دسترس بودن در مقابل ثبات

تئوری CAP باوری از علم کامپیوتر در مورد ذخیره‌سازی داده‌های توزیع‌شده است که ادعا می‌کند در صورت خرابی شبکه در database های توزیع‌شده (distributed)، می‌توان یکپارچگی یا در دسترس بودن را ارائه داد، در صورتی که داشتن هر دو مورد به طور همزمان امکان پذیر نیست.

همه چیز درباره تئوری سی‌ای‌پی (CAP theorem)

در سیستم‌های توزیع شده کامپیوتر، شما فقط می‌توانید دو مورد از تضمین‌های زیر را پشتیبانی کنید:

• ثبات (Consistency):  هر درخواست خواندن (read) آخرین نسخه نوشته شده را دریافت می‌کند یا اینکه آن را به صورت خطا در نظر می‌گیرد.
• دسترسی (Availability): هر درخواست یک جواب می‌گیرد، بدون ضمانت اینکه آخرین نسخه اطلاعات دریافت شود.
• تحمل تقسیم شدن (Partition Tolerance): در حالت توزیع شده سیستم حتی با وجود مشکل در شبکه‌ به کار خود ادامه بدهد.

با توجه به اینکه شبکه‌ها قابل اعتماد نیستند، بنابراین شما باید از تب‌آوری تقسیم شدن پشتیبانی کنید و از طرف دیگر باید بین سازگاری (Consistency) و در دسترس بودن نرم‌افزار (Availability) هماهنگی ایجاد کنید.

CP- سازگاری و تحمل پارتیشن

انتظار برای پاسخ از گره پارتیشن‌بندی شده ممکن است منجر به خطای زمانی شود. اگر کسب‌و‌کار شما نیازمند خواندن و نوشتن اتمی (atomic read and write) با سرعت بالا دارد CP گزینه خوبی است.

AP – در دسترس بودن و تحمل پارتیشن

پاسخ‌ها (response) جدیدترین نسخه از داده‌های موجود در یک گره را برمی‌گرداند اما این داده‌ها ممکن است آخرین نسخه نباشد. وقتی مشکل تقسیم شدن حل شد، فاصله نوشتن تا انتشار ممکن است کمی زمانبر باشد. در این صورت AP انتخاب خوبی است. اگر نیازهای کسب‌و‌کار اجازه ثبات نهایی سیستم را فراهم کند یا زمانی که سیستم باید همراه با خطاهای خارجی به کار خود ادامه دهد، استفاده از این روش مناسب است.

الگوهای سازگاری (Consistency patterns)

با کپی‌های متعدد از یک داده ما با گزینه‌هایی در مورد نحوه همگام‌سازی آن‌ها روبرو هستیم تا مشتریان دید ثابتی از داده‌ها داشته باشند. تعریف سازگاری را از قضیه CAP به یاد بیاورید- هر دستور read که دریافت می‌کند، آخرین دستور write یا Error را پردازش می‌کند

سازگاری ضعیف

بعد از نوشتن دیتا، read ممکن است پیام نوشته شده را ببیند یا اینکه آن را نادیده بگیرد. این رویکرد در سیستم‌هایی مانند memcached دیده می‌شود. سازگاری ضعیف در موارد استفاده بلادرنگ مانند VoIP، video chat و بازی‌های کامپیوتری چند نفره به خوبی کار می‌کند. به عنوان مثال: اگر در حال مکالمه تلفنی هستید و connection را برای چند ثانیه از دست می‌دهید، زمانی که دوباره متصل می‌شودی یا زمانی که اتصال قطع بوده و شما چیزی نمی‌شنیدید.

سازگاری مشروط

پس از نوشتن دیتا در نهایت read پیام را می‌بیند (معمولا در عرض چند میلی‌ثانیه). داده‌ها به صورت ناهمگام (asynchronous) تکرار می‌شوند. این رویکرد در سیستم‌هایی مانند DNS و ایمیل دیده می‌شود. سازگاری نهایی در سیستم‌هایی با دسترسی بالا به خوبی کار می‌کند.

سازگاری قوی

پس از نوشتن دیتا، read پیام دیتای نوشته شده را خواهد دید. داده‌ها به صورت همزمان (synchronous) تکثیر می‌شوند. این رویکرد در File System و RDBMS ها دیده می‌شود. سازگاری قوی در سیستم‌هایی که نیاز به تراکنش بالا دارند به خوبی کار می‌کند.

الگوهای در دسترس بودن (Availability patterns)

دو الگوی اصلی برای پشتیبانی از دسترسی بالا وجود دارد:

• FailOver 
• Replication

FailOver فعال – منفعل (Active-passive)

با این روش سیگنالی بین سرور فعال و سیستم غیرفعال ارسال می‌شود. اگر سیگنال قطع شود سرور passive یا غیرفعال آدرس IP سرور active را می‌گیرد و پاسخگویی را از سر می‌گیرد. مدت زمان از کار افتادن بر اساس این که آیا سرور passive از قبل در حالت آماده گرم «hot standby» کار می‌کند یا این که باید از حالت آماده سرد «cold standby» راه اندازی شود تعیین می‌شود.در این روش فقط سرور فعال ترافیک را مدیریت می‌کند.

FailOver فعال-فعال (Active-Active)

در این حالت هر دو سرور ترافیک را مدیریت می‌کنند و بار بین آن‌ها پخش می‌شود. همچنین اگر سرورها به صورت public و عمومی باشند، DNS باید در مورد IP های عمومی هر دو سرور اطلاع داشت باشد. اگر سرورها به صورت داخلی و internal باشند، منطق برنامه باید در مورد هر دو سرور اطلاع داشته باشد.

معایب FilOver

• Fail-over سخت‌افزار بیشتر و پیچیدگی بیشتری اضافه می‌کند.
• اگر سیستم فعال (active system) قبل از این که داده‌های جدید بر روی سیستم غیرفعال تکرار (replicate) شود از کار بیافتد احتمال ازدست دادن دیتا وجود دارد.

جمع بندی

اگرچه ممکن است قضیه CAP تا حدودی قدیمی به نظر برسد اما در ارائه راهی برای طراحی بهتر معماری پایگاه داده ارزشمند است. این نه تنها مهندسان و معماران کامپیوتر را در فرآیند توسعه نرم افزار وادار می کند تا در مورد آنچه از فناوری‌هایی که استفاده می‌کنند کنجکاو باشند بلکه آنها را مجبور می‌کند به دقت در مورد الزامات یک پروژه فکر کنند. اهداف کسب‌و‌کار چیست؟ انتظارات کاربران چیست؟

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

منبع: dev.to