جریان داده ها بین گره ها

(بخش: اکوسیستم و شبکه)

1) جوهر و اهداف

• قابلیت پیش بینی: SLO های پایدار با تاخیر/موفقیت/طراوت.
• قابلیت اطمینان: مقاومت در برابر تلفات، تکراری، reorgs.
• امنیت و انطباق: رمزگذاری، امضا، اقامت.
• مقیاس پذیری: توزیع جغرافیایی، پارتیشن بندی، QoS.

2) طبقه بندی جریان

1. کنترل هواپیما: پیکربندی ها، phicheflags، مسیریابی/سیاست های محدود.
2. داده هواپیما - رویداد: رویدادهای دامنه ("سپرده. '، پرداخت. '،' پل. ').
3. Data Plane - stream: جریانهای طولانی مدت (gRPC/WebSocket) برای سیگنال ها و معیارهای زنده.
4. دسته/Backfill: دانلود برش های تاریخی، تکرار، عکس های فوری.
5. تکرار/ضد آنتروپی: همگام سازی حالت، merclization، جریان CRDT.
6. Telemetry/observability: logs/metrics/trails side-band، با UX اصلی تداخل ندارد.

هر نوع کلاس QoS و قوانین retray/order خود را دارد.

3) توپولوژی و مسیریابی

Hub-and-Spoke: هاب های منطقه ای به عنوان لاستیک ؛ نمایشنامه - گره نقش.
Mesh/P2P: مش جزئی برای تکرار/شایعات بی اساس.
Edge-Tiered: دروازه های لبه نازک (rate-limit/cache) → خوشه های منطقه ای ضخیم.
مسیریابی جغرافیایی: قوانین اقامت LB + Anycast/Latency-Aware.

Key - partitioning: 'partition _ key = chainId' tenant 'topic' entityId 'نظم و مقیاس قابل پیش بینی را می دهد.

4) حمل و نقل و فرمت ها

HTTP/2/3، gRPC/QUIC - تاخیر کم، چندگانه، keepalive.
Kafka/Pulsar/NATS - صف با پایداری/احزاب/گروه های مصرف کننده.
WebSocket - رویدادهای فشار و تغذیه زنده.
فرمت ها: Protobuf/Avro (طرح هایی با تکامل)، JSON برای API های خارجی.
آدرس هش و Merkle برای تأیید صحت.

5) سفارش، تحویل و نهایی سازی

• حداقل یک بار (پیش فرض ؛ idempotency/deadup مورد نیاز).
• اثر دقیقا یک بار از طریق Outbox/Inbox + مصرف کننده idempotent.
• سفارش: تضمین شده در حزب ؛ نظم بین حزبی تضمین شده نیست.
• Finalization: statuses 'observed → confirmed (K) → invalid (reorg)'; برای خوش بینانه - پنجره اختلاف.

6) idempotence و dedup

• 'idempotency _ key = $ {chainId} | $ {block} | $ {tx} | $ {logIndex} | $ {type}'

• Upsert توسط کلید، TTL پنجره deduplication ≥ 72 ساعت.
• برای یک درگیری، سیاست «منبع حقیقت» (اولویت، نسخه، امضا) است.
• برای درخواست های HTTP، هدر «Idempotency-Key» + پاسخ ورود به سیستم است.

7) صف، فشار پشتی و سهمیه

صف: احزاب توسط کلید ؛ DLQ برای پیام های «سمی».
فشار پشتی: اعتبار/نشانه، حداکثر حد پرواز، قطع کننده مدار.
سهمیه/QoS: P0 (بحرانی)، P1 (محصول)، P2 (فله). استخر تقسیم/RPS محدود/بایت/S/اشتراک.
کنترل پذیرش: رد اولیه درخواست های «گران»، محافظت از محدوده/اندازه.

8) سازگاری و مدل های داده

خواندن-شما-نوشتن در حزب/گره.
سازگاری احتمالی بین مناطق/احزاب.
CRDT برای تکرار بدون تداخل برخی از مجموعه ها (شمارنده ها، مجموعه ها).
عکس های فوری + سیاهههای مربوط به بوت استرپ سریع و پخش قطعی.

9) امنیت و اعتماد

mTLS بین گره ها، پین کلید، چرخش.
امضای پیام/webhook، زمان بندی و پنجره های ضد پخش.

رمزگذاری در حال حرکت/در حالت استراحت ؛ جداسازی کلیدهای منطقه ای

PII-minimization: نشانه گذاری، ممنوعیت اطلاعات شخصی در برچسب ها/معیارها.

10) کارایی: بسته بندی، فشرده سازی، کش

دسته بندی: گروه بندی پیام های کوچک برای کاهش سربار.
فشرده سازی: zstd/gzip با لغت نامه های امن.
پول نقد: پاسخ های منفی و دایرکتوری های «داغ» ؛ TTL و ناتوانی توسط رویداد.

11) نمودار داده ها (منابع)

ثبت نام جریان/لات

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

ورود به سیستم رویداد (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/قرنطینه

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

12) سیاست ها (YAML)

QoS و محدودیت ها

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

نهایی سازی و پنجره ها

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

مسیریابی/اقامت

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

13) قابلیت مشاهده: SLI/SLO

• تاخیر p95/p99 (ورود → خروج، در هر جریان/QoS).
• میزان موفقیت/میزان افت.
• صف تاخیر p95 و تاخیر مصرف کننده توسط حزب.
• طراوت p95 (مصرف → مصرف).
• نرخ تجدید سازمان/نامعتبر (اگر onchain).
• کارایی Dedup (٪ جذب idemotently).
• نسبت ضربه جغرافیایی (به صورت محلی سرویس).

• P0 تاخیر p95 ≤ 400 میلی ثانیه ؛ موفقیت ≥ 99 95%; صف تاخیر p95 ≤ 2 с ؛ طراوت p95 ≤ 60 с.
• راندمان Dedup ≥ 99٪ ؛ DLQ ≤ 0 1 درصد ترافیک

داشبورد: جریان هسته/تاخیر و طراوت/QoS و خطاها/جغرافیایی/امنیت (mTLS/امضا).

14) الگوهای مصرف کننده

صندوق خروجی/صندوق ورودی: انتشار اتمی و برنامه idemotent.
دقیقا یک بار اثر: ذخیره آخرین کلید اعمال شده و نسخه.
علامت های سفید: داده های دیر.
Idempotent Side-Effects: نمایش داده شد خارجی تنها با کلید و پاسخ ورود به سیستم.

15) حالت های تخریب

حالت Finished-only: ما فقط رویدادهای نهایی را صادر می کنیم.
فقط برای کتاب های مرجع، روش های سنگین انجماد.
دریچه گاز P2 و «حالت رژیم غذایی» برای جریان (کاهش نرخ تجدید).
فقط خواندنی برای API های ثانویه.

16) انتشار و مهاجرت بدون Downtime

آبی سبز/قناری توسط جریان و مصرف کنندگان.
Schema-first: فقط فیلدها را اضافه کنید MAJOR - نسخه های موازی از موضوعات.
مهاجرت افست: مصرف کنندگان سایه، مقایسه تاخیر/موفقیت، تعویض.

17) مقررات عملیاتی

روزانه: گزارش SLO (تاخیر/موفقیت/تاخیر/طراوت)، حسابرسی امضا، بررسی DLQ.
هفتگی: بازبینی دسته ها/سهمیه ها، آزمون DR (بوت استرپ از عکس فوری)، تجزیه و تحلیل کارایی Dedup.
ماهانه: آزمون هرج و مرج (از دست دادن/لرزش, شکست کارگزار, تجدید سازمان پشت سر هم), تجدید نظر در پنجره پایانی.
قبل از انتشار: قناری ≥120 دقیقه، دروازه های SLO، طرح برگشت.

18) حوادث کتاب بازی

A. انفجار صف/تاخیر مصرف کننده

1. افزایش مصرف کنندگان/KEDA ؛ 2) احزاب توزیع مجدد ؛ 3) انجماد P2 و کارهای فله ؛ 4) تجزیه و تحلیل کلید های «داغ».

B. رشد P95 تاخیر P0

1. P2-throttle، اولویت بندی P0 ؛ 2) دروازه های مقیاس/کارگزاران ؛ 3) کش فقط برای کتاب های مرجع ؛ 4) تخلیه بیرونی.

C. DLQ بالا/دوبله

1. بررسی کلید idempotence/TTL ؛ 2) تقویت dedup ؛ 3) محدود کردن تولید کننده پر سر و صدا ؛ 4) پخش پس از تعمیر.

D. طرح های رانش/قرارداد

1. فعال کردن حالت دقیق (قطع موارد نامعتبر) ؛ 2) اطلاع به تولید کننده ؛ 3) آداپتور را آزاد کنید 4) به روز رسانی linters.

E. نقض اقامت/امضا

1. واحد صادرات/کانال ؛ 2) چرخش کلید/serts ؛ 3) حسابرسی و پس از مرگ ؛ 4) به روز رسانی سیاست ها.

19) چک لیست پیاده سازی

1. انواع جریان و کلید پارتیشن بندی را تعریف کنید.
2. فعال کردن idempotence/dedup و نهایی کردن با K/پنجره اختلاف.
3. پیکربندی صف ها، QoS، سهمیه ها و فشار پشتی.
4. اجرای mTLS/امضا و سیاست اقامت.
5. طرحوارهها/ثباتها (جریانها، آفستها، DLQ) و فاصله سنجی SLI/SLO را وارد کنید.
6. سازماندهی مهاجرت مدار canary/blue-green و downtime-free.
7. کار کردن حالت های تخریب و playbooks حادثه.

20) واژه نامه

فشار پشتی - کنترل بار ورودی (اعتبارات/نشانه ها/محدودیت ها).
DLQ - «صف مرده» برای پیام های مشکل.
CRDT - ساختارهای داده با حل تعارض بدون هماهنگی.
Finality - برگشت ناپذیری رویداد/حالت.
اثر دقیقا یک بار - نتیجه تکرار ایمن بیش از حداقل یک بار تحویل.
علامت گذاری به عنوان پیشرفت پردازش برای رویدادهای اواخر.
Outlier-ejection - محرومیت از موارد تخریب شده از استخر.

خط پایین: جریان داده ها بین گره ها فقط یک «صف و شنونده» نیست، بلکه یک نظم سیستماتیک نظم، نهایی سازی، idempotency، امنیت و مشاهده است. کلید های پارتیشن بندی استاندارد، QoS/سهمیه ها، طرح های سختگیرانه و SLO ها، همراه با حالت های تخریب و کتاب های بازی، کانال های انتقال داده های پایدار اکوسیستم را در مقیاس و تحت ممیزی قرار می دهند.