GH GambleHub

Przepływy danych między węzłami

(Sekcja: Ekosystem i sieć)

1) Istota i cele

Przepływy danych między węzłami są zarządzanymi kanałami zdarzeń, stanów i artefaktów między rolami ekosystemu (walidatory/czytniki/indeksery/mosty/bramy/magazyny/analizy). Cele:
  • Przewidywalność: Stabilne SLO przez opóźnienie/sukces/świeżość.
  • Niezawodność: odporność na straty, duplikaty, reorgs.
  • Bezpieczeństwo i zgodność: szyfrowanie, podpisy, rezydencja.
  • Skalowalność: geo-dystrybucja, partycjonowanie, QoS.

2) Taksonomia przepływu

1. Control Plane: configs, phicheflags, routing/limit policies.
2. Płaszczyzna danych - zdarzenie: zdarzenia domeny ('deposit. „,” wypłata. „,” most. ').
3. Data Plane - strumień: długotrwałe strumienie (gRPC/WebSocket) sygnałów i żywych mierników.
4. Seria/Backfill: pliki do pobrania historycznych plasterków, powtórki, migawki.
5. Replikacja/anty-entropia: synchronizacja stanu, merklizacja, strumienie CRDT.
6. Telemetria/obserwowalność: kłody/mierniki/szlaki boczne, nie zakłócają głównego UX.

Każdy typ ma klasy QoS i własne reguły retrasy/zamówienia.

3) Topologie i routing

Hub-and-Speak: regionalne węzły jako opony; odgrywa - węzły ról.
Mesh/P2P: częściowa siatka do replikacji/plotek.
Krawędź-wielopoziomowe: cienkie bramy krawędzi (tempo-limit/cache) → grube klastry regionalne.
Geo-Routing: Anycast/Latency-Aware LB + zasady pobytu.

Klucz - partycjonowanie: 'partition _ key = Id' lokator 'topic' 'Id' daje przewidywalną kolejność i skalę.

4) Transport i formaty

HTTP/2/3, gRPC/QUIC - niskie opóźnienia, multipleksowanie, utrzymywanie przy życiu.
Kafka/Pulsar/NATS - kolejki z trwałością/partie/grupy konsumenckie.
WebSocket - forsować wydarzenia i żywe kanały.
Formaty: Protobuf/Avro (schematy z ewolucją), JSON dla zewnętrznych API.
Adresowanie hash i pokwitowania Merkle do weryfikacji integralności.

5) Zamówienie, dostawa i finalizacja

Model dostawy:
  • Przynajmniej raz (domyślnie; wymagana idempotencja/deadup).
  • Dokładnie raz efekt za pośrednictwem Outbox/Inbox + idempotent konsumenta.
  • Zamówienie: gwarantowane w ramach strony; zamówienie międzypartyjne nie jest gwarantowane.
  • Finalizacja: statusy „zaobserwowane → potwierdzone (K) → sfinalizowane → nieprawidłowe (reorg)”; dla optymizmu - okno sporu.

6) Idempotencja i dedup

Idempotencja klucz do wydarzeń:
  • „idempotence _ key = ${chainId}|${block}|${tx}|${logIndex}|${type}”
Zasady:
  • Upsert by key, TTL okna deduplikacji ≥ 72 godziny.
  • Dla konfliktu ładunek jest „źródłem prawdy” polityki (priorytet, wersja, podpis).
  • W przypadku żądań HTTP nagłówek to 'Idempotence-Key' + log odpowiedzi.

7) Kolejki, zwłoka i kwoty

Kolejki: strony według kluczy; DLQ dla „trujących” wiadomości.
Backpressure: credits/tokens, max-inflight limit, circuit-breaker.
Kontyngenty/QoS: P0 (krytyczny), P1 (produkt), P2 (luzem). Podział puli/limity RPS/bajty/s/subskrypcje.
Kontrola wjazdu: wcześniejsza odmowa „drogich” wniosków, ochrona wg zakresu/wielkości.

8) Spójność i modele danych

Czytaj-pisz w obrębie strony/węzła.
Ewentualna spójność między regionami/stronami.
CRDT do bezkompromisowej replikacji niektórych zestawów (liczniki, zestawy).
Migawki + dzienniki do szybkiego buta i odtwarzania deterministycznego.

9) Bezpieczeństwo i zaufanie

mTLS między węzłami, szpilki klucza, obrót.
Sygnatury wiadomości/webhook, znacznik czasu i okna anty-replay.
Szyfrowanie podczas jazdy/odpoczynku; segregacja kluczy regionalnych.
PII-minimalizacja: tokenizacja, zakaz danych osobowych w etykietach/metrykach.

10) Wydajność: pakowanie, kompresja, pamięć podręczna

Dozowanie: grupowanie małych wiadomości w celu zmniejszenia napowietrzności.
Kompresja: zstd/gzip z bezpiecznymi słownikami.
Gotówka: odpowiedzi negatywne i „gorące” katalogi; TTL i niepełnosprawność według zdarzeń.

11) Schematy danych (odniesienia)

Rejestr przepływu/partii

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)
);

Dziennik zdarzeń (idempotent upsert)

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/kwarantanna

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

12) Polityka (YAML)

QoS i limity

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

Finalizacja i okna

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

Routing/rezydencja

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

13) Obserwowalność: SLI/SLO

SLI (rdzeń):
  • Latency p95/p99 (ingress → egress, per-stream/QoS).
  • Wskaźnik sukcesu/spadek.
  • Kolejka Lag p95 i opóźnienie konsumenckie według partii.
  • Świeżość p95 (spożycie → spożycie).
  • Reorg/Invalid Rate (jeśli onchain).
  • Wydajność Dedup (% pobiera wchłaniane idempotently).
  • Współczynnik geo-hitu (lokalnie obsługiwany).
SLO (punkty orientacyjne):
  • P0 opóźnienie p95 ≤ 400 ms; Sukces ≥ 99. 95%; Kolejka-lag p95 ≤ 2 μ; Świeżość p95 ≤ 60 ".
  • Wydajność dedup ≥ 99%; DLQ ≤ 0. 1% ruchu.

Deski rozdzielcze: Streams Core/Lag & Freshness/QoS & Errors/Geo/Security (mTLS/signatures).

14) Wzorce konsumenckie

Skrzynka odbiorcza/skrzynka odbiorcza: publikacja atomowa i aplikacja idempotentna.
Dokładnie raz efekt: Przechowywać ostatni zastosowany klucz i wersję.
Znaki wodne: późne dane.
Idempotent Side-Effects: zewnętrzne zapytania z tylko kluczem i dziennikiem odpowiedzi.

15) Tryby degradacji

Tryb sfinalizowany: emitujemy tylko zakończone wydarzenia.
Cache-tylko dla książek referencyjnych, zamrażanie ciężkich metod.
Przepustnica P2 i „tryb diety” dla strumieni (zmniejszona szybkość odświeżania).
Tylko do odczytu wtórnych API.

16) Zwolnienia i migracje wolne od przestojów

Niebiesko-zielony/kanaryjski przez przepływy i konsumentów.
Schemat-pierwszy: dodawanie tylko pól; MAJOR - równoległe wersje tematów.
Migracja offsetowa: konsumenci cieni, porównywanie opóźnień/sukcesów, przełączanie.

17) Regulamin operacyjny

Codziennie: raport SLO (opóźnienie/sukces/lag/świeżość), audyt podpisu, kontrola DLQ.
Co tydzień: przegląd partii/kwot, test DR (bootstrap z migawki), analiza efektywności Dedup.
Miesięcznie: testy chaosu (utrata/jitter, awaria brokera, reorg-burst), przegląd okien końcowych.
Przed zwolnieniem: kanarka ≥ 120 min, bramy SLO, plan wsteczny.

18) Incydenty playbook

A. Wybuch kolejki-Lag/konsumenta-Lag

1. Zwiększenie liczby konsumentów/KEDA; 2) redystrybucji stron; 3) zamrożenie P2 i miejsc pracy masowej; 4) analiza „gorących” kluczy.

B. Wzrost p95 Latency P0

1. P2-throttle, priorytety P0; 2) skala bramek/maklerów; 3) pamięć podręczną wyłącznie do książek referencyjnych; 4) wytrysku zewnętrznego.

C. Wysoki DLQ/dubbing

1. Sprawdź klucz idempotencji/TTL; 2) wzmocnienie dedup; 3) ograniczyć hałaśliwego producenta; 4) powtórka po naprawie.

D. Systemy dryfowania/umowy

1. Włącz tryb ścisły (odciąć nieprawidłowe); 2) powiadamia producenta; 3) zwolnić adapter; 4) aktualizować lintery.

E. Naruszenie miejsca zamieszkania/podpisu

1. Jednostka eksportu/kanału; 2) obrót kluczy/sert; 3) audyt i pośmiertnie; 4) aktualizowanie polityki.

19) Lista kontrolna wdrażania

1. Zdefiniuj typy strumienia i klucz podziału.
2. Włącz idempotence/dedup i finalizację z oknami K/sporu.
3. Konfiguruj kolejki, QoS, kwoty i backpressure.
4. Uruchom mTLS/Podpisy i Zasady pobytu.
5. Wprowadź schematy/rejestry (strumienie, offsety, dlq) i telemetrię SLI/SLO.
6. Organizowanie migracji obwodów kanaryjskich/niebiesko-zielonych i bezterminowych.
7. Wypracuj tryby degradacji i playbooks incydentów.

20) Słownik

Backpressure - kontrola obciążenia wejściowego (credits/tokens/limits).
DLQ - „martwa kolejka” dla wiadomości problemowych.
CRDT - struktury danych z rozwiązywaniem konfliktów bez koordynacji.
Finalność - nieodwracalność zdarzenia/stanu.
Dokładnie raz efekt - powtarzać bezpieczny wynik przez co najmniej raz dostawy.
Znak wodny - Zaznaczyć postęp przetwarzania dla późnych wydarzeń.
Wyrzut zewnętrzny - wyłączenie zdegradowanych instancji z basenu.

Najważniejsze: przepływy danych między węzłami to nie tylko „kolejka i słuchacz”, ale systemowa dyscyplina porządku, finalizacji, idempotencji, bezpieczeństwa i obserwowalności. Standardowe klucze podziału, QoS/kwoty, ścisłe schematy i SLO, wraz z trybami degradacji i playbooks, dają ekosystemowi stabilne kanały transmisji danych w skali i pod kontrolą.

Contact

Skontaktuj się z nami

Napisz do nas w każdej sprawie — pytania, wsparcie, konsultacje.Zawsze jesteśmy gotowi pomóc!

Telegram
@Gamble_GC
Rozpocznij integrację

Email jest wymagany. Telegram lub WhatsApp są opcjonalne.

Twoje imię opcjonalne
Email opcjonalne
Temat opcjonalne
Wiadomość opcjonalne
Telegram opcjonalne
@
Jeśli podasz Telegram — odpowiemy także tam, oprócz emaila.
WhatsApp opcjonalne
Format: kod kraju i numer (np. +48XXXXXXXXX).

Klikając przycisk, wyrażasz zgodę na przetwarzanie swoich danych.