ערבויות הזמנת הודעה

1) מהו ”סדר” ומדוע הוא נחוץ

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

2) סוגי ערבויות לסדר

1. לכל חילוק (סדר מקומי ביומן) - קפקא: הסדר בתוך המפלגה נשמר, בין המפלגות - לא.
2. Per-key (הזמנת קבוצת מפתח/מסרים) - כל ההודעות עם מפתח אחד מנותבות לתוך ”חוט” אחד של עיבוד (Kafka key, SQS FIFO Vassion GroupID, Pub/Sub ording key).
3. הסדר הכולל הגלובלי - המערכת כולה רואה סדר יחיד (journal/sequencer) מבוזר. יקר, משפיל זמינות ותפקוד.
4. סדר סיבתי - ”אירוע B אחרי A אם B צופה אפקט A” ניתן להשגה באמצעות metadata (גרסאות, Lamport-times/vector שעונים) ללא רצף גלובלי.
5. סדר המאמץ הטוב ביותר - הברוקר מנסה לשמור על הסדר, אבל במקרה של כשלים, פרמוטציות אפשריות (לרוב ב-NATS Core, RabbitMQ עם מספר צרכנים).

3) היכן שהסדר מתקלקל

DLQ/עיבוד מחדש - המסר ”הרעיל” עובר ל DLQ, הבאים הולכים רחוק יותר

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

4) עיצוב סדר מפתח

• השתמש במפתחות טבעיים: "order _ id'," arnet _ id', "aggregate _ id'.
• שימו לב ל ”מפתחות חמים” - מפתח אחד יכול ”לחסום” את הזרימה (חסימת ראש-קו). אם יש צורך, לפצל את המפתח: 'order _ id # shard (0.. k-1) "עם שחזור דטרמיניסטי של הסדר על הכיור.
• בקפקא - מפתח אחד = חלק אחד, הסדר יישמר בתוך המפתח.

java producer.send(new ProducerRecord<>("orders", orderId, eventBytes));

(מפתח = " Id' מבטיח סדר מקומי.)

5) ”סדר נגד רוחב פס”

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

פשרה: סדר לכל מפתח, מקביליות = מספר קבוצות/קבוצות, + חבורות אידמפוטנטיות.

6) שליטה על הסדר בברוקרים ספציפיים

קפקא

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

properties enable.idempotence=true acks=all retries=2147483647 max.in.flight.requests.per.connection=5

RabbitMQ (AMQP)

הסדר מובטח בתור אחד לצרכן אחד. עם מספר צרכנים של הודעות יכול לבוא ”מעורב”.
עבור סדר: צרכן אחד או קדם-אצבע = 1 + אק כאשר מסיימים. עבור תורים נפרדים באמצעות מפתחות (sharding changes/stable-hash change).

NATS/JetStream

ליבת NATS - המאמץ הטוב ביותר, איחור נמוך, סדר עלול להיות מופרע.
הזמנה בתוך זרם/רצף; במהלך הסידורים מחדש, סידור מחדש של הקונסולה אפשרי = = רצף שימוש וחוצץ התאוששות.

SQS FIFO

עיבוד חד פעמי (ביעילות, עקב שכפול) וסדר בתוך Message GroupID. קונקורנסי - מספר הקבוצות בתוך קבוצה ראש הקו.

Google Pub/Sub

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

7) דפוסים של שימור ושיקום הסדר

7. 1 רצף/וריאציות

• לוקח אירוע רק אם 'eq = last_seq + 1 ";
• אחרת - מכניס את חוצץ ההמתנה לפני ההגעה של חסר ('אחרון _ seq + 1').

pseudo if seq == last+1: apply(); last++
else if seq > last+1: buffer[seq] = ev else: skip // дубль/повтор

7. 2 באפרים וחלונות (עיבוד זרם)

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

7. 3 ניתוב דביק על ידי מפתח

החשיש (מפתח)% שברי ניתוב חשיש שולח את כל אירועי המפתח לעובד אחד.
ב ־ Kubernetes - לשמור על הפעלה (דביקה) ברמת התור/שרדים, ולא במאזן L4 HTTP.

7. 4 שחקן-מודל/” זרם אחד למפתח”

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

7. 5 אידמפוטנטיות + הזמנה מחדש

אפילו עם החזרת הסדר על כנו, חזרות אפשריות. צרף את UPSERT על ידי גרסת מפתח + ו ־ Inbox (ראה בדיוק-פעם אחת נגד לפחות-פעם אחת).

8) עבודה עם הודעות ”ארסיות” (גלולות רעל)

שמירת הסדר עומדת בפני המשימה: ”כיצד ניתן לחיות אם מסר אחד אינו מעובד?”

סדר קפדני: חסימת זרימת מפתח (SQS FIFO: קבוצה שלמה). הפתרון הוא על ידי מפתח DLQ: אנו מעבירים רק את מפתח הבעיה/קבוצה

סדר גמיש: אנו מאפשרים דילוג/פיצוי; אנו מתחברים וממשיכים (לא עבור אגרגטים פיננסיים/ביקורתיים).
מדיניות מגש: מוגבל ”max-deliver” + backoff + אפקטים אווידמפוטנטים.

9) ריבוי אזורים ומערכות גלובליות

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

10) יכולת תצפית של סדר

”out _ of _ order _ total”, ”reorded _ in _ window _ total”, ”late _ events _ total”, ”buffer _ size _ design”, ”חסום _ keys _ total”, ”fifo _ group _ backlog”.

11) אנטי דפוסים

תור אחד ועוד הרבה צרכנים בלי לדרוך על המפתח - ההזמנה מתקלקלת מיד.
רטריי דרך הציבור מחדש באותו תור ללא אידמפוטנציה - כפילים + מחוץ לסדר.
סדר ה ”ליתר ביטחון” הגלובלי הוא פיצוץ של איחוי וערך ללא תועלת אמיתית.
קבוצה אחת לכל ראשי השורות. השתמש ב ־ Sension GroupID לכל מפתח.
התעלמות מ ”מפתחות חמים” - ”ארנק” אחד מאט את הכל; לחלק את המפתח לתתי מפתחות היכן שאפשר.
ערבוב זרמים ביקורתיים ונפוצים באותו תור/קבוצה - השפעה הדדית ואובדן סדר.

12) רשימת מימושים

[ ] פר-מפתח/מחלקה/סיבתיות/גלובליות?

[ ] מפתח ריצוף ואסטרטגיית מפתח אנטי-חם תוכנן.

[ ] Router מוגדר: מחיצה/Message GroupID/הזמנת מפתח.

[ קונסולות ] מבודדות באמצעות מפתחות (דביקות-ניתוב, שברי-פועלים).

[ ] כלולים אידמפוטנטיות ו/או Inbox/UPSERT על חבורות.

[ ] יישום רצף/גרסה והזמנה מחדש של חוצץ (במקרה הצורך).

[ ] DLQ על ידי מדיניות מפתח ומגשים לאחור.

מחוץ לסדר, , סדר ומדדים התראה.

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

[ תיעוד ]: פקודות הזמנה, גבולות חלונות,

13) דוגמאות הגדרות

13. 1 קפקא צרכני (מזעור הפרות סדר)

properties max.poll.records=500 enable.auto.commit=false  # коммит после успешной обработки батча isolation.level=read_committed

13. 2 RabbitMQ (סדר לפי מחיר קונקורנסי)

צרכן אחד לכל תור + בסיסי. qos (פרפטץ = 1) "

bash rabbitmq-plugins enable rabbitmq_consistent_hash_exchange публикуем с хедером/ключом для консистентного хеша

13. 3 SQS FIFO

הגדרת Sension GroupID = מפתח. קונקורנסי = מספר קבוצות.
Sension DeduplicationID להגנה מפני כפילויות (בחלון הספק).

13. 4 NATS JetStream (צרכן מוזמן, סקיצה)

bash nats consumer add ORDERS ORD-KEY-42 --filter "orders.42.>" --deliver pull \
--ack explicit --max-deliver 6

מפתח> צג את 'רצף' והזמנה מחדש חוצץ ביישום.

14) FAQ

קיו: האם אני זקוק לסדר עולמי? ‏

א ': כמעט אף פעם. כמעט תמיד מספיק לכל מפתח. הסדר הגלובלי יקר ופוגע ברת-זמינות.

קיו: מה לגבי המסר ”הרעיל” בפקודה מפורשת?
א ': העבירו רק את המפתח/קבוצה שלו ל-DLQ, השאר - המשיכו.

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

ש: מה יותר חשוב: סדר או בדיוק פעם אחת?
A: עבור רוב התחומים - סדר מפתח + ביעילות בדיוק-פעם אפקטים (idempotency/UPSERT). תחבורה יכולה להיות לפחות פעם אחת.

15) סיכומים

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