GH GambleHub

זרמי רשת ואירועים

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.
ספסל SLO:
  • הקמת 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. אז הנחלים נשארים מהירים עבור המשתמש וניתנים לטיפול עבור הפלטפורמה - ללא פשרות על ביטחון וכסף.

Contact

צרו קשר

פנו אלינו בכל שאלה או צורך בתמיכה.אנחנו תמיד כאן כדי לעזור.

התחלת אינטגרציה

Email הוא חובה. Telegram או WhatsApp — אופציונליים.

השם שלכם לא חובה
Email לא חובה
נושא לא חובה
הודעה לא חובה
Telegram לא חובה
@
אם תציינו Telegram — נענה גם שם, בנוסף ל-Email.
WhatsApp לא חובה
פורמט: קידומת מדינה ומספר (לדוגמה, +972XXXXXXXXX).

בלחיצה על הכפתור אתם מסכימים לעיבוד הנתונים שלכם.