Raft Consensus Algorithm: איך צמתים מסכימים על האמת

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

Leader Election, Log Replication, בטיחות דרך Majority Quorum, שינוי חברות באשכול, השוואה ל-Paxos, ושימוש ב-etcd, Consul ו-CockroachDB.

אשכול של מסדי נתונים מבוזרים חייב להסכים על סדר האירועים — מי כתב מה קודם, איזה עדכון מנצח כשיש התנגשות — גם כשצמתים נופלים באמצע ורשת מפגרת. Raft Consensus Algorithm נבנה במפורש כדי לפתור את זה בצורה שאפשר להבין ולממש נכון, אחרי שנים שבהן Paxos המקורי נחשב חשוב אבל כמעט בלתי אפשרי להסביר בבירור.

שלושה תפקידים: Leader, Follower, Candidate

בכל רגע נתון כל צומת נמצא באחד משלושה מצבים: Follower פסיבי שמקבל פקודות מה-Leader, Leader יחיד שמרכז את כל הכתיבות ומשכפל אותן החוצה, ו-Candidate — מצב מעברי זמני שצומת נכנס אליו כשהוא מנסה להיבחר ל-Leader חדש. במצב יציב יש תמיד Leader יחיד בדיוק, וכל שאר הצמתים הם Followers.

Leader Election: איך בוחרים מנהיג בלי מתאם מרכזי

כשFollower לא שומע Heartbeat מה-Leader בתוך חלון זמן אקראי (Election Timeout), הוא הופך ל-Candidate, מעלה מספר גרסה (Term) חדש, ומבקש קולות משאר הצמתים. מי שצובר רוב קולות (Majority) הופך ל-Leader לאותו Term. הזמן האקראי בכל צומת מונע מצב שבו כמה צמתים הופכים ל-Candidate בדיוק באותו רגע ומפצלים קולות שוב ושוב.

Log Replication: איך כתיבה הופכת להחלטה מוסכמת

כל כתיבה מתקבלת רק אצל ה-Leader, שמוסיף אותה ל-Log המקומי שלו ומשכפל אותה (AppendEntries) לכל ה-Followers. רק כשרוב הצמתים אישרו שקיבלו את הרשומה, ה-Leader מסמן אותה כ-Committed ומחזיר תשובה ללקוח — כך שגם אם ה-Leader נופל מיד אחרי, הרשומה כבר קיימת אצל רוב הצמתים ולא תלך לאיבוד.

בטיחות: למה Majority Quorum מונע Split Brain

דרישת רוב (לא רק שני צמתים כלשהם) מבטיחה שכל שני Quorums חייבים לחפוף בלפחות צומת אחד — ולכן לא ייתכנו שני Leaders תקפים במקביל לאותו Term. אם חלוקת רשת (Network Partition) מפרידה אשכול לשני חלקים, רק החלק עם רוב הצמתים יכול לבחור Leader ולהמשיך לקבל כתיבות; החלק המיעוט נשאר תקוע בלי Leader עד שהחיבור חוזר — מחיר מודע של עקביות על פני זמינות מלאה.

שינוי חברות: הוספה והסרה של צמתים בלי לעצור את האשכול

שינוי הרכב האשכול עצמו — הוספת צומת חדש, החלפת צומת כושל — הוא פעולה עדינה: מעבר ישיר מהרכב ישן לחדש עלול ליצור רגע שבו יש שני Quorums תקפים בו-זמנית. Raft פותר את זה עם שלב ביניים (Joint Consensus) שדורש רוב גם מההרכב הישן וגם מהחדש בכל החלטה, עד שהמעבר מסתיים באופן מלא ובטוח.

Raft מול Paxos: אותה תוצאה, נגישות שונה לגמרי

Paxos מוכיח מתמטית את אותן תכונות בטיחות, אבל מפורק לתפקידים מופשטים (Proposer, Acceptor, Learner) שקשה למפות לקוד אמיתי בלי טעויות עדינות. Raft פורק את הבעיה במפורש לשלושה תת-תהליכים נפרדים — בחירת מנהיג, שכפול Log, ובטיחות — ותוכנן מלכתחילה כך שיהיה ניתן להסבר ולמימוש נכון, לא רק להוכחה תיאורטית נכונה.

שימוש בפרודקשן: etcd, Consul, CockroachDB

etcd — מסד המפתח-ערך שעליו נבנה כל Kubernetes — משתמש ב-Raft לשמירת מצב האשכול המרכזי. Consul משתמש בו לשכבת ההסכמה שלו (בשילוב עם Gossip Protocol לגילוי ומצב כללי). CockroachDB בונה על Raft ברמת כל טווח נתונים (Range) בנפרד, כך שאלפי מופעי Raft רצים במקביל על פני האשכול כולו.

Raft כבסיס לנעילות מבוזרות

מכיוון שRaft מבטיח החלטה יחידה ומוסכמת, הוא הבסיס הטבעי למימוש נעילות מבוזרות אמינות — מי מחזיק את הנעילה הוא בדיוק סוג השאלה שRaft נועד לענות עליה בוודאות, בניגוד לגישות מבוססות Gossip שנותנות רק תשובה סבירה, לא ודאית.

Log Compaction ו-Snapshots: כשה-Log גדל בלי גבול

ה-Log של Raft גדל עם כל כתיבה ולא יכול לגדול לנצח - צומת חדש שמצטרף היה צריך לשחזר מיליוני רשומות מההתחלה. הפתרון הוא Snapshot: צילום מצב תמציתי של המכונה במצב מסוים, שמאפשר לזרוק את כל הרשומות שקדמו לו. כשצומת מפגר מדי (ה-Leader כבר מחק את הרשומות שהוא צריך), ה-Leader שולח לו Snapshot מלא במקום רשומות בודדות - מנגנון InstallSnapshot נפרד שקריטי להצטרפות מהירה של צמתים חדשים ולריקוברי אחרי נפילה ארוכה.

ביצועים: למה Leader יחיד הוא צוואר בקבוק לכתיבה

כל כתיבה עוברת דרך ה-Leader היחיד, ולכן ה-Throughput של האשכול לכתיבות מוגבל בקצב שצומת בודד יכול לשכפל ולאשר. שתי טכניקות מרככות זאת: Batching (איגוד כמה רשומות ל-AppendEntries אחד) ו-Pipelining (שליחת בקשה הבאה בלי להמתין לאישור הקודמת). קריאות אפשר לסקל דרך ה-Followers עם Lease Reads - ה-Leader מבטיח שהוא עדיין המנהיג לתקופת זמן, ומאפשר לרפליקות קריאה לשרת בלי לעבור דרכו, במחיר של סיכון קטן לקריאה מיושנת אם השעונים סוטים.

Failure Modes נפוצים בפרודקשן

שלוש תקלות חוזרות: Split Votes כשכמה Candidates מתחרים באותו Term ומפצלים קולות שוב ושוב (נפתר עם Election Timeout אקראי, אבל כוונון גרוע מחמיר אותו); צד מיעוט תקוע אחרי חלוקת רשת שלא יכול לקדם כתיבות עד שהחיבור חוזר; ו-Timeout שמכוון קצר מדי ביחס להשהיית הרשת, שגורם לבחירות מנהיג מיותרות ותכופות שמשתקות את האשכול. כל השלוש הן בעיות כוונון, לא באגים - הן דורשות התאמת ה-Timeouts לזמני ה-Round-Trip האמיתיים בסביבה.

מסלול אימוץ: להשתמש ב-etcd או Consul במקום לממש לבד

מימוש Raft נכון מאפס קשה מאוד - הפרטים של Log Compaction, שינוי חברות בטוח וטיפול בכל Failure Mode נוטים להתפספס. כמעט תמיד עדיף להשתמש בשכבת הסכמה מוכנה: etcd כמסד מפתח-ערך מבוזר, או ספריית Raft בוגרת. Raft הוא הבסיס הטבעי לנעילות מבוזרות ולתיאום מצב קריטי, והוא משלים גישות כמו שכפול Leaderless שמוותרות על הסכמה חזקה לטובת זמינות - הבחירה תלויה אם אתם צריכים ודאות או זמינות מקסימלית.

שאלות נפוצות

מה Raft פותר?

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

מה ההבדל בין Raft ל-Paxos?

שניהם מבטיחים את אותן תכונות בטיחות, אבל Raft פורק את הבעיה לשלושה תת-תהליכים ברורים ותוכנן להיות ניתן להבנה ולמימוש נכון, בעוד Paxos קשה ליישם בלי טעויות עדינות.

מה קורה בחלוקת רשת?

רק הצד עם רוב הצמתים יכול לבחור Leader ולקבל כתיבות. צד המיעוט נתקע בלי מנהיג עד שהחיבור חוזר - מחיר מודע של עקביות על פני זמינות.

למה Leader יחיד ולא כתיבה לכל הצמתים?

Leader יחיד מבטיח סדר כתיבות ברור ומונע התנגשויות, אבל הוא צוואר בקבוק ל-Throughput. מרככים אותו עם Batching, Pipelining ו-Lease Reads מה-Followers.

מהו Quorum ולמה צריך רוב?

Quorum הוא רוב הצמתים. דרישת רוב מבטיחה שכל שני Quorums חופפים בלפחות צומת אחד, ולכן לא ייתכנו שני Leaders תקפים במקביל - מה שמונע Split Brain.

מה זה Snapshot ב-Raft?

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

אילו מערכות משתמשות ב-Raft?

etcd שעליו נבנה Kubernetes, Consul לשכבת ההסכמה שלו, ו-CockroachDB שמריץ מופע Raft נפרד לכל טווח נתונים - אלפי מופעים במקביל.

כדאי לממש Raft לבד?

ברוב המקרים לא. עדיף להשתמש ב-etcd או בספריית Raft בוגרת, כי הפרטים של Log Compaction, שינוי חברות ו-Failure Modes קשים לממש נכון מאפס.

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

תגיות: Raft · Consensus Algorithm · מערכות מבוזרות · etcd · Distributed Systems

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