GH GambleHub

Fluxurile de date între noduri

(Secțiunea: Ecosistem și rețea)

1) Esență și obiective

Fluxurile de date între noduri sunt gestionate canale de evenimente, stări și artefacte între rolurile ecosistemului (validatori/cititori/indexatori/poduri/gateway-uri/stocări/analize). Obiective:
  • Predictibilitate: SLO-uri stabile prin întârziere/succes/prospețime.
  • Fiabilitate: rezistență la pierderi, duplicate, reorgs.
  • Securitate și conformitate: criptare, semnături, rezidență.
  • Scalabilitate: geo-distribuție, partiționare, QoS.

2) Taxonomia debitului

1. Plan de control: configurații, phicheflags, politici de rutare/limită.
2. Data Plane - eveniment: evenimente de domeniu ('depozit. „,” plata. „,” pod. ').
3. Data Plane - stream: fluxuri de lungă durată (gRPC/WebSocket) pentru semnale și metrici vii.
4. Batch/Backfill: descărcări de felii istorice, reluări, instantanee.
5. Replicare/anti-entropie: sincronizare de stat, merclization, fluxuri CRDT.
6. Telemetrie/observabilitate: busteni/metrici/trasee laterale, nu interferează cu UX principal.

Fiecare tip are clase QoS și propriile reguli de retray/ordine.

3) Topologii și rutare

Hub-and-Speak: hub-uri regionale ca anvelope; joacă - noduri de rol.
Mesh/P2P: plasă parțială pentru replicare/bârfă.
Edge-Tiered: gateway-uri cu margini subțiri (rate-limit/cache) → clustere regionale groase.
Geo-Routing: Reguli de rezidență Anycast/Latency-Aware LB +.

Cheie - partiționare: 'partition _ key = chainId' chiriaș' topic 'entityId' oferă ordine și scară previzibile.

4) Transport și formate

HTTP/2/3, gRPC/QUIC - latență scăzută, multiplexare, keepalive.
Kafka/Pulsar/NATS - cozi cu grupuri de persistență/părți/consumatori.
WebSocket - evenimente push și feed-uri live.
Formate: Protobuf/Avro (scheme cu evoluție), JSON pentru API-uri externe.
Adresarea hash și chitanțele Merkle pentru verificarea integrității.

5) Comandă, livrare și finalizare

Model de livrare:
  • Cel puțin o dată (implicit; idempotency/deadup necesar).
  • Efect exact o dată prin Outbox/Inbox + consumator idempotent.
  • Comanda: garantata in cadrul partii; comanda inter-party nu este garantată.
  • Finalizare: statusuri „observate → confirmate (K) → finalizate → nevalide (reorg)”; pentru optimist - fereastra de dispute.

6) Idempotence și dedup

Cheia Idempotence pentru evenimente:
  • 'idempotency _ key = ${chainId}|${block}|${tx}|${logIndex}|${type}'
Reguli:
  • Upsert după cheie, TTL a ferestrei de eliminare a duplicatelor ≥ 72 de ore.
  • Pentru un conflict, sarcina utilă este politica „sursa adevărului” (prioritate, versiune, semnătură).
  • Pentru solicitările HTTP, antetul este „Idempotency-Key” + jurnal de răspuns.

7) Cozi, backpressure și cote

Cozi: petreceri la cheie; DLQ pentru mesaje „otrăvitoare”.
Backpressure: credite/jetoane, limita max-inflight, circuit-breaker.
Cote/QoS: P0 (critic), P1 (produs), P2 (în vrac). Split piscine/limite SPR/octeți/s/abonamente.
Controlul admiterii: refuzul timpuriu al cererilor „scumpe”, paza în funcție de interval/dimensiune.

8) Modele de coerență și date

Citiți-vă-scrieți în cadrul partidului/nodului.
Eventuala coerență între regiuni/părți.
CRDT pentru replicarea fără conflicte a unor seturi (contoare, seturi).
Instantanee + jurnale pentru bootstrap rapid și reluarea deterministă.

9) Securitate și încredere

mTLS între noduri, fixare cheie, rotație.
Semnături mesaj/webhook, timestamp și ferestre anti-reluare.
Criptare în mers/în repaus; segregarea cheilor regionale.
PII-minimizare: tokenizare, interzicerea datelor cu caracter personal în etichete/metrici.

10) Eficiență: ambalare, compresie, memorie cache

Batching: gruparea mesajelor mici pentru a reduce deasupra capului.
Compresie: zstd/gzip cu dicționare sigure.
Cash: răspunsuri negative și directoare „fierbinți”; TTL și handicap în funcție de eveniment.

11) Diagrame de date (referințe)

Registru flux/lot

sql
CREATE TABLE streams (
name TEXT PRIMARY KEY,
partitions INT,
qos TEXT,        -- P0    P1    P2 retention_days INT,
schema_version TEXT
);

CREATE TABLE offsets (
stream TEXT, partition INT, consumer_group TEXT,
offset BIGINT, updated_at TIMESTAMPTZ,
PRIMARY KEY (stream, partition, consumer_group)
);

Jurnal de evenimente (upsert idempotent)

sql
CREATE TABLE events_core (
id UUID PRIMARY KEY,
idempotency_key TEXT UNIQUE,
ts TIMESTAMPTZ,
partition_key TEXT,
type TEXT,
payload JSONB,
status TEXT,      -- observed    confirmed    finalized    invalidated signature TEXT
);

DLQ/Carantină

sql
CREATE TABLE dlq (
id UUID PRIMARY KEY,
stream TEXT, partition INT, offset BIGINT,
reason TEXT, payload JSONB, ts TIMESTAMPTZ
);

12) Politici (YAML)

QoS și limite

yaml qos:
P0: { ack_timeout_ms: 2000, retries: 3, backoff_ms: [100,400,800], rps_per_org: 1500 }
P1: { ack_timeout_ms: 5000, retries: 2, rps_per_org: 800 }
P2: { best_effort: true, rps_per_org: 200 }
limits:
max_message_bytes: 1048576 max_stream_subscriptions_per_client: 20

Finalizare si ferestre

yaml finality:
eth-mainnet: { k: 12 }
polygon:   { k: 256 }
optimistic: { k: 0, challenge_minutes: 20 }

Rutare/Rezidență

yaml routing:
prefer_local_region: true fallback: [nearest_healthy, master_hub]
residency:
eu: ["eu"]
uk: ["uk"]

13) Observabilitate: SLI/SLO

SLI (nucleu):
  • Latență p95/p99 (ingress→egress, per-stream/QoS).
  • Rata de succes/Rata de scădere.
  • Coada Lag p95 și lag de consum de partid.
  • Prospețime p95 (ingest→consume).
  • Reorg/Invalid Rate (în cazul în care onchain).
  • Dedup Eficiență (% din ia absorbit idempotent).
  • Geo-Hit Ratio (service local).
SLO (repere):
  • P0 latență p95 ≤ 400 ms; Succes ≥ 99. 95%; Coadă-lag p95 ≤ 2 с; Prospețime p95 ≤ 60 с.
  • Eficiența dedupului ≥ de 99%; DLQ ≤ 0. 1% din trafic.

Tablouri de bord: Fluxuri Core/Lag & Prospețime/QoS & Erori/Geo/Securitate (mTLS/semnături).

14) Modele de consum

Outbox/Inbox: publicarea atomică și aplicarea idempotentă.
Efect exact o dată: Stocați ultima cheie aplicată și versiunea.
Filigrane: date târzii.
Efecte secundare Idempotent: interogări externe cu doar cheie și jurnal de răspuns.

15) Moduri de degradare

Modul finalizat: emitem doar evenimente finalizate.
Cache-numai pentru cărțile de referință, înghețarea metodelor grele.
Accelerația P2 și „modul dietetic” pentru fluxuri (rata redusă de reîmprospătare).
Numai pentru API-uri secundare.

16) Downtime-free versiuni și migrații

Albastru-verde/canar de fluxuri și consumatori.
Schema-first: adăugați câmpuri numai; MAJOR - versiuni paralele ale subiectelor.
Migrații compensate: consumatori umbriți, comparație întârziere/succes, comutare.

17) Regulamentele de funcționare

Zilnic: raport SLO (latență/succes/lag/prospețime), audit de semnături, verificare DLQ.
Săptămânal: revizuirea loturilor/cotelor, testul DR (bootstrap din instantaneu), analiza Dedup Efficiency.
Lunar: teste de haos (pierdere/jitter, eșec broker, reorg-explozie), revizuirea ferestrelor de finalitate.
Înainte de lansare: canar ≥120 min, porți SLO, plan rollback.

18) Incidente Playbook

A. Explozie de tip Queue-Lag/Consumer-Lag

1. Creșterea consumatorilor/KEDA; 2) redistribuie părțile; 3) congela P2 și locuri de muncă în vrac; 4) analiza cheilor „fierbinți”.

B. Creșterea latenței p95 P0

1. P2-throttle, prioritizarea P0; 2) gateway-uri/brokeri de scară; 3) memoria cache numai pentru cărțile de referință; 4) outlier-ejection.

C. DLQ ridicat/dublare

1. Verificați cheia de idempotență/TTL; 2) consolidarea dedupului; 3) limitează producătorul zgomotos; 4) reluare după remediere.

D. Drift scheme/contracte

1. Activați modul strict (tăiați cele nevalide); 2) notifică producătorul; 3) eliberarea adaptorului; 4) actualizați lintere.

E. Încălcarea rezidenței/semnăturilor

1. Unitate de export/canal; 2) rotația cheilor/serturilor; 3) audit și post-mortem; 4) actualizarea politicilor.

19) Lista de verificare a implementării

1. Definiți tipurile de flux și tasta de partiționare.
2. Activați idempotența/dedupul și finalizarea cu ferestrele K/dispută.
3. Configurați cozi, QoS, cote și backpressure.
4. Run mTLS/Semnături și Politica de rezidență.
5. Introduceți scheme/registre (fluxuri, compensări, dlq) și telemetrie SLI/SLO.
6. Organiza canare/albastru-verde şi downtime-free circuit migraţii.
7. Elaborați moduri de degradare și cărți de redare incidente.

20) Glosar

Backpressure - controlul sarcinii de intrare (credite/jetoane/limite).
DLQ - „coadă moartă” pentru mesajele cu probleme.
CRDT - structuri de date cu rezolvarea conflictelor fără coordonare.
Finalitate - ireversibilitatea evenimentului/stării.
Efect exact o dată - rezultat repetat-sigur peste cel puțin o dată de livrare.
Filigran - Marcați progresul procesării pentru evenimentele târzii.
Outlier-ejection - excluderea instanțelor degradate din rezervă.

Linia de fund: fluxurile de date între noduri nu sunt doar o „coadă și ascultător”, ci o disciplină sistemică de ordine, finalizare, idempotență, securitate și observabilitate. Cheile standard de partiționare, QoS/cote, schemele stricte și SLO-urile, împreună cu modurile de degradare și cărțile de redare, oferă ecosistemului canale stabile de transmisie a datelor la scară și sub audit.

Contact

Contactați-ne

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

Telegram
@Gamble_GC
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ă.