מודלים עקביים

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

1) דגמים ”נוקשים”

ליניארי (חזק)

התנהגות כאילו כל הפעולות בוצעו באופן מיידי בסדר אחיד כלשהו שמכבד את הזמן האמיתי.
מקצוענים: מודל מנטלי פשוט, בטוח לכסף וייחודיות.
Cons: quorums/leader = p95/p99 growth, במיוחד באופן זמני.
השתמש במקרים: מאזנים, מלאי עם מגבלות קשות, שמות/מפתחות ייחודיים.

עקביות רציפה

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

Serializable

שקול לכמה סדרי רצופים של עסקאות (לא פעולות בודדות).
מקצוענים: תקינות של אינווריאנטים מורכבים ברמת השאילתה/טבלה.
חסרונות: יותר יקרים (חסימה/אימות קונפליקט).
השתמש במקרים: עסקאות פיננסיות מורכבות, ספירות עקביות, מלאי.

Snapshot Isolation (SI)

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

2) לכל הפעלה וערבויות סיבתיות

קריאה-כתיבה-שלך (RYW)

הלקוח תמיד רואה את זה בקריאות הבאות לאחר כניסתו.
יתרונות: UX טוב (טופס = אישור).
אחריות מקומית, לא גלובלית.

מונוטוני קורא/כותב

קריאות לא ”להתגלגל בחזרה”; רשומות של לקוח אחד מיושמות באותו סדר כמו אלה שנשלחו.

עקביות סיבתית

אם המבצע תלוי באחר (A = B), כולם רואים את A לפני B.
יתרונות: אינטואיטיבי עבור הזנות חברתיות, הערות.
חסרונות: ניתוב ותוויות סיבתיות (שעונים וקטוריים) קשים יותר.
מפתחות משתמש: תקשורת, עריכה משותפת, הזנות אירועים.

3) דגמים חלשים והיברידיים

עקבתName

הקריאה יכולה לסמן לא יותר מגרסאות Transply או N.
מקצוענים: UX צפוי, פשרה טובה באופן זמני.
לא מגן מפני קונפליקטים בכתב.

סופו של דבר עקביות

עם הזמן, כל העותקים מתכנסים; סדר ועיכוב אינם מובטחים.

יתרונות: לינות/עלות מינימלית, זמינות גבוהה (AP)

חסרונות: צריך מיזוג מפורש (כללי CRDT/domain).
השתמש במקרים: מטמונים, הזנות, מדדים, אוהב, nen ספריות קריטיות.

4) חריגות טיפוסיות ומה משמעותן

קריאה מלוכלכת: קריאת נתונים לא מחויבים.
קריאה לא חוזרת: אותה קריאה בתוך עסקה נותנת ערכים שונים.
פנטום: על פי בקשה חוזרת, מחרוזת התואמת לחיזוי מופיעה/נעלמת.
כתוב Skew (עם SI): שתי עסקאות קוראות את האינווריאנט המצטלב וכתוב שורות שונות, תוך הפרת התנאי ”הסכום חייב להיות 1”.
עדכון אבוד: התקליט ”משכתב” את השינויים של המתחרה.

5) קורומים ורמות קריאה/כתיבה

חנויות רבות מאפשרות לך להגדיר את רמות ה-R/W (מספר ההעתקים לקריאה/כתיבה).

קוורום (R + W> N) נותן ”צומת” וערבות חזקה לקריאות של התקליט האחרון.
W = 1, R = 1 כפול Latency, אבל מידע ישן אפשרי.
כוונון: פעולות קריטיות - גבוה ”W” (או מנהיג), השאר - נמוך ”R” למהירות.
קריאה-תיקון/מסירה מרומזת לעזור לקבל עקביות ברקע.

6) שעות וסדר: כיצד אנו ”מבינים” סיבתיות

שעוני מנורה: סדר חלקי של אירועים.
שעוני וקטור: לתקן סיבתיות, לאפשר איתור קונפליקטים.
גישות זמן היברידי/TrueTime: להגביל את התפשטות שעונים באשכול עבור הזמנת עסקה ועקיבה כבולה.
Versioning: ”גרסה/ts + שחקן” למיזוג; ב-CRDT, חצי-גרפים סגורים (קומוטציה/אידמפוטנטיות).

7) התמזגות CRDT ותחום

CRDT (סוג נתונים מתכנסים/משוכפלים) מבטיח התכנסות ללא תיאום: G-Counter, OR-SET, LWW-Register, Map, text OT/WOOT.
כאשר שימושי: אוהב, תגיות רבות, סלים, מסמכים.
מגבלות: להמציא את הסמנטיקה הנכונה של ”מיזוג” עבור ישות מסוימת.

8) תקשורת עם CAP/PACELC

מודלים קפדניים (Linearizable/Serializable) ב-multi-region # CP עם latency הולך וגדל (PACELC: בחר C ושלם L).
מודלים חלשים/היברידיים * AP ו/או low L, אך זקוקים למיזוג/יישוב סכסוכים.
היברידי: CP-Cernel עבור אינווריאנטים + AP-presentions/caches לקריאה.

9) בחירת מודל: רשימה

1. מדריכים: מה אין להפר? ‏ (ייחודיות, איזון, גבולות).
2. איפה הכתיבה/הקריאה נעשית? (מקומי/גלובלי).
3. SLO על ידי latency: p95/p99 עבור מסלולים קריטיים?
4. מחיר קואורדינציה: מוכן לשלם עם מניין בין-אזורי?
5. קונפליקטים: האם יש לך מיזוג דטרמיניסטי או שאתה זקוק למתאם?
6. ציפיות UX: RYW/מונוטונית/סיבתיות חשובות עבור הלקוח?
7. תצפית: איך מודדים פיגור/קונפליקט/מידה של התיישנות?
8. פולבקים: מה קורה כאשר רשת מפוצלת (P)? קריאה בלבד/כניסה מקומית/תורים?

10) מתכונים מהירים

תשלום/איזון: Linearizable/Serializable, leader + quorum, פסקי זמן קצרים; קריאות RYW.
פרופילים/הזנה: Causal/Bounded Stabiness + Cache; CRDT עבור לייקים/ספירות; RYW למחבר.
חיפוש/אנליטיקה: SI/Read מחויב, תחזיות אסינכרוניות, בסופו של דבר לאינדקסים.
Global SaaS: Geo-לחלק; ”רשומות הבית” - CP, דיווחים/ספריות - AP.
עריכה משותפת: סיבתיות/סופו של דבר + CRDT/OT; שימור ”היסטוריה”.

11) עקביות נצפתה

Lag metrics: "שכפול _ לאג", "staleness _ age _ ms' (p50/p95/p99).
קונפליקט: אחוז הקונפליקטים, זמן פתרון ממוצע.
מניין: הצלחה 'R/W' quorums, פסקי זמן של נתיבים בין-אזוריים.
אחריות לקוחות: RYW/monotonic - תגי עקבות לאחר הפעלה.

12) שגיאות אופייניות

דרישה חזקה ”בכל מקום” ללא בסיס עסקי.
כתיבה כפולה לאזורים שונים ללא סגה/CRDT # פנטומים ואובדן אינווריאנטים.
התעלם ממונוטוניות RYW/monotonicity ב- UX # ”חסר” את הנתונים שזה עתה נשלחו.
אין לעקוב אחר ההזדקנות של מטמונים/תחזיות = אי התאמות ”נצחיות”.
מיזוג לא מתוכנן = לא צפוי אובדן/שכפול ערכים.

13) ארכיטקטורת מיני-התייחסות

כתיבה-ליבה (CP): מנהיג, רשומות מניין, פסקי זמן, יומנים.
צפיות ממומשות, מטבעות TTL, קריאה-תיקון.
לקוח: סשן דביק/סשן מבטיח (RYW/מונוטוני), תוויות גרסה.
קונפליקט מנוע: כללי CRDT/domain, תור יישוב ידני.
ניטור: פיגור, עימותים, מניות של קריאות מיושנות.

סיכום

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