الگوی حماسه و معاملات توزیع شده

الگوی حماسه و معاملات توزیع شده

1) چرا ساگا مورد نیاز است

2PC کلاسیک (قفل دو فاز) ضعیف مقیاس پذیر، پیچیده تحت شکست و منابع بلوک است. حماسه فرایند کلی کسب و کار را به یک دنباله ای از معاملات محلی (مراحل) تقسیم می کند، که هر کدام به طور مستقل انجام می شود. در صورت عدم موفقیت، مراحل بعدی لغو می شوند و آنهایی که قبلاً تکمیل شده اند با عملیات معکوس جبران می شوند.
نتیجه: سازگاری نهایی مدیریت شده بدون مسدود کردن جهانی، بقای بالا و یک پروتکل بازیابی روشن.

2) مدل های پایه

2. 1 ارکستر

یک هماهنگ کننده حماسه اختصاصی مراحل را مدیریت می کند: دستورات را ارسال می کند، منتظر پاسخ ها/رویدادها می ماند، جبران خسارت را آغاز می کند.
مزایا: کنترل متمرکز، مشاهدهپذیری ساده، ضربالاجلهای صریح. منفی: جزء اختیاری.

2. 2 طراحی رقص

بدون هماهنگ کننده ؛ سرویسها به رویدادهای یکدیگر پاسخ میدهند («OrderPosted →» «PaymentCaptured» → «InventoryReserved»...).
مزایا: اتصال ضعیف. منفی: سخت تر برای ردیابی، خطر «رقص مرگ» بدون قوانین روشن است.

2. 3 TCC (امتحان تأیید/لغو)

1. سعی کنید - آماده سازی/رزرو،

2. تأیید - تثبیت،

3. لغو - بازگشت

تضمین ها بالاتر است، اما قراردادها و زمان رزرو پیچیده تر هستند.

3) قراردادهای گام و جبران خسارت

هر مرحله = معامله محلی + جبران (idempotent، اجازه می دهد تا تکرار).
جبران خسارت لازم نیست به طور کامل «بازگشت جهان» - معادل دامنه کافی است (به عنوان مثال، «پرداخت بازگشت» به جای «حذف پرداخت»).
تعریف ناوردا: برای پول - تعادل به منفی نمی رود ؛ برای سفارشات - بدون وضعیت «آویزان».
را وارد کنید ضرب العجل/ذخایر TTL و یک «جمع آوری زباله» برای تلاش های عقب افتاده.

4) سازگاری و معانی تحویل

تحویل پیام: حداقل یک بار (پیش فرض) → تمام عملیات باید idempotent باشد.
سفارش: مهم با کلید همبستگی (به عنوان مثال،. 'order _ id', 'player _ id').
دقیقا یک بار هدف حماسه نیست ؛ ما از طریق کلید های idemotent، outbox/inbox و تعهد صحیح به یکنواختی موثر دست می یابیم.

5) وضعیت حماسه و ورود به سیستم آن

• 'saga _ id'، 'correlation _ id'، وضعیت فعلی (در حال اجرا/تکمیل/جبران/جبران/شکست خورده)،
• مرحله و متغیرهای آن (شناسه پرداخت/رزرو)،
• تاریخچه (ورود به سیستم) رویدادها/تصمیم گیری ها، زمانبندی ها، مهلت ها، تعداد بازپرداخت ها.

• یک Saga Store جداگانه (جدول/سند) در دسترس هماهنگ کننده.
• برای رقص - «عوامل» محلی حماسه، انتشار رویدادهای وضعیت در یک موضوع مشترک.

6) الگوهای انتشار قابل اعتماد: صندوق پستی/صندوق ورودی

Outbox: مرحله تغییر را انجام می دهد و رویداد/فرمان را به یک جدول خروجی در یک معامله می نویسد ؛ کارگر در تایر منتشر می کند.
صندوق ورودی: مصرفکننده جدولی از پردازش 'message _ id' → dedup + idempotency را نگه میدارد.
پس از یک اثر جانبی موفق، مرتکب افست/ACK (Kafka/RabbitMQ) - نه زودتر.

7) مراحل طراحی حماسه

7. 1 مثال (خرید iGaming/تجارت الکترونیک)

1. PlaceOrder → وضعیت «در انتظار».
2. AuthorizePayment (Try) → 'payment _ hold _ id'.
3. ReserveInventory → 'reservation _ id'.

4. CapturePayment (تأیید)

5. FinalizeOrder → «تکمیل شده».

• اگر (3) «CancelPaymentHold» → با شکست مواجه شود ؛
• (4) خرابی پس از (3) → «فهرست انتشار» ؛
• اگر (5) «RefundPayment» و «ReleaseInventory» → با شکست مواجه شود.

7. 2 مهلت/عقب نشینی

حداکثر بازپخش N با تأخیر نمایی + لرزش.
پس از بیش از - به «جبران» بروید.
next_attempt_at و deadline_at را برای هر مرحله ذخیره کنید.

8) ارکستر در مقابل پلت فرم

• ارکستراتور خانه سبک (مایکروسرویس + جدول حماسه).
• بستر های نرم افزاری: Temporal/Cadence، Camunda، Netflix Conductor، Zeebe - به تایمر، retrays، جریان کار طولانی مدت، دید و یک کنسول وب.
• برای طراحی رقص، از یک کاتالوگ رویداد و یک قرارداد وضعیت/کلید دقیق استفاده کنید.

9) پروتکل های ادغام

9. 1 ناهمزمان (کافکا/RabbitMQ)

وی افزود: "پرداختها. اجازه بده. v1 '،' موجودی. رزرو کنید. v1 '.
رویدادها: "پرداخت ها. مجاز است. v1 '،' موجودی. رزرو شده v1، پرداخت ها. دستگیر شد. v1، پرداخت ها. بازپرداخت شده v1 '.
کلید بخش = 'order _ id '/' player _ id' برای سفارش.

9. 2 همزمان (HTTP/gRPC) در یک مرحله

معتبر برای مراحل «کوتاه»، اما همیشه با timeouts/retrays/idempotency و بازگشت به جبران آسنکرون.

10) Idempotence و کلید

در درخواست های دستور و جبران، pass 'idempointency _ key'.
عوارض جانبی (نوشتن در پایگاه داده/نوشتن خاموش) به صورت مشروط انجام می شود: «اگر هنوز» idempotency _ key «را ندیده اید، انجام دهید».
جبران خسارت نیز idempotent: تکرار 'RefundPayment (id = X)' امن است.

11) مدیریت خطا

• گذرا (شبکهها/زمانهای خاموشی) → بازگشت/برگشت.
• کسب و کار (بودجه کافی، محدودیت) → جبران فوری/مسیر جایگزین.
• غیر قابل جبران → مداخله دستی، جبران دستی.
• ایجاد یک ماتریس راه حل: نوع خطا → عمل (تلاش مجدد/جبران/تشدید).

12) قابلیت مشاهده و کاهش SLO

• تأخیر پایان به پایان حماسه (p50/p95/p99).
• میزان موفقیت
• میانگین زمان برای جبران и جبران خسارت.
• ساگا یتیم و زمان به GC.
• ردیابی: 'trace _ id '/' saga _ id' به عنوان لینک فاصله بین مراحل ؛ معیارهای نرخ سوزاندن برای بودجه خطا.

سیاهههای مربوط: هر تغییر وضعیت حماسه = رکورد ساختار با علت.

13) نمونه ها (شبه کد)

13. 1 ارکستر (ایده)

python def handle(OrderPlaced e):
saga = Saga. start(e. order_id)
saga. run(step=authorize_payment, compensate=cancel_payment)
saga. run(step=reserve_inventory, compensate=release_inventory)
saga. run(step=capture_payment, compensate=refund_payment)
saga. run(step=finalize_order, compensate=refund_and_release)
saga. complete()

def run(step, compensate):
try:
step () # local transaction + outbox except Transient:
schedule_retry()
except Business as err:
start_compensation(err)

13. 2 جعبه خروجی (ایده جدول)

outbox(id PK, aggregate_id, event_type, payload, created_at, sent_at NULL)
inbox(message_id PK, processed_at, status)
saga(order_id PK, state, step, next_attempt_at, deadline_at, context JSONB)
saga_log(id PK, order_id, time, event, details)

13. 3 رقص (ایده های تم)

دستور داد. قرار داده شده «→ مصرف کنندگان: » پرداخت. اجازه دهید، موجودی. ذخیره شده

سلام. موجودی مجاز «+». سفارشات رزرو شده. try_finalize'

هرگونه شکست در اجرای دستورات پرداخت های «→ آغاز شده» را جبران کنید. لغو/بازپرداخت '،' موجودی. آزاد کنید.

14) مقایسه با 2PC و ES

2PC: سازگاری قوی، اما انسداد، تنگناها، لوله های مس.
Saga: سازگاری نهایی، شما نیاز به یک رشته جبران خسارت و تله متری دارید.
منبع یابی رویداد: رویدادها را به عنوان منبع حقیقت ذخیره می کند. sagas در آن طبیعی است، اما پیچیدگی را به مهاجرت/عکس های فوری اضافه کنید.

15) ایمنی و انطباق

امنیت حمل و نقل (TLS/mTLS)، ACL در هر موضوع/صف.
در حوادث - حداقل PII، رمزگذاری زمینه های حساس، نشانه گذاری.
دسترسی حسابرسی به sagas و گزارش های جبران خسارت.
SLA با ارائه دهندگان خارجی (پرداخت/تحویل) = مهلت و پارامترهای حد مجاز.

16) چک لیست پیاده سازی (0-45 روز)

0-10 روز

فرآیندهای کاندید را انتخاب کنید (چند سرویس، جبران شده).
مدل (ارکستراسیون/رقص/TCC) و کلید همبستگی را انتخاب کنید.
توصیف مراحل/آفست، ثابت و مهلت. جداول «saga»، «outbox»، «inbox» را بالا ببرید.

11-25 روز

شامل صندوق خروجی/صندوق ورودی، idempointency، و retraces برگشت.
اولین ساگا Deploite ؛ داشبورد SLI/SLO را اضافه کنید و ردیابی کنید.
یک runbook از جبران خسارت (از جمله دستی) و افزایش حقوق بنویسید.

26-45 روز

خودکار GC «حلق آویز» ساگا، راه اندازی مجدد دوره/ادامه در مهلت.
صرف روز بازی: شکست مرحله، بیش از حد مهلت، عدم دسترسی کارگزار.
استاندارد کردن قراردادهای رویداد (نسخه ها، سازگاری)، ایجاد یک «دایرکتوری حماسه».

17) ضد الگوهای

«جبران خسارت = حذف از پایگاه داده» به جای عمل معکوس دامنه صحیح.
بدون صندوق ورودی/صندوق → از دست دادن رویدادها/اثرات دوگانه.

Retrai without jitter → وابستگی های خود DDoS

انتظار سازگاری قوی در خواندن بدون «پردازش در حال پیشرفت»....
یک ارکستر غول پیکر برای همه → کنترل مونولیت.
رقص کامل بدون دید و SLA → رقص غیر قابل کنترل.
نادیده گرفتن مهلت → ذخایر ابدی/نگه می دارد.

18) معیارهای بلوغ

≥ 90٪ از فرآیندهای بحرانی توسط sagas/جبران پوشیده شده و توصیف ناوردا.
صندوق ورودی/صندوق ورودی برای همه تولید کنندگان/مصرف کنندگان Tier-0/1 یکپارچه شده است.
SLO: p95 حماسه پایان به پایان طبیعی است، میزان موفقیت پایدار است، یتیم <هدف.
ردیابی شفاف و داشبورد «در مراحل»، هشدار سوختگی نرخ.
سه ماهه بازی روز و کتابچه راهنمای کتابچه راهنمای کاربر چک جبران.

19) نتیجه گیری

Saga یک قرارداد عملی انسجام برای سیستم های توزیع شده است: مراحل روشن و اقدامات معکوس، نظم و انضباط چاپ و نشر (صندوق پستی/صندوق ورودی)، مهلت و بازپرداخت، مشاهده پذیری و فرآیندهای جبران خسارت. یک مدل (ارکستراسیون/رقص/TSS) را انتخاب کنید، ثابت ها و کلید ها را ثابت کنید، مدیران را بی نظیر کنید - و فرآیندهای کسب و کار چند سرویس شما بدون 2PC گران قیمت قابل پیش بینی و پایدار خواهد بود.