מקור אירועים: יסודות

מהו מקור אירועים

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

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

מונחים בסיסיים

יחידת צבירה - תחום של עקביות עם אינווריאנטים ברורים (סדר, תשלום, איזון).
אירוע - עובדה לא משתנה שהתרחשה בעבר ('תשלום. מורשה ”, צו”. נשלח ').
Event Store הוא יומן בלבד המספק את סדר האירועים בתוך היחידה.
גרסת אגרגייט (באנגלית: Aggregate version) היא הגרסה המיושמת האחרונה.
סנאפוט - רושם מחזורי של המדינה כדי להאיץ את הפיתול.
הקרנה (מודל קריאה) - תצוגה ממומשת לקריאה/חיפוש/דיווח (לרוב אסינכרוני).

איך זה עובד (חוט = אירועים * תחזיות)

1. הלקוח שולח פקודה (”תשלום”, ”הזמנה עצמית”).
2. הצבירה נותנת תוקף לחייזרים, ואם הכל בסדר, זה יוצר אירועים.
3. אירועים מתווספים באופן אטומי לחנות האירוע עם אימות גרסה (אופטימי concurrency).
4. מעבדי הקרנה מנויים על זרימת האירוע ועדכון מודלים לקריאה.
5. כאשר הצבירה נטענת עבור הפקודה הבאה, המצב מוחזר לצילום (אם בכלל) האירוע לאחר הצילום.

עיצוב אירועים

תכונות דרושות (ליבה)

json
{
"event_id": "uuid",
"event_type": "payment. authorized. v1",
"aggregate_type": "Payment",
"aggregate_id": "pay_123",
"aggregate_version": 5,
"occurred_at": "2025-10-31T10:42:03Z",
"payload": { "amount": 1000, "currency": "EUR", "method": "card" },
"meta": { "trace_id": "t-abc", "actor": "user_42" }
}

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

חוזים ותכניות

סכימות תיקון (Avro/JSON Schema/Protobuf) ובדיקת תאימות על CI.
עבור שינויים ”שבירה” - גרסה מרכזית חדשה של האירוע ופרסום מקביל ”v1 ”/” v2” לתקופת הנדידה.

גישה תחרותית: אופטימית

כלל: ניתן לכתוב אירועים חדשים רק אם 'צפוי _ גרסה = current_version'.

pseudo load: snapshot(state, version), then apply events > version new_events = aggregate. handle(command)
append_to_store(aggregate_id, expected_version=current_version, events=new_events)
//if someone has already written an event between load and append, the operation is rejected -> retray with reload

אז אנחנו מבטיחים שלמות של אינווריאנטים ללא עסקאות מבוזרות.

snapshots (תאוצת הפיתול)

תצלם כל אירוע או טיימר.
"snapshot _ state", "aggregate _ id'," version "," creed _ at ".
תמיד לבדוק ולהתעדכן באירועים לאחר הצילום (לא רק לסמוך על השחקנים).
הסר תמונות כדי שניתן יהיה לשחזר אותן מהרישום (לא לאחסן שדות ”קסומים”).

תחזיות ו ־ CQRS

• כתיבה-מודל = אגרגטים + חנות אירועים.
• קריאת מודלים = תחזיות המעודכנות על ידי אירועים (כרטיסי רדיס, OpenSearch לחיפוש, ClickHouse/OLAP לדיווח).
• התחזיות הן אידיאמפוטנטיות: עיבוד מחדש של אותו "אירוע _ id' לא משנה את התוצאה.

אבולוציה מעגלית ותאימות

תוסף-ראשון: הוסף שדות; לא לשנות סוגים/סמנטיקה.
עבור שינויים מורכבים, שחררו סוגי אירועים חדשים וכתבו מנדרי הקרנה.
שמור על כניסה כפולה ('v1' + 'v2') לתקופת המעבר וצלם 'v1' כאשר כל התחזיות מוכנות.

בטיחות, מח "ש ו" הזכות להישכח "

• מזעור PII באירועים (מזהים במקום נתונים, פרטים בצדדים מוגנים).
• Crypto-rase: הצפנת שדות, וכאשר יש צורך במחיקה, השמד את המפתח (האירוע נשאר, אך הנתונים אינם זמינים).
• שינויים באירועים: "משתמש. הופעל באופן פיראטי. עם החלפת שדות רגישים בתחזיות (ההיסטוריה שומרת על עצם העריכה).
• מדיניות השמירה: עבור תחומים מסוימים, חלק מהאירועים יכולים להיות בארכיון לאחסון תולעת.

ביצועים וסולם

החלוקה: הפקודה חשובה בתוך הצבירה - החלוקה על ידי 'agregate _ id'.
התחלה קרה: תמונות + עקום ”לוחץ” מחזורי.
תוספתן אצווה - אירועים קבוצתיים בעסקה אחת.
Backpressure ו-DLQ עבור מעבדי הקרנה; למדוד פיגור (זמן ומספר הודעות).
אינדקס חנות אירועים: גישה מהירה על ידי '(aggregate_type, aggregate_id)' ועל ידי זמן.

בדיקה

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

דוגמאות של תחומים

1) תשלומים

אירועים: 'תשלום. יזם, ”תשלום”. מורשה ',' תשלום. נתפס, התשלום. מוחזר '.
אינווריאנטים: אתה לא יכול ”ללכוד” בלי ”מורשה”; כמויות אינן שליליות; המטבע לא השתנה.
תחזיות: ”כרטיס תשלום” (KV), חיפוש עסקאות (OpenSearch), דיווח (OLAP).

2) פקודות (מסחר אלקטרוני)

אירועים: סדר. במקום, 'סדר. תשלום ”,” סדר. ארזו, הזמינו. נשלח ”, סדר”. נמסר '.
אינווריאנטים: מעברי מצב תרשים מדינה; ביטול אפשרי לפני 'נשלח'.
תחזיות: רשימת הזמנות המשתמש, לוחות SLA לפי מצב.

3) גיליונות שיווי משקל (פיננסים/iGaming)

אירועים: איזון. הופקד, איזון. התלבטו, "איזון. קרדיט, איזון. מותאם ".
קשה אינווריאנט: איזון לא נעלם <0; פקודות הן 'operation _ id'.
פעולות קריטיות נקראות ישירות מהצבירה (עקביות קפדנית), UI - מההשלכה (בסופו של דבר).

מבנה חנות אירועים טיפוסי (וריאנט DB)

אירועים

'event _ id (PK)', 'aggregate _ type', 'aggregate _ id',' version ',' version _ at ',' event _ type ',' prime ',' metafuse '

אינדקס: (aggregate_type, aggregate_id, גרסה).

תמונות

'Aggregate _ type', 'aggregate _ id',' version ',' state ',' creed _ attoff

אינדקס: ”(aggregate_type, aggregate_id)”.

consumers_offsets

'consumer _ id', 'event _ id'/' id',' עדכן _ at '(עבור תחזיות וקמעונאות).

שאלות נשאלות תכופות (FAQs)

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

מה לגבי בקשות ”המדינה הנוכחית”?
או לקרוא מההשלכה (במהירות, בסופו של דבר), או מהיחידה (יותר יקר, אבל בהחלט). פעולות קריטיות בדרך כלל משתמשות בנתיב השני.

האם אני צריך מתווך קפקא/זרם?
חנות אירועים - מקור האמת; ברוקר נוח להפצת אירועים למקרנים ומערכות חיצוניות.

מה לעשות עם ”הזכות להישכח”?
למזער PII, להצפין שדות רגישים וליישם מחיקת קריפטו/רדוקציה בתחזיות.

איך אני נודד נתונים ישנים?
לכתוב תסריט לדור אירועים רטרוספקטיבי ("re-hystory") או להתחיל עם "state-as-is' ולפרסם אירועים רק לשינויים חדשים.

Antipatterns

מקור האירוע ”מתוך הרגל”: מסבך את המערכת ללא תועלת בתחום.
אירועים שמנים: מטען נפוח עם מח "ש ומכפיל - בלמים ובעיות ציות.
חוסר אופטימיות מקבילה: אובדן של אינווריאנטים בעת מירוץ.
תחזיות ללא רבייה: אין שידור חוזר/צילומים = תיקונים ידניים.
CDCs גולמי כאירועי תחום: דלפו סכמות DB וקישוריות קשה.
ערבוב אירועים פנימיים ואינטגרציה: לפרסם ”תצוגה” מיוצבת בחוץ.

בדיקת ייצור

[ מוגדרים ] אגרגטים, מדריכים ואירועים (כותרים, גרסאות, תוכניות).

חנות אירועים [ ] מספקת סדר בתוך הצבירה ובאופן אופטימי.

[ ] Snapshots ותוכנית הבנייה מחדש שלהם כלולים.

[ ] התחזיות הן אידיאמפוטנטיות, יש DLQs ו-lag metrics.

[ מזימות ] מאומתות במצ "ח, מדיניות הגרסאות מתועדת.

[ ] PII הוא מזערי, שדות מוצפנים, יש אסטרטגיית ”שכחה”.

שידור חוזר [ ] Projection בדק על ספסל; יש תכנית התאוששות אסון.

[ ] לוחות מחוונים: מהירות אפליקציה, עיכוב הקרנה, שגיאות יישום, פרופורציה של מגשים מחדש.

סך הכל

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