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

نویسنده: محمد حسین کرمی

3 دقیقه زمان مطالعه
1401/04/21
بدون دیدگاه

قضیه CAP

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

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

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

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

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

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

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

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

در این صورت AP انتخاب خوبی است اگر نیازهای کسب‌و‌کار اجازه ثبات نهایی را فراهم کند یا زمانی که سیستم باید همراه با خطاهای خارجی به کار خود ادامه دهد.

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

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

سازگاری ضعیف

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

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

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

سازگاری قوی

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

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

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

Fail-Over

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

با این روش سیگنالی بین سرور فعال و سیستم غیرفعال ارسال می‌شود. اگر سیگنال قطع شود، سرور  passive یا غیرفعال آدرس IP سرور active را می‌گیرد و پاسخگویی را از سر می‌گیرد.

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

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

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

معایب FilOver

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

جمع بندی:

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

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

منبع: CAP