משפט CAP מוסבר בפשטות

משפט CAP הוא אחד הרעיונות שכל מי שעובד עם מערכות מבוזרות שומע עליו במוקדם או במאוחר, ולעיתים קרובות בצורה מפושטת מדי שמטעה יותר משהיא מסבירה. הגרסה השימושית באמת שלו לא אומרת "בחרו שניים מתוך שלושה" - היא אומרת משהו הרבה יותר ממוקד וחשוב.

שלושת האותיות

C - Consistency, עקביות - כל קריאה מכל צומת במערכת מחזירה את הנתון העדכני ביותר, בלי הבדל לאיזה עותק פונים. A - Availability, זמינות - כל בקשה למערכת מקבלת תשובה, גם אם היא לא מגיעה לצומת "המושלם" ביותר לענות עליה. P - Partition Tolerance, סבילות לפיצול - המערכת ממשיכה לפעול גם כשיש בעיית תקשורת בין חלקים שונים של הרשת, ולא כל הצמתים יכולים לדבר זה עם זה.

למה זה לא באמת "בחרו שניים מתוך שלושה"

הניסוח הפופולרי אומר שאפשר לקבל רק שניים מתוך שלושת המאפיינים בכל זמן נתון. אבל בפועל, פיצול רשת (Partition) הוא לא משהו שבוחרים להיפטר ממנו - ברשת אמיתית, בטח כשמדובר במערכת שפרוסה על כמה שרתים או אזורים גיאוגרפיים, תקלות תקשורת קורות מתישהו, בלי קשר לרצון שלכם. אז המשוואה האמיתית היא לא "בחרו שניים", אלא - כשפיצול רשת קורה בפועל, ורק אז, המערכת חייבת לבחור בין עקביות לזמינות. ברוב הזמן, כשאין פיצול, אפשר לקבל גם עקביות וגם זמינות יחד בלי בעיה.

מה קורה בפועל כשיש פיצול

תארו לעצמכם מסד נתונים ששוכפל בין שני מרכזי נתונים, ופתאום החיבור ביניהם נופל. משתמש פונה לצומת אחד ומבקש לעדכן נתון. יש שתי אפשרויות בלבד. אפשרות ראשונה - המערכת בוחרת עקביות (CP) - היא מסרבת לענות עד שהחיבור בין הצדדים יחזור, כי היא לא יכולה להבטיח שהעדכון יגיע לצד השני, וזה יפגע בעקביות. המשתמש מקבל שגיאה או המתנה ארוכה. אפשרות שנייה - המערכת בוחרת זמינות (AP) - היא עונה בכל זאת, על סמך המידע המקומי שיש לה, גם אם היא לא בטוחה שהצד השני מעודכן. המשתמש מקבל תשובה מיד, אבל ייתכן שהיא לא עקבית עם מה שקורה בצד השני של הפיצול, עד שהתקשורת תתחדש והמערכת תתכנס בחזרה.

דוגמאות מהעולם האמיתי

מערכות כמו מסדי נתונים יחסיים מסורתיים שרצים במצב מבוזר עם דגש על עקביות טרנזקציונית - כמו יישומים בנקאיים - נוטות לבחור CP, כי עדיף להחזיר שגיאה זמנית מאשר להראות יתרה שגויה. מערכות כמו Cassandra או DynamoDB, שנבנו במקור לצרכים כמו עגלת קניות או ספירת מעורבות, נוטות לבחור AP - עדיף שהמערכת תמשיך לענות גם אם לפעמים היא מראה מידע שלא לגמרי מעודכן, כי הפסקת שירות לגמרי גרועה יותר.

למה זה קשור למודלי עקביות שדיברנו עליהם

משפט CAP הוא בעצם הרקע התיאורטי מאחורי הבחירה בין עקביות חזקה לעקביות סופית שדיברנו עליה בפוסט קודם. מערכת שבוחרת CP מיישמת בדרך כלל עקביות חזקה, כי היא מוכנה לוותר על זמינות כדי לשמור עליה. מערכת שבוחרת AP מיישמת בדרך כלל עקביות סופית, כי היא מוכנה לענות עם מידע לא מעודכן לגמרי, ובלבד שהיא תמיד עונה.

למה זה חשוב גם אם אתם לא בונים מסד נתונים

רוב המפתחים לא בונים מסד נתונים מבוזר מאפס - הם בוחרים אחד קיים. אבל הבנת CAP חשובה כי היא מסבירה למה מסדי נתונים שונים מתנהגים אחרת בזמן תקלה, ועוזרת לבחור את הכלי הנכון לכל צורך - מסד נתונים שמעדיף עקביות עבור נתוני תשלומים, ומסד נתונים שמעדיף זמינות עבור נתונים שמותר להם להיות מעט לא מעודכנים.

בקורס ארכיטקטורת תוכנה שלנו עוברים על CAP לצד מודלי עקביות בהקשר מעשי, ומראים איך זה משפיע על בחירת מסד הנתונים בפרויקט אמיתי.

נתקלתם בהחלטה בין עקביות לזמינות בפרויקט שלכם? הצטרפו לקהילה בדיסקורד ותספרו איך הכרעתם.

לסיכום

משפט CAP לא אומר "בחרו שניים מתוך שלושה" באופן כללי - הוא אומר שברגע שקורה פיצול רשת בפועל, מערכת מבוזרת חייבת לבחור בין עקביות לזמינות, ולא יכולה לקבל את שתיהן במלואן באותו רגע. ברוב הזמן, כשאין פיצול, אפשר לקבל גם וגם - וזו בדיוק הסיבה שהבחירה הזאת רלוונטית רק בתרחיש כשל ספציפי, לא כתכונה קבועה של המערכת.