درک نظریه CAP: تعادل یکپارچگی، دسترس‌پذیری و تحمل اختلال شبکه

در دنیای سامانه‌های توزیع‌شده، جایی که داده‌ها باید روی چندین سرور یا گره ذخیره و بازیابی شوند، تضمین قابلیت اطمینان، عملکرد و یکپارچگی سیستم، چالش‌برانگیز است. برای پاسخ به این چالش‌ها، دانشمند علوم رایانه، اریک بروئر، نظریه‌ای به نام «قضیه‌ی CAP» را مطرح کرد که امروزه به یکی از مفاهیم بنیادین در طراحی و اجرای سامانه‌های توزیع‌شده تبدیل شده است. در این نوشته، قصد داریم به بررسی این نظریه بپردازیم: CAP چیست، چه پیامدهایی دارد و چگونه بر تصمیم‌های طراحی پایگاه‌داده‌های توزیع‌شده تأثیر می‌گذارد.

قضیه‌ی CAP چیست؟

قضیه‌ی CAP یا همان «قضیه‌ی بروئر» در سال ۲۰۰۰ توسط اریک بروئر معرفی شد. سه حرف CAP مخفف مفاهیم زیر هستند:

• C: یکنواختی یا Consistency
• A: در دسترس‌بودن یا Availability
• P: تحمل قطعی ارتباط یا Partition Tolerance

این نظریه به ما می‌گوید که در طراحی سامانه‌های توزیع‌شده، همواره نوعی بده‌بستان (trade-off) میان این سه ویژگی وجود دارد.

صورت‌بندی قضیه‌ی CAP

قضیه‌ی CAP بیان می‌کند که در یک سامانه‌ی توزیع‌شده که داده‌ها در آن کپی می‌شوند (replication)، نمی‌توان به‌طور هم‌زمان هر سه ویژگی یکنواختی، در دسترس‌بودن و تحمل قطعی ارتباط را تضمین کرد. در ادامه، هر یک از این سه مفهوم را به‌طور خلاصه توضیح می‌دهیم.

C: یکنواختی (Consistency)

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

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

A: در دسترس‌بودن (Availability)

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

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

P: تحمل قطعی ارتباط (Partition Tolerance)

تحمل قطعی ارتباط به توانایی سامانه در ادامه‌ی فعالیت حتی در صورت قطعی ارتباط بین بخش‌های مختلف اشاره دارد. در مواقعی که گره‌ها امکان برقراری ارتباط با یکدیگر را از دست می‌دهند، همگام‌سازی داده‌ها مختل می‌شود.

مثلاً اگر ارتباط بین d1 و d2 قطع شود، همگام‌سازی بین این دو انجام نمی‌شود و یکنواختی از بین می‌رود. اما اگر هر دو گره همچنان به ارائه‌ی پاسخ ادامه دهند، سامانه از نظر تحمل قطعی ارتباط مقاوم بوده است.

ترکیب‌های ممکن CAP

قضیه‌ی CAP می‌گوید که نمی‌توان هر سه ویژگی را هم‌زمان داشت. در بهترین حالت، تنها دو ویژگی از سه‌گانه‌ی C، A و P را می‌توان هم‌زمان تضمین کرد. بنابراین، سه ترکیب زیر ممکن است:

CA (یکنواختی + در دسترس‌بودن):
سامانه همواره در دسترس است و داده‌ها یکسان باقی می‌مانند. اما اگر قطعی شبکه رخ دهد، سامانه دیگر قادر به حفظ این وضعیت نخواهد بود.

AP (در دسترس‌بودن + تحمل قطعی ارتباط):
در صورت قطعی ارتباط، سامانه همچنان پاسخ می‌دهد (در دسترس می‌ماند)، اما به‌دلیل عدم همگام‌سازی، یکنواختی داده‌ها از بین می‌رود.

CP (یکنواختی + تحمل قطعی ارتباط):
برای حفظ یکنواختی در شرایط قطعی ارتباط، باید بخشی از سامانه موقتاً از دسترس خارج شود تا ارتباط بازیابی شود. بنابراین در این حالت، در دسترس‌بودن قربانی می‌شود.

این ترکیب‌ها نشان می‌دهند که هیچ‌گاه نمی‌توان هر سه ویژگی CAP را به‌طور هم‌زمان در یک سامانه‌ی توزیع‌شده حفظ کرد.

اهمیت قضیه‌ی CAP

اهمیت CAP در این است که طراحان سامانه‌های توزیع‌شده را مجبور می‌کند به‌طور دقیق درباره‌ی اولویت‌های خود تصمیم‌گیری کنند. بسته به کاربرد سامانه، ممکن است برخی ویژگی‌ها مهم‌تر از دیگران باشند.

مثلاً در یک سامانه‌ی بانکی، یکنواختی مهم‌ترین ویژگی است. نمی‌توان پذیرفت که مانده‌حساب‌ها در گره‌های مختلف متفاوت باشند. اما در یک اپلیکیشن شبکه‌ی اجتماعی، در دسترس‌بودن اولویت بیشتری دارد؛ چرا که کاربران انتظار دارند همیشه به سامانه دسترسی داشته باشند، حتی اگر داده‌ها کمی تأخیر داشته باشند.

نمونه‌های واقعی

برای درک بهتر، به دو نمونه‌ی واقعی توجه کنید:

• Amazon DynamoDB:
  این پایگاه‌داده برای تضمین در دسترس‌بودن و تحمل قطعی ارتباط طراحی شده است. داده‌ها در چند منطقه‌ی جغرافیایی تکرار می‌شوند. اما در صورت بروز اختلال شبکه، یکنواختی قوی به‌طور پیش‌فرض تضمین نمی‌شود.
• Google Spanner:
  این پایگاه‌داده مثالی از یک سامانه‌ی CP است. با استفاده از ساعت‌های هم‌زمان‌شده و معماری توزیع‌شده‌ی جهانی، یکنواختی قوی را تضمین می‌کند. اما در صورت بروز قطعی شبکه، ممکن است موقتاً از دسترس خارج شود.
• پلتفرم یکپارچه پیام‌رسانی و ارتباطات سازمانی «دارکوب»:
  پیام‌رسان سازمانی دارکوب نیز بر پایه معماری توزیع‌شده طراحی شده است و به از سادگی می‌توان آن را از یک سرور به سه، پنج، هفت و سرورهای پیشتر مقیاس داد.