قضیه CAP
قضیه CAP: در شبکه پارتیشن‌شده باید بین سازگاری و دسترس‌پذیری یکی را انتخاب کنیم + توسعه PACELC
قضیه بنیادین سیستم‌های توزیع‌شده
CAP Theorem (بروئر، ۲۰۰۰): یک سیستم توزیع‌شده نمی‌تواند هم‌زمان هر سه را داشته باشد:
- C — Consistency (سازگاری): همه خواندن‌ها، آخرین نوشتن را می‌بینند
- A — Availability (دسترس‌پذیری): هر درخواست، پاسخ می‌گیرد
- P — Partition Tolerance (تحمل پارتیشن): حتی با قطع شبکه کار می‌کند
چرا P قابل حذف نیست؟
شبکه همیشه ممکن است قطع شود (کابل، دیتاسنتر، اینترنت) — P اجباری است! پس انتخاب واقعی:
CP: سازگاری را نگه دار، بعضی درخواست‌ها را رد کن
AP: پاسخ بده، حتی اگر داده قدیمی باشدمثال ملموس: دو دیتابیس، شبکه قطع!
کاربر A → DB1: موجودی را ۹۰ تومان کرد
شبکه بین DB1 و DB2 قطع!
کاربر B → DB2: موجودی را می‌خواند
CP: DB2 پاسخ نمی‌دهد («مطمئن نیستم») ← سازگار اما غیرقابل دسترس
AP: DB2 پاسخ می‌دهد: ۱۰۰ (قدیمی!) ← در دسترس اما ناسازگارهیچ جادویی نیست — یکی را قربانی کن!
مثال‌های واقعی
| سیستم | انتخاب | چرا |
|---|---|---|
| پرداخت بانکی | CP | دو برداشت از یک موجودی = فاجعه! |
| تایم‌لاین شبکه اجتماعی | AP | پست چند ثانیه دیر = OK؛ سرویس پایین = فاجعه |
| سبد خرید | AP | سبد گم نشود؛ قیمت لحظه‌ای نه |
| موجودی انبار | CP | فروش کالای ناموجود = مشکل |
PACELC — توسعه واقع‌بینانه
CAP فقط حالت «پارتیشن» را می‌بیند؛ PACELC اضافه می‌کند:
اگر Partition (P): انتخاب A یا C (مثل CAP)
وگرنه (Else): انتخاب Latency یا Consistency!حتی بدون پارتیشن: همگام‌سازی سریع (C بالا، تأخیر نوشتن) یا async (سریع، کهنگی ممکن)!
سازگاری نهایی (Eventual Consistency)
انتخاب AP یعنی: داده‌ها «بالاخره» هم‌رنگ می‌شوند — نه فوراً! تایم‌لاین، DNS، سبد خرید — اکثر سیستم‌های بزرگ این‌طورند.
نکته مصاحبه: CAP را با مثال «پرداخت در برابر تایم‌لاین» توضیح دهید — نشان می‌دهد نه فقط قضیه را می‌دانید، بلکه در تصمیم واقعی به‌کار می‌گیرید.
جمع‌بندی
- CAP: سه‌گانه غیرممکن؛ P اجباری
- انتخاب واقعی: CP (رد درخواست) یا AP (داده قدیمی)
- پول = CP؛ تجربه کاربری = AP
- PACELC: حتی بدون پارتیشن، تأخیر/سازگاری ترید‌آف است
این مبحث بخشی از دوره آموزش کامل طراحی سیستم (System Design) است.