תבנית סאגה ועסקאות מבוזרות
תבנית סאגה ועסקאות מבוזרות
1) מדוע יש צורך בסאגות
2PC קלאסית (שני שלבים) אינה ניתנת למדד, מורכבת תחת כשלים וחוסמת משאבים. הסאגה מפרקת את התהליך העסקי הכולל לרצף של עסקאות מקומיות (צעדים), שכל אחת מהן מתבצעת באופן עצמאי. במקרה של כישלון, הצעדים הבאים מבוטלים, ואלה שכבר הושלמו מקבלים פיצוי על ידי פעולות הפוכות.
התוצאה: עקביות מנוהלת בסופו של דבר ללא חסימה גלובלית, הישרדות גבוהה ופרוטוקול שחזור ברור.
2) מודלים בסיסיים
2. 1 תזמור
מתאם מסור מנהל את הצעדים: שולח פקודות, ממתין לתגובות/אירועים, מתחיל בפיצויים.
מקצוענים: שליטה מרכזית, יכולת תצפית פשוטה, מועדים מפורשים. חסרונות: מרכיב אופציונלי.
2. 2 כוריאוגרפיה
אין מתאם; שירותים מגיבים אחד לשני באירועים ("LookPosed =" Discoved Capted "=" Inventuased Reserved... ").
מקצוענים: קישוריות חלשה. חסרונות: קשה יותר להתחקות, סיכון של ”ריקוד מוות” ללא חוקים ברורים.
2. 3 TCC (נסה לאשר/לבטל)
אפשרות עם ”הקפאה” משאבים:1. נסה - הכנה/שמורה,
2. אישור - קיבעון,
3. ביטול - rollback.
ערבויות הן גבוהות יותר, אבל חוזים ופסקי זמן מילואים מסובכים יותר.
3) חוזי צעדים ופיצויים
כל שלב = עסקה מקומית + פיצוי (idempotent, מאפשר חזרה).
הפיצוי אינו נדרש כדי ”להחזיר את העולם” במלואו - השווי התחומי הוא מספיק (לדוגמה, ”החזר” במקום ”מחיקת התשלום”).
הגדר אינווריאנטים: עבור כסף - היתרה אינה נכנסת למינוס; לפקודות - אין סטטוס ”תלוי”.
הזן מועדים/רזרבות TTL ו ”אספן אשפה” לניסיונות איחור.
4) עקביות וסמנטיקה מסירה
העברת מסרים: לפחות פעם אחת (ברירת מחדל) = כל הפעולות חייבות להיות אידיאמפוטנטיות.
סדר: חשוב על ידי מפתח קורלציה (למשל. order _ id ',' שחקן _ id '.
בדיוק-פעם אחת היא לא המטרה של הסאגה; אנו משיגים אחידות יעילה באמצעות מפתחות אידמפוטנטים, תיבת דואר אלקטרוני ומשיבים נכונים.
5) מצב הסאגה ויומניה
מה לאחסן:- 'Saga _ id', 'correlation _ id', מעמד נוכחי (ריצה/השלמה/פיצוי/פיצוי/נכשל),
- צעד ומשתנים שלה (תעודות זהות בתשלום/רזרבה),
- (יומן היסטוריה) של אירועים/החלטות, מחסומי זמן, מועדים, מספר המגשים מחדש.
- חנות סאגה נפרדת (טבלה/מסמך) זמינה למתאם.
- לכוריאוגרפיה - ”סוכנים” מקומיים של הסאגה, פרסום אירועים סטטוטוריים בנושא משותף.
6) דפוסי הוצאה לאור מהימנים: extbox/inbox
Outbox: הצעד מבצע את השינוי וכותב את פקודת האירוע/פקודה לשולחן היוצא בעסקה אחת; העובד מפרסם לתוך הצמיג.
תיבת דואר אלקטרוני: הצרכן שומר טבלה של "הודעה מעובדת _ id' ac dedup + idempotency.
לאחר תופעת לוואי מוצלחת לבצע קיזוז/ACK (Kafka/RabbitMQ) - לא קודם לכן.
7) עיצוב צעדי סאגה
7. 1 דוגמה (רכישת iGaming/e-commerce)
1. הזמנה נמוכה פי סטטוס 'ממתין'.
2. Authorder Preservation (Try) ac.co.il 'תשלום _ hold _ id'.
3. Reventory # "הזמנה _ id'.
4. תשלום (אישור).
5. Fin Order # ”הושלם”.
- אם (3) The DistrichHold' # נכשל;
- (4) נכשל לאחר (3) □ ”המצאה”;
- אם (5) 'החזר' ו 'המלאי' ייכשלו.
7. 2 מועדים/נסיגה
מגשים מחדש מקסימלי N עם עיכוב מעריכי + jiter.
לאחר שחרג - ללכת 'פיצוי'.
לאחסן next_attempt_at deadline_at לכל צעד.
8) תזמור נגד פלטפורמה
אפשרויות:- תזמור ביתי קל משקל (microservice + Saga table).
- פלטפורמות: Temporal/Cadence, Camunda, Netflix Conductor, Zeebe - לתת טיימרים, מגשים מחדש, זמן עבודה ארוך, ראות וקונסולת אינטרנט.
- לכוריאוגרפיה, השתמש בקטלוג אירועים ובאמנת סטטוס/מפתח קפדנית.
9) פרוטוקולי אינטגרציה
9. 1 Asynchronous (קפקא/RabbitMQ)
פקודות: תשלומים. לאשר. v1 ',' מלאי. שמורה. v1 '.
אירועים: תשלומים. מורשה. v1 ',' מלאי. שמורות v1 ',' תשלומים. שבויים. v1 ',' תשלומים. מוחזר בחזרה. v1 '.
חלק מפתח = ”order _ id'/” player _ id' עבור הסדר.
9. 2 סינכרוני (HTTP/gRPC) בתוך שלב
תקף עבור צעדים ”קצרים”, אבל תמיד עם פסקי זמן/מגשים מחדש/אידמפוטנציה ונשורת לפיצוי אסינכרוני.
10) אידמפוטנטיות ומפתחות
בבקשות פיקוד ופיצוי, pass 'idempotency _ key'.
תופעות לוואי (כתיבה לבסיס הנתונים/כתיבה כבויה) מבוצעות בתנאי: ”בצע אם טרם ראית את” idempotency _ key ””.
פיצוי הוא גם אידמפוטנטי: חזרה על 'RefundSime (id = X) היא בטוחה.
11) שגיאות בטיפול
שיעורים:- טרנזיטיבי (רשתות/פסקי זמן) * מגש/גיבוי.
- Business (לא מספיק קרנות, מגבלות) = פיצוי מיידי/דרך חלופית.
- בלתי ניתן לשחזור = התערבות ידנית, פיצוי ידני.
- בנה מטריצת פתרון: שגיאה סוג action (retry/pleate/esclate).
12) יכולת תצפית ו ־ SLO Sag
SLI/SLO:- איחור מקצה לקצה של הסאגה (p50/p95/p99).
- אחוזי הצלחה.
- זה הזמן לפצות על פיצוי.
- סאגות מיותמות וזמן לג 'י-סי.
- עקבות: ”trace _ id'/” saga _ id' כקישור בין צעדים; מדדי שרפה לתקציבי שגיאות.
יומנים: כל שינוי במצב סאגה רישום מובנה עם סיבה.
13) דוגמאות (פסאודו-קוד)
13. 1 תזמור (רעיון)
python def handle(OrderPlaced e):
saga = Saga. start(e. order_id)
saga. run(step=authorize_payment, compensate=cancel_payment)
saga. run(step=reserve_inventory, compensate=release_inventory)
saga. run(step=capture_payment, compensate=refund_payment)
saga. run(step=finalize_order, compensate=refund_and_release)
saga. complete()
def run(step, compensate):
try:
step () # local transaction + outbox except Transient:
schedule_retry()
except Business as err:
start_compensation(err)13. 2 out box (רעיון שולחן)
outbox(id PK, aggregate_id, event_type, payload, created_at, sent_at NULL)
inbox(message_id PK, processed_at, status)
saga(order_id PK, state, step, next_attempt_at, deadline_at, context JSONB)
saga_log(id PK, order_id, time, event, details)13. 3 כוריאוגרפיה (רעיונות לנושא)
'הזמנות. הצרכנים: תשלומים. לאשר ',' מלאי. שמורה &fost
"תשלומים. מורשה '+' מלאי. הזמנות ”שמורות”. try_finalize'
כל כישלון של ההזמנות של ach. לפצות את התשלומים שיוזמו. ביטול/החזר כספי, ספירת מלאי. שחרור ".
14) השוואה עם 2PC ואס
2PC: עקביות חזקה, אבל חסימות, צווארי בקבוק, צינורות נחושת.
בסופו של דבר, צריך משמעת של פיצוי וטלמטריה.
מקור אירועים: מאחסן אירועים כמקור לאמת; סאגות עליו הן טבעיות, אבל להוסיף מורכבות לנדידה/תצלומים.
15) בטיחות וציות
אבטחת תחבורה (TLS/mTLS), ACL לכל נושא/תור.
באירועים - לפחות PII, הצפנה של שדות רגישים, אסימון.
ביקורת גישה לסאגות ורישומי פיצויים.
SLA עם ספקים חיצוניים (תשלומים/משלוח) = תאריך יעד והגבלת מגש מחדש.
16) רשימת מימושים (0-45 ימים)
0-10 ימים
בחר את תהליכי המועמד (ריבוי שירות, פיצוי).
בחר את המודל (תזמור/כוריאוגרפיה/TCC) ומפתח קורלציה.
תאר צעדים/קיזוזים, הזמנות ותאריכי יעד. הרימו את השולחנות ”סאגה”, ”אאוטבוקס”, ”תיבת דואר אלקטרוני”.
11-25 ימים
כלול את תיבת היוצא/תיבת הדואר הנכנס, אידמפוטנטיות, וחזרה לאחור.
פרוס ראשון סאגות; לוחות מחוונים ועקבות של SLI/SLO.
כתוב ספר הזמנות של פיצויים (כולל מדריך) והסלמה.
26-45 ימים
אוטומטי GC ”תלוי” סאגות, restarts/continuations תקופתי על תאריך יעד.
לבלות את יום המשחק: כישלון צעד, עודף מועד אחרון, תיווך לא זמין.
תקן חוזי אירועים (גרסאות, תאימות), קבע ”ספריית סאגה”.
17) אנטי דפוסים
”פיצוי = למחוק מבסיס הנתונים” במקום פעולה הפוכה נכונה.
אין תיבת יוצא/תיבת דוא "ל = אובדן אירועים/אפקטים כפולים.
Retrai ללא jitter * תלות DDOS עצמית.
מצפה לעקביות חזקה בקריאה ללא ”עיבוד בתהליך”....
תזמורת אחת ענקית עבור כל מונולית השליטה.
כוריאוגרפיה מוחלטת ללא ראות וריקוד בלתי נשלט.
התעלמות מתאריכי יעד * מילואים נצחיים/מחזיקים.
18) מדדי בגרות
90% מהתהליכים הקריטיים מכוסים על ידי סאגות/פיצויים ויש להם את האינווריאנטים המתוארים.
תיבת הדואר היוצא משולבת עבור כל היצרנים/צרכנים Tier-0/1.
p95 סאגה מקצה לקצה היא נורמלית, אחוזי ההצלחה יציבים, יתומים <היעד.
איתור שקוף ולוחות מחוונים ”בצעדים”, התראות שרפה.
יום משחק רבעוני וצ 'ק פיצוי ידני.
19) מסקנה
סאגה היא חוזה קוהרנטיות מעשי למערכות מבוזרות: צעדים ברורים ופעולות הפוכות, פרסום דיסציפלינות (outbox/inbox), מועדים ומגרשים, תצפיות ותהליכי פיצוי. בחר מודל (תזמור/כוריאוגרפיה/TSS), תקן אינווריאנטים ומפתחות, הפוך את המפעילים לאידמפוטנטים - והתהליכים העסקיים הרבים שלך יהפכו להיות צפויים ויציבים ללא 2PC יקרות.