הודעות העברה

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

1) סמנטיקה מסירה

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

2) למה ”שתי אותיות” זה מסוכן

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

3) תבניות בסיסיות

3. 1 Outbox (יצרן)

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

3. 2 תיבת דוא "ל/צרכן אידמפוטנטי

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

3. 3 קריאה-תהליך-כתיבה עם עסקת Offset

תבנית לאוטובוסים מוכווני יומן: הצרכן קורא את המנה, באותה עסקה רשום השינוי העסקי ו ”עבר קיזוז”. "לאחר ההתחייבות, הברוקר מחשיב את המסרים הנצרכים. הדבר מבטל את ”read # fall # return” ללא כפילויות.

3. 4 TSS/SAGAS להשפעות אינטרסרבייס

כאשר אתה צריך תהליך רב שלבי עקבי, השתמש ב-TCC או סאגות; הודעות - העברת פקודות/אירועים, והעברות - ברמה של צעדים ופיצויים.

4) יצרנים וצרכנים איכותיים

Production: stable 'message _ id'/' idempotency _ key', residening עם אותו מפתח לא יוצר אפקטים חדשים למנויים; לשמור על רצף לפי מפתח.
צרכן: ”inbox” + idempotency עסקי (upsert/merge, סמן גרסה/גרסה עדכנית).

5) סדר וסיבתיות

להשתתף על ידי מפתח עסקי (לדוגמה, ”aggregate _ id',” terenant _ id') כך שהאירועים של אובייקט אחד מגיעים בסדר.
שמור מספרים/מחסומי זמן עוקבים בתוך המגרש; כאשר שרטוט מחדש מ DLQ, להתבונן ”על ידי מפתח ורצוף”.
אם הסדר הגלובלי אינו קריטי, להבטיח סדר מקומי על ידי מפתח ולתקן אינווריאנטים דומיין.

6) קיזוז ותיקון אפקטים

אפשרות א ': ”Offset in DB”

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

אפשרות ב ': עסקת ברוקרים

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

7) רטריי, אחורה, DLQ

חוזר רק על שגיאות ניתנות לניסוח (פסקי זמן, 5xx), עם גיבוי מעריכי וליצן.
לא ניתן לשחזור (סכימה/אימות) - מיד ב-DLQ עם metadata (דייר, מפתח, קיזוז, סיבה).
מנה את הרדרייב מ ־ DLQ (אצווה, הגבלת קצב), בדוק את המעגל לפני החזרה, התבונן בפקודה לפי מקש.

8) עמידות מרובה ואזורים

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

9) יכולת תצפית וביקורת

איתור: corlation 'event _ id'/' aggregate _ id '/' saga _ id', משתרע "לקרוא" expert process _ write/biew ".
Metrics: הוצאה לאור/עיבוד לאג (p95/p99), אחוזי הצלחה, DLQ-rate, redrive lag, ”שכפול”.
יומנים: קיצור להצלחה; פרטים על שגיאות (סיבה, ניסיון, מפתח, קיזוז).
ביקורת: מי צייר מחדש/התגלגל חזרה, איזו קבוצה ואיזו תוצאה.

10) בטיחות וציות

מזעור PII במטען; מסכה בעת העברה לדי-אל-קיו/יומנים.
חתום/הצפן הודעות לאוטובוסים חיצוניים; השתמש ב-MTLS בין השירותים.
לנהל חיי מדף ו ”זכות לשכוח” לדייר/אזור.

11) תוכניות אינטגרציה טיפוסיות

1. מקור שירות (צד כתיבה)

עסקה מקומית: domain record + outbox.
צרור, 'דלג נעול', גיבוי, גבולות לדייר.
ניטור lag 'now occurred_at'.

2. שירות-צרכן (צד-קריאה)

קריאת המנה כפול מנסה 'INSERT INBOX (צרכן, event_id)'.
באותה עסקה, אנו מתקנים את ה ”קיזוז המועבר” (אפשרות א ') או מסתמכים על העסקה של הברוקר (אפשרות ב').
שגיאה: מגש מחדש או DLQ לפי מדיניות.

3. הקרנה/תצוגה ממשית

רק עדכונים אידמפוטנטיים (upsert), מפתחות שכפול קומפקטיים, אימות צ 'קסום תקופתי.

12) תבניות הגדרות (דוגמה)

yaml producer:
idempotency_key: event_id partition_key: "{tenant_id}:{aggregate_id}"
retry:
max_attempts: 8 initial_ms: 200 max_ms: 8000 strategy: exponential_full_jitter

consumer:
batch: 500 offset_commit: "with_domain_tx"  # или "broker_tx"
inbox_enabled: true concurrency_per_partition: 4 dlq:
enabled: true batch_redrive: 200 rate_limit_per_sec: 50 order_by_key: true

observability:
metrics:
- processing_lag_ms
- publish_success_ratio
- dlq_rate
- redrive_success_ratio tracing_tags: [event_id, tenant_id, aggregate_id, partition, offset]

13) רשימת בדיקות לפני המכירה

[ ] בוטל ”שתי אותיות”: תיבה על המפיק או תיקון הקיזוז והתוצאה בעסקה אחת בצרכן.

[ ] צרכן אידמפוטנטי: ”תיבת דואר אלקטרוני ”/dedup journal, אידמפוטנטיות עסקית של מבצעים.

[ ] החלוקה לפי מפתח עסקי, הסדר המקומי מבוצע.

[ ] Backoff + jitter חוזר, סיווג שגיאות, metadata עשיר DLQ.

[ ] רדרייב מסומנת, בטוחה; יש ספרי שעשועים.

[ ] גבולות וסדרי עדיפויות; דייר _ id/תוכנית/תגי אזור.

[ ] Telemetry: lags, lace rate, ”duplicates docked”, התראות p95/p99.

[ ] מדיניות PII/שימור/הצפנה נאכפת.

[ ] בדיקות: טיפה בין שלבים, שכפולים, סדר מפתח, צלילה מחדש המונית.

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

שולח לאוטובוס וכותב לבסיס הנתונים בצעדים נפרדים ללא תיבת יציאה/פעולת קיזוז.
צרכן ללא אידמפוטנטיות * משכפל תופעות לוואי.
הסדר הכלל ־ עולמי ”יבוא אשר” יקר ולעיתים נדירות מוצדק; מספיק סדר לפי מפתח.
שרטוט מחדש מסיבי ללא גבולות. תקרית משנית.
חוסר איתור/lag metrics = ”השפלה נסתרת”.
תערובת PII ב DLQ/יומנים.

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

מאורעות SaaS: Outgregate + idempotent conservation (תיבת דואר אלקטרוני), המחולקת על ידי "terenant _ id: aggregate _ id'.
ETL/תחזיות: Read-process-write עם תיקון קיזוזים בעסקה אחת, חבורות 500-1000, Upsert.
עומס גבוה: פרסום רסיסים, 'דלג נעול', WFQ לדייר, בקרת פיגור.
אזור ציות מחמיר: תיבת חוץ אזורית, הצפנת מטען, שימור וביקורת של שיפוצים.

סיכום

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