GH GambleHub

Fluxuri și evenimente WebSocket

TL; DR

Flux de lucru = canal de încredere (WSS) + compensări rezumate + evenimente idempotente + limite stricte și backpressure. Do: autentificare JWT, autorizație pentru subiecte, bătăi de inimă, seq/offset + CV-token, cel puțin o dată + deadup. Pentru scară - sharding utilizator/chiriaș, rutare lipicioasă și coadă (Kafka/NATS/Redis Streams) ca sursă de adevăr.

1) iGaming cazuri de afaceri (ceea ce am flux cu adevărat)

Echilibru/limite: modificări instantanee ale echilibrului, limite RG, încuietori.
Pariuri/runde/rezultate: confirmare, stare, calculul câștigurilor.
Turnee/clasamente: poziții, cronometre, evenimente premiu.
Plăți: stare de plată/rambursare, steaguri KYC/AML - precum notificări (iar critica rămâne în jurnalele web REST +).
Evenimente de serviciu: mesaje de chat, bannere push, stări de sesiune, întreținere.

2) Protocol și conexiune

Numai WSS (TLS 1. 2+/1. 3). Maxim 1 conexiune activă per dispozitiv/sesiune implicită.
Ping/Pong: clientul trimite 'ping' every 20-30 secunde, timpul de răspuns este de 10 secunde. Serverul scade conexiunea la 3 intervale de timp consecutive.
Compresie: „permessage-deflate”, limita dimensiunii cadrului (de exemplu, ≤ 64 KB).
Format sarcină utilă: JSON pentru extern, Protobuf/MsgPack pentru intern/mobil.

3) Autentificare și autorizare

JWT strângere de mână în interogare/antet („Sec-WebSocket-Protocol ”/„ Autorizare”), TTL token scurt (≤ 15 min), reîmprospătare prin out-of-band (REST).
Creanțe legate de chiriași: "sub", "chiriaș", "scopes", "risk _ flags'.
ACL-uri la subiecte/canale: abonarea numai la 'subiecte' permise (de exemplu: 'utilizator: {id}', 'turneu: {id}', 'joc: {table}').
Re-crearea conexiunii atunci când jetonul expiră: „fereastră moale” 60 s.

4) Model de abonament

Clientul trimite comenzi după conectare:
json
{ "op":"subscribe", "topics":["user:123", "tournament:456"], "resume_from":"1748852201:987654" }
{ "op":"unsubscribe", "topics":["tournament:456"] }

'CV _ from' - offset (vezi § 5) dacă clientul se reconectează.
Serverul răspunde cu ack nack, ACL-urile eșuate sunt în 'nack' cu 'reason'.

5) Garanții de livrare și rezumat

Scop: cel puțin o dată pe canal + idempotență în client.

Fiecare eveniment are un monoton „seq” în „parte” (de obicei utilizator/cameră) și un eveniment global _ id' pentru deduplicare.
Cu o re-conexiune, clientul trimite 'cv _ from' = ultimul 'seq' confirmat (sau 'offset' al brokerului). Serverul încarcă evenimentele ratate din „sursa adevărului” (Kafka NATS Redis Streams).
Dacă decalajul depășește reținerea (de exemplu, 24 de ore), serverul trimite un „instantaneu” al stării și un nou „seq”.

Semantica clientului:
  • Store 'last _ seq '/' event _ id' in storage durabil (IndexedDB/Keychain).
  • Dedup prin 'event _ id', sari peste evenimente cu' seq ≤ last_seq', detecta găuri (gap) → auto-' resync' cerere instantaneu.

6) Schema de mesaje (plic)

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' - taxonomia domeniului (vezi dicţionarul evenimentului).
PII/PCI - excludeți/mască la nivelul gateway-ului.

7) Backpressure, cote și protecție împotriva clienților „scumpe”

Server → Client: per conexiune trimite-coadă cu fereastră glisantă. Full - resetarea abonamentelor la subiecte „zgomotoase” sau deconectarea cu codul „1013 ”/„ policy _ violation”.
Client → Server: limitează 'subscribe/unsubscribe' (de exemplu, ≤ 10/sec), limita listei de subiecte (≤ 50), intervalul minim de retrimitere.
Limitele ratei prin IP/chiriaș/cheie. Anomalii → blocare temporară.
Prioritate: evenimente vitale (echilibru, limite RG) - coadă de prioritate.

8) Protecție și siguranță

Profilul WAF/bot pe punctul final de strângere de mână, Lista de origine permisă.
mTLS între gateway-ul de margine și nodurile de flux.
Protecție DoS: cookie-uri SYN pe L4, limite privind numărul de WS deschise/păstrați-vii interval.
Anti-reluare: „timestamp” în semnătura opțională a sarcinii utile (pentru parteneri) cu o fereastră validă de 5 min.
Izolarea chiriașilor: sharding fizic/logic, chei/jetoane per chiriaș.

9) Arhitectura de transport

Gateway (margine): terminal TLS, authN/Z, cote, rutare per parte.
Noduri de flux: lucrătorii apatrizi cu rutare lipicioasă prin „hash (user_id)% N”.
Broker de evenimente: Kafka/NATS/Redis Streams - sursa adevărului și a tamponului de reluare.
State-service: stochează instantanee (echilibru, poziții în turneu).
Multiregie: activ-activ; GSLB după regiunea cea mai apropiată; acasă-regiune este fixat la autentificare; cu un feiler - un rezumat „rece” din altă regiune.

10) Ordine, consecvență, idempotență

Comanda este garantată în cadrul părții (utilizator/cameră), nu la nivel global.
Consecvență: evenimentul poate veni înainte de răspunsul REST; UX trebuie să fie capabil să trăiască cu o stare intermediară (UI optimist + reconciliere).
Idempotence: reprocesarea 'event _ id' nu schimbă starea clientului.

11) Erori, reconectare și furtuni

Coduri de închidere: „1000” (normal), „1008” (politică), „1011” (intern), „1013” (supraîncărcare server).
Backoff exponențial client + jitter: 1s, 2s, 4s... max 30 de ani.
În timpul reconectărilor în masă ("turmă tunătoare") - serverul oferă răspunsuri "retry _ after 'și" gri "cu promptitudinea de a utiliza rezerva SSE numai pentru citire.

12) Numerar și instantanee

Fiecare abonament poate începe cu un instantaneu al stării curente, apoi un flux de evenimente diff.
Versionarea și compatibilitatea schemei data _ version (extensia câmpului nu rupe clienții).

13) Observabilitate și SLO

Măsurători:
  • Conexiuni: activ, stabilit/sec, distributie pe chirias/regiune.
  • Livrare: p50/p95 întârzieri de la broker la client, drop-rate, resend-rate.
  • Fiabilitate: cota de CV-uri de succes fără un instantaneu, detector de decalaj.
  • Erori: 4xx/5xx la strângerea de mână, închiderea codurilor, limitarea loviturilor.
  • Încărcare: RPS de „abonare” comenzi, coadă dimensiune, CPU/NET.
Criterii de referință SLO:
  • Stabilirea WS p95 ≤ 500 ms (în cadrul regiunii).
  • Eveniment de latență end-to-end p95 ≤ 300 ms (partiție utilizator).
  • Reluați succesul ≥ 99%, pierderea mesajului = 0 (по cel puțin o dată).
  • Uptime Stream Endpoint ≥ 99. 95%.

14) Schema și managementul versiunii

Dicționar de evenimente cu proprietari, exemple și semantică.
Evoluția "soft': doar adăugarea de câmpuri opționale; ștergere - după perioada „@ depreciat”.
Teste de contract împotriva SDK-urilor client, lintere pe JSON Schema/Protobuf.

15) Playbook-uri incidente (încorporați în playbook-ul partajat)

Creșterea latenței: trecerea părților la nodurile de rezervă, creșterea dimensiunii lotului la broker, permiterea prioritizării evenimentelor vitale.
Reconectați furtuna: activați 'retry _ after', ridicați temporar limitele strângerii de mână, activați rezerva SSE.
Scurgere de token: rotație JWKS, revocarea jetoanelor afectate, reconectarea forțată cu re-auth.
Pierderea de partid broker: transfer la modul instantaneu, reluare după recuperare.

16) API Mini Specificaţie (simplificată)

Strângere de mână (HTTP GET → WS):

GET /ws? tenant=acme&client=web
Headers:
Authorization: Bearer <JWT>
X-Trace-Id: <uuid>
Comenzi client:
json
{ "op":"subscribe",  "topics":["user:123"], "resume_from":"1748852201:42" }
{ "op":"unsubscribe", "topics":["user:123"] }
{ "op":"ping", "ts":"2025-11-03T12:34:56Z" }
Răspunsurile serverului:
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) Lista de verificare UAT

  • Rezumat din offset după 1/10/60 minute de nefuncționare a clientului.
  • Dedup: redelivery of the same 'event _ id' nu schimbă starea.
  • Detector de decalaj → „instantaneu” automat și aliniere.
  • Cote și backpressure: clientul încărcat primește politica de deconectare.
  • Multiregion: failover regiune menținând în același timp offset.
  • Securitate: Token rocker expirat de JWT, încercând să se aboneze în afara ACL.
  • RG/eveniment balance comes before/after REST - UI corect „cusături”.

18) Erori frecvente

Nu există 'seq/offset' și reînnoire - pierdeți evenimente și încredere.
Amestecarea comenzilor de plată critice în mutațiile WS - utilizați REST.
Lipsa de backpressure/cote - conexiuni „suspendate” și o avalanșă de memorie.
Ordinea globală este costisitoare și inutilă; destul de ordine în partid.
PII logare în evenimente - încălcări ale confidențialității și PCI/GDPR.
Lipsa unui dicționar de evenimente și versiuni - clienții se descompun.

Rezumat

Fluxurile WebSocket dau semnale reactive UX și operaționale dacă sunt construite ca un canal rezumat, protejat și limitat: WSS + mTLS/JWT, ACL pe subiecte, seq/offset + CV, cel puțin o dată cu eliminarea duplicatelor, backpressure/cotes, broker ca sursă de adevăr, observabilitate și SLO. Deci, fluxurile rămân rapide pentru utilizator și ușor de gestionat pentru platformă - fără compromisuri privind securitatea și banii.

Contact

Contactați-ne

Scrieți-ne pentru orice întrebare sau solicitare de suport.Suntem mereu gata să ajutăm!

Pornește integrarea

Email-ul este obligatoriu. Telegram sau WhatsApp sunt opționale.

Numele dumneavoastră opțional
Email opțional
Subiect opțional
Mesaj opțional
Telegram opțional
@
Dacă indicați Telegram — vă vom răspunde și acolo, pe lângă Email.
WhatsApp opțional
Format: cod de țară și număr (de exemplu, +40XXXXXXXXX).

Apăsând butonul, sunteți de acord cu prelucrarea datelor dumneavoastră.