طراحی سیستم: قضیه اصلی CAP

قضیه CAP: یک مرور کلی

قضیه CAP، که به عنوان قضیه بروئر نیز شناخته می شود، یک اصل اساسی در سیستم های توزیع شده است که مبادلات بین سه ویژگی اصلی را توصیف می کند:

1. سازگاری (C)
2. در دسترس بودن (A)
3. تحمل پارتیشن (P)

ویژگی های اصلی

1. سازگاری (C):

   • هر خوانده شده از سیستم آخرین نوشته را برمی گرداند. این بدان معنی است که همه گره های سیستم داده های یکسانی را به طور همزمان می بینند.

2. در دسترس بودن (A):

   • هر درخواست (خواندن یا نوشتن) بدون توجه به موفقیت یا عدم موفقیت، پاسخی دریافت می کند. این تضمین می کند که سیستم عملیاتی و پاسخگو باشد.

3. تحمل پارتیشن (P):

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

چگونه کار می کند

قضیه CAP بیان می کند که در یک سیستم توزیع شده، دستیابی به هر سه ویژگی به طور همزمان غیرممکن است. شما فقط می توانید حداکثر دو مورد از سه ویژگی را در هر زمان معین داشته باشید:

• CA (ثبات + در دسترس بودن): این سیستم ها به خوبی پارتیشن ها را مدیریت نمی کنند. اگر یک پارتیشن شبکه رخ دهد، ممکن است سیستم برای اطمینان از ثبات در دسترس نباشد.

• CP (ثبات + تحمل پارتیشن): این سیستم ها می توانند پارتیشن ها را مدیریت کنند اما ممکن است در طول پارتیشن برای اطمینان از سازگاری در دسترس نباشند.

• AP (در دسترس بودن + تحمل پارتیشن): این سیستم ها حتی در طول پارتیشن ها نیز در دسترس هستند اما ممکن است سازگار نباشند.

اهمیت در طراحی سیستم

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

چرا به قضیه CAP نیاز داریم؟

قضیه CAP مهم است زیرا چارچوبی برای درک محدودیت ها و مبادلات سیستم های توزیع شده فراهم می کند. در سناریوهای دنیای واقعی، پارتیشن‌های شبکه اجتناب‌ناپذیر هستند و درک CAP به طراحی سیستم‌هایی کمک می‌کند که بتوانند چنین سناریوهایی را به خوبی مدیریت کنند.

مثال: سیستم های پایگاه داده توزیع شده

بیایید یک پایگاه داده توزیع شده مانند Cassandra را در نظر بگیریم:

• سازگاری (C): در Cassandra، می توانید سطح سازگاری را پیکربندی کنید. به عنوان مثال، می‌توانید آن را طوری تنظیم کنید که اطمینان حاصل شود که نوشتن فقط در صورتی موفق تلقی می‌شود که در تمام گره‌ها (یا اکثریت) نوشته شود.
• در دسترس بودن (A): Cassandra طوری طراحی شده است که در دسترس باشد. از تکرار استفاده می کند و طوری طراحی شده است که همیشه خواندن و نوشتن را بپذیرد.
• تحمل پارتیشن (P): کاساندرا تحمل پارتیشن دارد. این می تواند پارتیشن های شبکه را مدیریت کند و با اطمینان از اینکه داده ها در نهایت سازگار هستند به کار خود ادامه می دهد.

سناریو 1: CA (ثبات + در دسترس بودن)

• مثال: پایگاه داده های رابطه ای سنتی مانند MySQL در یک راه اندازی master-slave.
• مصالحه: ممکن است در طول پارتیشن های شبکه برای حفظ ثبات در دسترس نباشند.

سناریو 2: CP (ثبات + تحمل پارتیشن)

• مثال: MongoDB را می توان برای CP با اطمینان از سازگاری داده ها در بین کپی ها پیکربندی کرد.
• مصالحه: ممکن است برای برخی از عملیات در طول پارتیشن ها در دسترس نباشد.

سناریو 3: AP (در دسترس بودن + تحمل پارتیشن)

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

بیایید مثال دیگری بزنیم:

قضیه CAP در زمینه یک سیستم بانکی

بیایید یک سیستم بانکی با چندین دستگاه خودپرداز که بخشی از یک سیستم توزیع شده است را در نظر بگیریم. ما بررسی خواهیم کرد که چگونه قضیه CAP زمانی که دو دستگاه خودپرداز نیاز به همگام سازی داده ها (مانند موجودی حساب) در حضور پارتیشن های شبکه دارند، اعمال می شود.

سناریو: دو دستگاه خودپرداز و یک پارتیشن شبکه

تصور کنید دو دستگاه خودپرداز ATM1 و ATM2 به یک سرور پایگاه داده مرکزی متصل هستند. یک پارتیشن شبکه رخ می دهد که ATM1 را از ATM2 و سرور مرکزی جدا می کند.

معاوضه در سیستم بانکی

با توجه به محدودیت های قضیه CAP، سیستم بانکی باید مبادلات زیر را انجام دهد:

• CA (ثبات + در دسترس بودن):

  • رفتار – اخلاق: این سیستم اطمینان از سازگاری و در دسترس بودن هر تراکنش را در اولویت قرار می دهد.
  • مثال: در طول یک پارتیشن شبکه، دستگاه های خودپرداز ممکن است برای جلوگیری از ناهماهنگی در دسترس نباشند. مشتریان ممکن است نتوانند تراکنش ها را تا زمانی که پارتیشن حل نشده انجام دهند.
  • پیامد: این رویکرد دقت را تضمین می کند اما می تواند به دلیل در دسترس نبودن منجر به تجربه ضعیف مشتری شود.

• CP (ثبات + تحمل پارتیشن):

  • رفتار – اخلاق: سیستم ثبات را در اولویت قرار می دهد و می تواند پارتیشن ها را مدیریت کند اما در دسترس بودن را قربانی می کند.
  • مثال: در طول یک پارتیشن شبکه، ATM ها ممکن است پذیرش تراکنش ها را متوقف کنند تا زمانی که بتوانند با سرور مرکزی همگام شوند و اطمینان حاصل شود که همه تراکنش ها سازگار هستند.
  • پیامد: این رویکرد دقت داده ها را حفظ می کند اما منجر به وقفه در سرویس می شود.

• AP (در دسترس بودن + تحمل پارتیشن):

  • رفتار – اخلاق: این سیستم در دسترس بودن و تحمل پارتیشن را اولویت بندی می کند اما ثبات فوری را قربانی می کند.
  • مثال: در طول یک پارتیشن شبکه، هر دو دستگاه خودپرداز به پذیرش تراکنش ها ادامه می دهند. ATM1 ممکن است اجازه برداشت را بدهد حتی اگر نتواند فوراً با ATM2 همگام شود و منجر به تناقضات موقتی شود (مثلاً اضافه برداشت بالقوه).
  • پیامد: این رویکرد تضمین می‌کند که دستگاه‌های خودپرداز همچنان عملیاتی هستند، اما موجودی ممکن است بلافاصله در هر دو دستگاه خودپرداز دقیق نباشد. سیستم پس از رفع پارتیشن شبکه، ناسازگاری ها را برطرف می کند و در نهایت به یکپارچگی دست می یابد.

نمونه راهنما

حالت اولیه:

• مشتری A 500 دلار در حساب خود دارد.

در طول پارتیشن شبکه:

1. ATM1: مشتری A 100 دلار برداشت می کند.

   • ATM1 موجودی 400 دلاری را نشان می دهد.
   • ATM2 که هنوز ایزوله است، موجودی 500 دلاری را نشان می دهد.

2. ATM2: مشتری A 200 دلار برداشت می کند.

   • ATM2 موجودی 300 دلاری را نشان می دهد.
   • ATM1 که هنوز ایزوله است، موجودی 400 دلاری را نشان می دهد.

پس از حل پارتیشن شبکه:

• سیستم باید تفاوت ها را تطبیق دهد:
  • تراز نهایی باید هر دو تراکنش را منعکس کند: 500 دلار – 100 دلار – 200 دلار = 200 دلار.

قضیه CAP در زمینه یک بستر رسانه اجتماعی

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

سناریو: پست های کاربر و پارتیشن شبکه

دو کاربر، کاربر A و کاربر B را تصور کنید که در پلتفرم با هم دوست هستند. کاربر A یک به روز رسانی پست می کند و به دلیل پارتیشن شبکه، دید کاربر B از به روز رسانی ها به طور موقت تحت تأثیر قرار می گیرد.

مبادلات در بستر رسانه های اجتماعی

با توجه به محدودیت های قضیه CAP، پلت فرم رسانه های اجتماعی باید معاوضه هایی را انجام دهد:

• CA (ثبات + در دسترس بودن):

  • رفتار – اخلاق: سیستم اطمینان از سازگاری و در دسترس بودن هر تعامل را در اولویت قرار می دهد.
  • مثال: در طول یک پارتیشن شبکه، پلتفرم ممکن است برای جلوگیری از ناسازگاری در دسترس نباشد. ممکن است تا زمانی که پارتیشن حل نشود، کاربران نتوانند به‌روزرسانی‌ها را پست کنند.
  • پیامد: این رویکرد دقت را تضمین می کند اما می تواند به دلیل در دسترس نبودن منجر به تجربه کاربری ضعیف شود.

• CP (ثبات + تحمل پارتیشن):

  • رفتار – اخلاق: سیستم ثبات را در اولویت قرار می دهد و می تواند پارتیشن ها را مدیریت کند اما در دسترس بودن را قربانی می کند.
  • مثال: در طول یک پارتیشن شبکه، پلتفرم ممکن است پذیرش پست‌ها یا تعاملات جدید را متوقف کند تا زمانی که بتواند با همه سرورها همگام شود و اطمینان حاصل شود که همه داده‌ها سازگار هستند.
  • پیامد: این رویکرد دقت داده ها را حفظ می کند اما منجر به وقفه در سرویس می شود.

• AP (در دسترس بودن + تحمل پارتیشن):

  • رفتار – اخلاق: این سیستم در دسترس بودن و تحمل پارتیشن را اولویت بندی می کند اما ثبات فوری را قربانی می کند.
  • مثال: در طول یک پارتیشن شبکه، هم کاربر A و هم کاربر B به استفاده از پلتفرم ادامه می دهند. کاربر B ممکن است بلافاصله آخرین به روز رسانی کاربر A را نبیند، که منجر به تناقضات موقت می شود.
  • پیامد: این رویکرد تضمین می‌کند که پلتفرم همچنان عملیاتی است، اما به‌روزرسانی‌ها ممکن است فوراً در همه کاربران سازگار نباشد. سیستم پس از رفع پارتیشن شبکه، ناسازگاری ها را برطرف می کند و در نهایت به یکپارچگی دست می یابد.

نمونه راهنما

حالت اولیه:

• کاربر A و کاربر B با هم دوست هستند.
• کاربر A یک به روز رسانی قبلی ارسال کرده است که کاربر B می تواند آن را ببیند.

در طول پارتیشن شبکه:

1. کاربر A: آپدیت جدید ارسال می کند.

   • به روز رسانی برای کاربر A و کاربرانی که در همان پارتیشن کاربر A هستند قابل مشاهده است.
   • کاربر B که روی پارتیشن دیگری قرار دارد، فورا آپدیت را نمی بیند.

2. کاربر B: پستی از یک دوست دیگر را لایک می کند.

   • موارد مشابه برای کاربر B و کاربرانی که در همان پارتیشن کاربر B هستند قابل مشاهده است.
   • کاربر A که در پارتیشن دیگری قرار دارد، بلافاصله مانند آن را نمی بیند.

پس از حل پارتیشن شبکه:

• سیستم باید تفاوت ها را تطبیق دهد:
  • به روز رسانی جدید کاربر A به فید کاربر B منتشر می شود.
  • لایک کاربر B به دیدگاه کاربر A از پست منتشر می شود.

نتیجه

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

جزئیات بیشتر:

دریافت کلیه مقالات مرتبط با طراحی سیستم
Hastag: SystemDesignWithZeeshanAli

systemdesignwithzeeshanali

Git: https://github.com/ZeeshanAli-0704/SystemDesignWithZeeshanAli