Cloudflare בונה מערכת קונצנזוס גלובלית — ובמקום לבחור ב‑Raft המוכר, היא הלכה על אלגוריתם שלא נוסה מעולם בפריסה כזו. בפוסט טכני שפורסם ב‑11 בנובמבר 2026, החברה הסבירה מדוע בחרה ב‑QuePaxa עבור Meerkat, שירות ניסיוני שנועד לנהל חלקים ממישור הבקרה הגלובלי שלה.
מה Cloudflare מנסה לפתור?
מערכות מבוזרות צריכות להסכים על אמת משותפת: מהו סדר האירועים, איזה ערך נכתב אחרון ומהו המצב התקף. אלגוריתמי קונצנזוס כמו Raft, Multi‑Paxos ו‑Viewstamped Replication עושים זאת היטב בתוך אזור או רשת יציבה יחסית.
הבעיה מתחילה כאשר ה‑replicas מפוזרים בין יבשות. זמן ההשהיה משתנה, קישורים נופלים ומנהיג שנראה ״מת״ עשוי פשוט להיות רחוק או איטי. באלגוריתם שתלוי ב‑leader יחיד, כשל או האטה של המנהיג יכולים לעצור את המערכת עד לבחירת מנהיג חדש.
מהו QuePaxa?
QuePaxa הוא אלגוריתם קונצנזוס חדש יחסית שמאפשר לכל proposer להציע ערך. קיים leader שמקבל מסלול מהיר ויכול להחליט בסבב תקשורת אחד כאשר התנאים טובים, אבל הוא אינו נקודת הכשל היחידה. אם הוא נעלם או מתעכב, proposers אחרים יכולים להמשיך לפעול בלי להמתין תחילה לזיהוי רשמי של הכשל.
האלגוריתם משתמש בעדיפויות אקראיות ובאימוץ הצעות כדי לגרום ל‑proposers להתכנס לאותה הצעה. ייתכן שסבב מסוים לא יספיק, אך העבודה שכבר נעשתה אינה נזרקת, והמערכת ממשיכה לסבב הבא עם הידע שנצבר.
למה לא פשוט Raft?
ב‑Raft, מעבר למנהיג חדש תלוי ב‑failure detector וב‑election timeout. timeout קצר מדי ברשת גלובלית עלול לגרום לבחירות שווא ולחוסר יציבות; timeout ארוך מדי משאיר את המערכת ממתינה כאשר המנהיג באמת אינו זמין. Cloudflare מסבירה שבפריסה בין־יבשתית, זיהוי כשל יכול לקחת בערך שנייה — זמן רב עבור control plane גלובלי.
QuePaxa משתמש ב‑hedging: הלקוח יכול לשלוח בקשות לכמה replicas. ה‑leader מקבל הזדמנות להשלים את המסלול המהיר, אבל אם הוא מתעכב, אחרים מתחילים להציע בלי להכריז שהוא נכשל. ה‑hedge timeout אינו צריך להתאים לזמן ההשהיה של הרשת, ולכן אפשר להגדיר אותו באגרסיביות רבה יותר.
מה המחיר?
- יותר הודעות: כאשר כמה proposers פועלים במקביל, כמות התעבורה גדלה.
- פחות ודאות לסיום בסבב אחד: הצעות מתחרות יכולות לדרוש סבב נוסף.
- מורכבות והבשלה: בניגוד ל‑Raft, אין שנים של ניסיון תפעולי נרחב וכלים בשלים סביב האלגוריתם.
- כוונון: hedge timeout נמוך מגיב מהר יותר, אך מגדיל עומס ותחרות בין הצעות.
מהי Meerkat?
Meerkat היא מערכת ניסיונית שבה replicas מסכימים על log מסודר של אירועים. מעל ה‑log אפשר לבנות שירותים כמו key‑value store: כל replica קורא את אותו רצף פעולות ומגיע לאותו מצב. Cloudflare משווה את הקטגוריה למערכות כמו Consul, etcd ו‑ZooKeeper, אך מדגישה שהיעד שלה גלובלי יותר.
הבחירה ב‑QuePaxa אינה אומרת ש‑Cloudflare מחליפה מחר את כל מערכות Raft שלה. מדובר בשירות ניסיוני ובבחירה שנעשתה עבור תנאי רשת מסוימים. החברה עצמה מציגה את האלגוריתם כבחירה לא שגרתית ומפרטת את הסיכונים והסטיות שלה מהמאמר המקורי.
למה זה מעניין מנהלי תשתיות?
הסיפור אינו רק על אלגוריתם חדש. הוא מדגים עיקרון חשוב בתכנון מערכות: פתרון מצוין בתוך data center אחד עלול להתנהג אחרת לגמרי כאשר ה‑latency נמדד במאות מילישניות ומשתנה ללא הפסקה. מערכות control plane גלובליות צריכות להפריד בין ״מנהיג איטי״ לבין ״מערכת שאינה יכולה להתקדם״.
ארגונים שמתכננים multi‑region צריכים לבדוק לא רק זמינות replicas, אלא גם זמני failover אמיתיים, עלות הבחירות, עומס ההודעות ומידת התלות ב‑leader. בחלק מהמקרים, פריסה אזורית עם federation פשוטה תהיה בטוחה וקלה יותר ממערכת קונצנזוס גלובלית.
השורה התחתונה
QuePaxa מבטיח לשמור על התקדמות גם כאשר ה‑leader נעלם, בלי להמתין לזיהוי כשל שתלוי ב‑latency הגלובלי. אבל Cloudflare עדיין מגדירה את Meerkat ניסיונית. זהו ניסוי הנדסי מסקרן — לא המלצה להחליף מחר את Raft במערכות ייצור.
מקור: Cloudflare Blog — Choosing QuePaxa, an unusual consensus algorithm, 11 בנובמבר 2026.
תמונת המחשה: Jordan Harrison, Unsplash. דף המקור. שימוש לפי Unsplash License.
