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}'
- 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).
- 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.