قضیه CAP: چرا سیستم‌های توزیع‌شده باید سازگاری یا در دسترس بودن را انتخاب کنند، اما هرگز هر دو را با هم نه

فروشندگان نرم‌افزارهای سازمانی به طور معمول پایگاه‌های داده توزیع‌شده خود را به گونه‌ای تبلیغ می‌کنند که گویی سازگاری کامل، در دسترس بودن بدون وقفه و انعطاف‌پذیری مطلق در برابر خرابی‌های شبکه را ارائه می‌دهند. اما واقعیت ریاضی، که توسط محققان سث گیلبرت و نانسی لینچ در سال ۲۰۰۲ اثبات شد، حکم می‌کند که هیچ سیستمی نمی‌تواند هر سه مورد را به طور همزمان هنگام وقوع تقسیم‌بندی شبکه (Network Partition) ارائه دهد.[2]

چارچوبی که این محدودیت را تعیین می‌کند، به عنوان قضیه CAP شناخته می‌شود. این قضیه بیان می‌کند که هر سیستم داده مشترک شبکه‌ای می‌تواند حداکثر دو مورد از سه ویژگی زیر را تضمین کند: سازگاری (Consistency)، در دسترس بودن (Availability) و تحمل تقسیم‌بندی (Partition Tolerance).[6]

سازگاری تضمین می‌کند که هر عملیات خواندن، جدیدترین داده نوشته شده یا یک خطا را دریافت کند. در دسترس بودن تضمین می‌کند که هر درخواست یک پاسخ غیرخطا دریافت کند، بدون اینکه تضمین کند حاوی جدیدترین داده نوشته شده است. تحمل تقسیم‌بندی به این معنی است که سیستم با وجود از دست رفتن یا تأخیر در تعداد دلخواهی از پیام‌ها بین گره‌ها توسط شبکه، به کار خود ادامه دهد.[6]

این مفهوم در سال ۲۰۰۰ شکل گرفت، زمانی که دانشمند کامپیوتر، اریک بروئر، آن را به عنوان یک حدس در سمپوزیوم اصول محاسبات توزیع‌شده ارائه کرد. در آن زمان، رشد سریع غول‌های اولیه وب، مهندسان را مجبور می‌کرد تا معماری‌های سنتی پایگاه داده رابطه‌ای را بازنگری کنند.[1]

دو سال بعد، گیلبرت و لینچ اثبات رسمی ریاضی حدس بروئر را منتشر کردند. آن‌ها نشان دادند که در یک مدل شبکه ناهمگام، پیاده‌سازی یک شیء داده خواندن/نوشتن که هر سه ویژگی را تضمین کند، از نظر ریاضی غیرممکن است.[2]

سوءتفاهم حیاتی در مورد قضیه CAP این است که هر سه ویژگی را به عنوان انتخاب‌های برابر در نظر می‌گیرد. در هر سیستم توزیع‌شده‌ای که در چندین مکان فیزیکی گسترش یافته است، تقسیم‌بندی شبکه یک انتخاب نیست؛ بلکه یک اجتناب‌ناپذیری است. کابل‌ها قطع می‌شوند، روترها از کار می‌افتند و سوئیچ‌های شبکه خراب می‌شوند.[6]

از آنجا که تحمل تقسیم‌بندی یک الزام فیزیکی است و نه یک پیکربندی نرم‌افزاری، مهندسان در واقع مجبور به یک انتخاب دوتایی در طول خرابی شبکه هستند: آن‌ها باید بین سازگاری و در دسترس بودن یکی را انتخاب کنند.[5]

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

برعکس، سیستمی که در دسترس بودن و تحمل تقسیم‌بندی را در اولویت قرار می‌دهد (AP)، جدیدترین نسخه‌ای از داده‌ها را که در اختیار دارد، برمی‌گرداند، حتی اگر نتواند تضمین کند که مطلقاً آخرین نسخه است. فیدهای شبکه‌های اجتماعی و سبدهای خرید خرده‌فروشی به شدت به این معماری‌ها متکی هستند تا اطمینان حاصل کنند که کاربران هرگز صفحه خطای از کار افتادگی را نمی‌بینند.[4]

تا سال ۲۰۱۲، تفسیر سخت‌گیرانه از این قضیه به یک گلوگاه در طراحی سیستم تبدیل شده بود. اریک بروئر یک بازنگری عمده منتشر کرد و اشاره کرد که صنعت این قانون را بیش از حد تحت‌اللفظی گرفته است. بروئر نوشت: «فرمول‌بندی '۲ از ۳' همیشه گمراه‌کننده بوده است، زیرا تمایل داشت تنش‌های بین ویژگی‌ها را بیش از حد ساده کند.»[1]

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

این درک منجر به آن شد که محقق دانیل عبادی در سال ۲۰۱۰ قضیه PACELC را پیشنهاد کند، که قضیه CAP را گسترش داد تا آنچه در طول عملیات عادی رخ می‌دهد را توصیف کند. PACELC بیان می‌کند: اگر تقسیم‌بندی (Partition) وجود داشته باشد، سیستم باید بین در دسترس بودن (Availability) و سازگاری (Consistency) بده‌بستان کند؛ در غیر این صورت (Else)، زمانی که سیستم به طور عادی کار می‌کند، باید بین تأخیر (Latency) و سازگاری (Consistency) بده‌بستان کند.[4]

بده‌بستان تأخیر-سازگاری، واقعیت روزمره مهندسان نرم‌افزار است. برای دستیابی به سازگاری کامل در یک شبکه جهانی، پایگاه داده باید منتظر بماند تا داده‌ها با سرعت نور بین قاره‌ها جابجا شوند و سپس عملیات نوشتن را تأیید کند. این انتظار باعث ایجاد تأخیر می‌شود.[3]

اگر یک سیستم برای حفظ تجربه کاربری روان، به زمان پاسخ‌دهی کمتر از ۱۰ میلی‌ثانیه نیاز داشته باشد، نمی‌تواند منتظر اجماع جهانی بماند. برای برآورده کردن اهداف تأخیر خود، باید سازگاری سخت‌گیرانه را قربانی کند و داده‌های کمی قدیمی را به کاربران در آن سوی جهان ارائه دهد.[7]

معماری‌های ابری مدرن، همانطور که در یک بررسی فنی IBM در سال ۲۰۲۵ تحلیل شد، تلاش می‌کنند تا این بده‌بستان‌ها را با استفاده از الگوریتم‌های اجماع بسیار تنظیم‌شده و نسخه‌های خواندنی محلی‌شده پنهان کنند. با این حال، فیزیک بنیادی انتقال اطلاعات بدون تغییر باقی می‌ماند.[6]

محدودیت‌های ریاضی که در سال ۲۰۰۲ اثبات شدند، همچنان بر هر سیستم توزیع‌شده‌ای که امروز ساخته می‌شود، حاکم هستند. مهندسان نمی‌توانند با کدنویسی، سرعت نور یا آسیب‌پذیری فیزیکی سخت‌افزار شبکه را دور بزنند؛ آن‌ها فقط می‌توانند انتخاب کنند که کدام حالت خرابی کمترین آسیب را به کاربران خاص آن‌ها وارد خواهد کرد.[2]