Leaderless Replication: רפליקציה מבוזרת בלי Leader יחיד

מאת צוות מדיה דיל · 30.06.2026 · טכנולוגיה · 4 דק׳

Quorum Reads, Quorum Writes, R + W > N, Read Repair, Amazon Dynamo, ו-Cassandra.

ברפליקציה מבוססת leader, כל כתיבה עוברת דרך node יחיד שמפיץ אותה הלאה, ואם ה-leader נופל צריך תהליך בחירה (leader election) לפני שאפשר לכתוב שוב, חלון זמן שבו המערכת כולה לא זמינה לכתיבה. Leaderless Replication, כמו שמיושם ב-Amazon Dynamo ו-Cassandra, מוותר על התפקיד המיוחד הזה לגמרי: כל replica יכולה לקבל כתיבות וקריאות ישירות, בלי תלות בצומת בודד שחייב להיות זמין כדי שהמערכת תעבוד.

המודל: כל Replica שווה, אין Leader מיוחד

בארכיטקטורת leaderless, client שולח בקשת כתיבה או קריאה ישירות לכמה replicas במקביל, לא רק לאחד ייעודי. כל replica מטפלת בבקשה עצמאית, בלי לעבור דרך תיאום מרכזי. זה אומר שאין single point of failure מובנה בתפקיד עצמו: נפילת replica בודד לא דורשת בחירת מנהיג חדש, כי אין תפקיד מנהיג מלכתחילה. המחיר הוא שהעקביות בין replicas לא מובטחת אוטומטית ברגע הכתיבה, וצריך מנגנון נפרד כדי לשמור עליה לאורך זמן.

Quorum Writes: לא צריך את כל ה-Replicas

כדי לכתוב ערך, client שולח את הבקשה ל-N replicas ומחכה לאישור מ-W מתוכן בלבד (write quorum), לא מכולן. אם N הוא שלוש ו-W הוא שתיים, הכתיבה נחשבת מוצלחת ברגע ששתי replicas אישרו, גם אם השלישית איטית או זמנית לא זמינה. זה מאפשר למערכת להמשיך לכתוב גם כשreplica אחד או יותר נופלים, כל עוד W מתוך N זמינים, גמישות שרפליקציה מבוססת leader לא מספקת כשה-leader עצמו הוא הצוואר בקבוק.

Quorum Reads: R + W > N

קריאה עובדת באופן דומה: client פונה ל-N replicas ומחכה לתשובה מ-R מתוכן, ומחזיר את הערך העדכני ביותר שראה. הנוסחה הקלאסית R + W > N מבטיחה שכל קבוצת קריאה חופפת עם כל קבוצת כתיבה קודמת בלפחות replica אחד משותף, כך שהקריאה תמיד רואה את הכתיבה האחרונה, גם בלי לפנות לכל ה-replicas. הגדרות נפוצות הן N=3, W=2, R=2, שמאזנות בין latency (פחות replicas לחכות להם) לבין ערבות עקביות חזקה יחסית.

Read Repair: תיקון עקביות תוך כדי קריאה

כשclient קורא מכמה replicas ומגלה שגרסאות שונות חוזרות, replica אחד עדיין מחזיק ערך ישן שלא קיבל עדכון אחרון, מנגנון Read Repair דואג לכתוב את הגרסה העדכנית חזרה ל-replica המפגר, כחלק מתהליך הקריאה עצמו, בלי לחכות לתהליך רקע נפרד. זו דרך אלגנטית להביא replicas מפגרים לעדכניות בהדרגה, תוך שימוש בתעבורת הקריאה הרגילה שממילא קורית, במקום להריץ תהליך סנכרון יקר ונפרד על כל האשכול.

זיהוי כתיבות מקבילות עם Vector Clocks

בלי leader שקובע סדר כתיבה יחיד, שני clients יכולים לכתוב לאותו מפתח כמעט בו-זמנית דרך replicas שונים, מה שיוצר שתי גרסאות שאף אחת מהן לא קדמה לשנייה באמת. כדי להבחין בין זה לבין דריסה רגילה של ערך ישן, מערכות leaderless משתמשות ב-Vector Clocks שמזהים במדויק מתי שתי כתיבות היו concurrent, ומחזירים את שתיהן ל-client להחלטה, במקום לבחור שרירותית איזו לשמור ולאבד מידע.

מתי זה עדיף על Replication מבוסס-Leader

Leaderless Replication מתאים במיוחד לעומסים עם דרישת זמינות גבוהה לכתיבה גם באזורים גיאוגרפיים מרוחקים, למשל עגלת קניות גלובלית שחייבת לקבל כתיבות גם כשקישור בין data centers נופל זמנית. לעומת זאת, כשנדרשת עקביות חזקה ומיידית (strong consistency) על סדר הכתיבות, כמו יתרות בנקאיות, מודל leader-based עם Gossip Protocol להפצת מטא-דאטה על מצב האשכול נותן ערבויות פשוטות יותר להבנה, גם במחיר של פחות זמינות בזמן נפילת leader.

בונים מערכת שצריכה זמינות כתיבה גבוהה גם כש-nodes נופלים? נשמח לעזור לכם בוואטסאפ.

תגיות: Leaderless Replication · Quorum · Read Repair · Amazon Dynamo · Cassandra

← חזרה לבלוג · צור קשר