זרמי רשת ואירועים
TL; DR
זרם עבודה = ערוץ אמין (WSS) + סיכום קיזוזים + אירועים אידמפוטנטיים + מגבלות קפדניות ותיקי גב. דו: אימות JWT, אישור לנושאים, פעימות לב, seq/offset + reson-token, לפחות פעם אחת + deadup. לקנה מידה - דייר/משתמש, ניתוב דביק ותור (Kafka/NATS/Redis Streams) כמקור לאמת.
1) תיקים עסקיים של iGaming (מה שאנחנו באמת מזרימים)
איזון/גבולות: שינויים מיידיים במאזן, גבולות RG, מנעולים.
הימורים/סיבובים/תוצאות: אישור, מצב, חישוב של זכיות.
טורנירים/לוחות מובילים: עמדות, טיימרים, אירועי פרס.
תשלומים: מצב תשלום/החזר, דגלי KYC/AML - כמו הודעות (והביקורת נשארת ב-REST + webhooks).
אירועי שירות: הודעות צ 'אט, כרזות דחיפה, סטטוסים הפעלה, תחזוקה.
2) פרוטוקול וחיבור
WSS בלבד (TLS 1. 2+/1. 3). מקסימום של 1 חיבור פעיל לכל התקן/הפעלה ברירת מחדל.
פינג/פונג: הלקוח שולח 'פינג' מאוד 20-30 שניות, זמן התגובה הוא 10 שניות. השרת מפיל את החיבור ב-3 פסקי זמן רצופים.
דחיסה: ”permessage-deflate”, הגבלת גודל מסגרת (לדוגמה, 64 KB).
פורמט Payload: JSON לחיצוני, Protobuf/MsgPack עבור פנימי/נייד.
3) אימות ואישור
לחיצת יד ב-JWT ב-shary/header ('Sec-WebSocket-Protocol '/' Authorization'), TTL token קצר (15 דקות), רענון על ידי out-of-band (Rest).
טענותיו של הדייר: ”תת”, ”דייר”, ”סקופים”, ”סיכון _ דגלים”.
ACLs לנושאים/ערוצים: מנוי רק ל ”נושאים מותרים” (לדוגמה: ”משתמש:”, ”טורניר:” (id'), ”משחק: [שולחן]”.
חיבור מחדש יצירה כאשר האסימון פג: ”חלון רך” 60 s.
4) מודל מנוי
הלקוח שולח פקודות לאחר ההתחברות:json
{ "op":"subscribe", "topics":["user:123", "tournament:456"], "resume_from":"1748852201:987654" }
{ "op":"unsubscribe", "topics":["tournament:456"] }
'resume _ from' - offset (ראה § 5) אם הלקוח מתחבר מחדש.
השרת מגיב עם אק/נאק, האזיקים הכושלים נמצאים ב 'נאק' עם 'ריסון'.
5) ערבויות משלוח וסיכום
מטרה: לפחות פעם אחת לכל ערוץ + אידמפוטנטיות אצל הלקוח.
לכל אירוע יש "seq 'within" מונוטוני (בדרך כלל משתמש/חדר) ו "event _ id' global עבור dauplication.
עם חיבור מחדש, הלקוח שולח "reson _ from' = האחרון אשר 'seq' (או 'offset' של הברוקר). השרת מעמיס אירועים שלא נענו מתוך ”מקור האמת” (Kafka/NATS/Redis Streams).
אם הפיגור עולה על השימור (לדוגמה, 24 שעות), השרת שולח ”תצלום” של המדינה ו ”seq” חדש.
- אחסון עמיד (IndexedDB/Keychain).
- Dedup by "event _ id', לדלג על אירועים עם 'seq mall last_seq', לזהות חורים (gap) * auto-' resync' snopshot בקשה.
6) ערכת מסרים (מעטפה)
json
{
"ts": "2025-11-03T12:34:56. 789Z",
"topic": "user:123",
"seq": "1748852201:987654", // partition:offset
"event_id": "01HF..", // UUID/KSUID
"type": "balance. updated",
"data": { "currency":"EUR", "delta"--5. 00, "balance":125. 37 },
"trace_id": "4e3f.., "//for correlation
"signature": "base64 (hmac (...)) "//optional for partners
}
'Type' - טקסונומיה תחום (ראה מילון אירוע).
PII/PCI - לא כולל/מסכה ברמת השער.
7) כיסוי גב, מכסות והגנה מפני לקוחות ”יקרים”
Server Ac.Client: per-connection send-sweet עם חלון הזזה. איפוס מלא של מנויים לנושאים ”רועשים” או ניתוק עם קוד ”1013 ”/” מדיניות _ הפרה”.
שרת לקוח: מגבלות על 'subscribe/unsubscribe' (לדוגמה, סימון 10/sec), הגבלת רשימת נושאים (mall 50), מרווח חידוש מינימלי.
דרג גבולות על ידי IP/דייר/מפתח. חריגות = חסימה זמנית.
עדיפות: אירועים חיוניים (איזון, RG-limits) - תור עדיפות.
8) הגנה ובטיחות
פרופיל WAF/BOT בלחיצת יד, רשימה מותרת.
MTLS בין שער קצה וצמתים זרם.
הגנת DOS: עוגיות SYN על L4, מגבלות על מספר מרווח WS/לשמור-בחיים פתוח.
אנטי-שידור חוזר: ”חותמת זמן” בחתימת מטען אופציונלית (לשותפים) עם חלון תקף של 5 דקות.
בידוד דייר: חוד פיזי/לוגי, מפתחות/אסימונים לדייר.
9) ארכיטקטורת תחבורה
שער (קצה): מסוף TLS, AuthN/Z, מכסות, ניתוב לכל צד.
צמתים זרם: עובדים חסרי מעמד עם ניתוב דביק על ידי 'חשיש (user_id)% N'.
מתווך אירועים: Kafka/NATS/Redis Streams - מקור האמת וחוצץ מחדש.
שירות המדינה: צילומי חנויות (איזון, עמדות בטורניר).
אזור מרובה: נכס נכס; GSLB לפי האזור הקרוב ביותר; אזור הבית קבוע בעת ההתחברות; עם מסווה - סיכום ”קר” מאזור אחר.
10) סדר, עקביות, אידמפוטנטיות
הזמנה מובטחת בתוך המפלגה (משתמש/חדר), לא באופן גלובלי.
עקביות: האירוע עשוי לבוא לפני תגובת ה-REST; UX חייב להיות מסוגל לחיות עם מצב ביניים (אופטימי UI + פיוס).
idempotence: עיבוד מחדש של "event _ id' לא משנה את מצב הלקוח.
11) שגיאות, חיבור מחדש וסערות
קודי סגירה: ”1000” (נורמלי), ”1008” (מדיניות), ”1011” (פנימי), ”1013” (עומס יתר שרת).
גיבוי מעריכי ללקוח + ג 'יטר: 1, 2, 4... מקסימום שנות ה -30.
במהלך חיבור המסה ("Runding Herd') - השרת נותן תגובות" retry _ after "ו-" gray "עם קדימון לשימוש ב-SSE Fallback לקריאה בלבד.
12) מזומנים ותמונות
כל מנוי יכול להתחיל עם תמונה של המצב הנוכחי, ואז זרם של אירועים שונים.
סכימת Data _ version versioning ותאימות (סיומת שדה אינה מפרקת לקוחות).
13) יכולת תצפית ו ־ SLO
מדדים:- חיבורים: פעיל, מבוסס/שנייה, הפצה על ידי דייר/אזור.
- משלוח: p50/p95 עיכובים מברוקר ללקוח, קצב ירידה, קצב מחדש.
- אמינות: נתח של קורות חיים מוצלחים ללא צילום, גלאי פערים.
- שגיאות: 4xx/5xx בלחיצת יד, סגירת קודים, הגבלת פגיעות.
- טען: RPS של פקודות ”מנוי”, גודל תור, מעבד/NET.
- הקמת WS p95 ms 500 (בתוך האזור).
- אירוע איחור מקצה לקצה p95 בלום 300 ms (מחיצת משתמש).
- המשך הצלחה ב-99%, אובדן הודעה = 0 (לפחות פעם אחת).
- מעלה זרם אנדפוינט 99. 95%.
14) סכימה וניהול גרסאות
מילון אירועים עם בעלים, דוגמאות וסמנטיקה.
אבולוציה ”רכה”: רק הוספת שדות אופציונליים; מחיקה - אחרי תקופת ”@ disrated”.
מבחני חוזה מול לקוח SDKs, מקשים על JSON Schema/Protobuf.
15) חוברות משחק תקריות (משובצות בספר המהלכים המשותף שלך)
גדילה: לעבור צדדים לצמתים גיבוי, להגדיל את גודל המנה בברוקר, לאפשר עדיפות של אירועים חיוניים.
התחבר מחדש לסערה: הפעל את ”retry _ after”, העלה זמנית את מגבלות לחיצת היד, אפשר נסיגה של SSE.
דליפת טוקן: סיבוב JWKS, שלילת אסימונים מושפעים,
אובדן מסיבת ברוקרים: העברה למצב צילום, שידור חוזר לאחר ההתאוששות.
16) מפרט מיני API (מפושט)
לחיצת יד (HTTP GET # WS):
GET /ws? tenant=acme&client=web
Headers:
Authorization: Bearer <JWT>
X-Trace-Id: <uuid>
פקודות הלקוח:
json
{ "op":"subscribe", "topics":["user:123"], "resume_from":"1748852201:42" }
{ "op":"unsubscribe", "topics":["user:123"] }
{ "op":"ping", "ts":"2025-11-03T12:34:56Z" }
תגובות שרת:
json
{ "op":"ack", "id":"subscribe:user:123" }
{ "op":"event", "topic":"user:123", "seq":"1748852201:43", "type":"balance. updated", "data":{...} }
{ "op":"snapshot", "topic":"user:123", "seq":"1748852201:42", "state":{...} }
{ "op":"error", "code":"acl_denied", "reason":"no access to topic tournament:456" }
{ "op":"pong", "ts":"..." }
17) רשימת בדיקות UAT
[ ] תקציר מהקיזוז לאחר 1/10/60 דקות של השבתה של הלקוח.
[ ] דדאפ: האריכות המחודשת של אותו "אירוע _ id' לא משנה את המצב.
[ ] Gap Gallector * אוטומטי ”צילום” ויישור.
[ ] מכסות ותרמיל גב: הלקוח הטעון מקבל ניתוק מדיניות.
[ ריבוי ]: אזור כשל תוך שמירה על קיזוז.
[ ] אבטחה: Token rocker פג תוקף על ידי JWT,
[ ] אר ג 'י/איזון אירועים בא לפני/אחרי מנוחה - ”תפרים” נכון.
18) שגיאות תכופות
אין ”סק/קיזוז” וחידוש - לאבד אירועים ואמון.
ערבוב פקודות תשלום קריטיות במוטציות WS - להשתמש במנוחה.
חוסר בתרמיל גב/מכסות - קשרים ”מושעים” ומפולת של זיכרון.
סדר עולמי יקר ומיותר; מספיק סדר במסיבה.
רישום אירועים: הפרות פרטיות ו-PCI/GDPR.
היעדר מילון אירועים ואירועים - לקוחות נשברים.
תקציר
זרמי WebSocket נותנים אותות ריאקטיביים UX ותפעוליים אם הם בנויים כערוץ מסכם, מוגן ומוגבל: WSS + mTLS/JWT, ACL על נושאים, seq/offset + resease, לפחות פעם אחת עם dauplication, backpreser כמקור יכולת תצפית ו-SLO. אז הנחלים נשארים מהירים עבור המשתמש וניתנים לטיפול עבור הפלטפורמה - ללא פשרות על ביטחון וכסף.