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

حماسه یک معامله تجاری بلند مدت است که به دنباله ای از مراحل محلی در خدمات/مخازن مختلف تقسیم می شود. هر مرحله یک عمل جبران کننده دارد که اثر مرحله را در شکست جزئی برمی گرداند. بر خلاف 2PC/3PC، ساگا ها قفل های جهانی را نگه نمی دارند و برای میکروسرویس ها، چند منطقه و بارهای زیاد مناسب هستند، در حالی که سازگاری نهایی قابل قبول است.

1) هنگامی که برای انتخاب sagas (و زمانی که نه)

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

• اتمیسیته اسید جامد بسیار مهم است (به عنوان مثال، انتقال مقادیر زیادی در همان رجیستری).
• جبران پذیری مشخصی وجود ندارد (شما نمی توانید اثر را «رزرو» یا لغو کنید).
• محدودیت های قانونی/نظارتی نیاز به انزوا سخت و «فوری» ناوردا.

2) مدل های Sagas

1. Saga Orchestrator - هماهنگ کننده مرکزی مراحل و جبران خسارت را مدیریت می کند.

مزایا: جریان صریح، کنترل خطا، تله متری ساده شده.
معایب: نقطه تمرکز، خطر هماهنگ کننده «چربی».

2. رقص (Choreography): بدون مرکز - مراحل توسط حوادث آغاز می شود («سرویس A انجام X → سرویس B واکنش نشان می دهد»).

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

3. TCC (Try-Confirm/Cancel) - هر مرحله «Try» است، سپس تأیید یا لغو کنید.

مزایا: نزدیک به پروتکل شبه دو فاز، منابع مدیریت شده.
منفی: گران تر در اجرای رابط ؛ نیاز به «سعی کنید» وقفه دارنده.

3) طراحی زمین و جبران خسارت

ثابت ها: به وضوح بیان می کنند که چه چیزی باید «قبل/بعد» از مرحله درست باشد (به عنوان مثال، «باقی مانده ≥ 0»).
جبران خسارت ≠ معامله معکوس: این یک اقدام منطقی است که اثر کسب و کار را لغو می کند (بازپرداخت، انتشار، بازگرداندن).
Idempotence: هر دو مرحله و جبران کننده باید با خیال راحت تکرار شوند (با 'operation _ id').
مدت زمان: هر مرحله یک مهلت دارد ؛ تاخیر باعث جبران خسارت می شود.
اثرات غیر بازگشتی: آنها را به طور جداگانه ضبط کنید (اطلاعیه ها، ایمیل) و اجازه دهید «بهترین تلاش» باشد.

4) ثبات و نظم

ثبات احتمالی: کاربران می توانند اختلاف زمان را ببینند. UX - با «wait «/spinners/statuses.
سفارش توسط کلید - گروه مراحل سوئیچینگ توسط کلید کسب و کار (order_id) برای سفارش وقایع.
Deduplication - ثبت پردازش ('operation _ id' → وضعیت) را با TTL ذخیره کنید.

5) حمل و نقل و قابلیت اطمینان

الگوی Outbox-رویداد را به جدول خروجی محلی در همان معامله می نویسد و سپس آن را به صورت ناهمگام به اتوبوس منتشر می کند.
صندوق ورودی/فروشگاه Idempotency: در سمت مصرف کننده - ورود به سیستم از پیام های در حال حاضر پردازش شده است.
دقیقا یک بار به طور موثر: «outbox + مصرف کننده idemotent» عملی «دقیقا یک بار» می دهد.
DLQ: برای پیام های «سمی» با متا اطلاعات غنی و امن redrive.

6) خطا، بازپرداخت، سیاست های عقب نشینی

ما فقط گام های بیهوده را تکرار می کنیم ؛ عملیات نوشتن - با 'Idempotency-Key'.
عقب نشینی نمایشی + لرزش ؛ محدود کردن تلاش ها و مهلت خلاصه حماسه.
با تخریب سیستمیک - قطع کننده مدار و تخریب برازنده (به عنوان مثال، بخش داستانی ثانویه حماسه را لغو کنید).
درگیری های کسب و کار ('409') - تلاش مجدد پس از آشتی و یا جبران و پایان.

7) ارکستر: مسئولیت ها و ساختار

• پیگیری وضعیت حماسه: «در انتظار → در حال اجرا → جبران → انجام شده/شکست خورده».
• مراحل برنامه ریزی، مهلت ها، وقفه ها، عقب نشینی ها.
• مسیریابی رویداد و راه اندازی جبران خسارت.
• Idempotency از عملیات هماهنگ کننده (ورود به سیستم فرمان).
• قابلیت مشاهده: همبستگی 'saga _ id' در سیاهههای مربوط/ردیابی/معیارها.

• جدولهای «saga»، «saga _ step»، «commands»، «outbox».
• نمایه های «saga _ id»، «business _ key»، «وضعیت»، «next _ run _ at».

8) رقص: قوانین و حفاظت در برابر «گلوله برفی»

قراردادهای رویداد: طرحها و نسخهبندی (Avro/Proto/JSON Schema).
معانی روشن: «واقعیت رویداد» در مقابل «فرمان».
توقف زنجیره: سرویس، با تشخیص عدم تطابق، یک رویداد «شکست خورده »/« جبران» را منتشر می کند.
هشدارها و هشدارها در «حلقه های بی پایان».

9) TCC: جزئیات عملی

سعی کنید: ذخیره منابع با TTL.
تأیید: مرتکب، قفل موقت را آزاد کنید.
لغو: رزرو برگشت (بدون عوارض جانبی).
جمع آوری زباله: لغو خودکار Try پس از TTL (idempotent لغو).
تایید/لغو idempotent: تکرار امن است.

10) مثال (طرح کلمه) - «سفارش با پرداخت و تحویل»

1. CreateOrder (local) → صندوق پستی: «OrderCreated».
2. خدمات پرداخت: «سعی کنید» رزرو (TCC) ؛ اگر → 'PaymentReserved' suceeds, اگر 'PaymentFailed' → با شکست مواجه شود.
3. InventoryService: ذخیره محصول ؛ خارج از → 'InventoryFailed'.
4. ShippingService - ایجاد اسلات تحویل (قابل لغو).
5. اگر هر مرحله «ناموفق» → ارکستر جبران خسارت را به ترتیب معکوس شروع می کند: «CancelShipping» → «ReleaseInventory» → «PaymentCancel».
6. اگر همه خوب → «PaymentConfirm» → «OrderConfirmed».

11) شبه کد ارکستر

pseudo startSaga(saga_id, order_id):
steps = [ReservePayment, ReserveInventory, BookShipment, ConfirmPayment]
for step in steps:
res = execWithRetry(step, order_id)
if!res.ok:
compensateInReverse(steps_done(order_id))
return FAIL return OK

execWithRetry(step, key):
for attempt in 1..MAX:
try:
return step.run(key)    # идемпотентно catch RetryableError:
sleep(backoff(attempt))
catch NonRetryableError:
return FAIL return FAIL

compensateInReverse(done_steps):
for step in reverse(done_steps):
step.compensate()       # идемпотентно

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

ردیابی: تک 'saga _ id'، حاشیه نویسی 'مرحله'، 'تلاش'، 'تصمیم' (اجرا/جبران/جست و خیز).

• موفقیت/خطای ساگا (٪)، مدت زمان متوسط، p95/p99.
• سهم ساگا جبران شده، دلایل اصلی جبران خسارت.
• صف/صندوق عقب، retrays در مراحل.
• سیاهههای مربوط/ممیزی: راه حل ارکستر، شناسه منابع، کلید کسب و کار.

13) آزمایش و هرج و مرج

تزریق خطا در هر مرحله: وقفه، '5xx'، درگیری های کسب و کار.
حوادث خارج از ترتیب، تکراری، قطره.
دم طولانی از تاخیر → چک کردن مهلت و جبران.
sagas → چک کردن WFQ/DRR و کلاه در صف، عدم وجود «سر از خط مسدود کردن».
Redrave از DLQ در مراحل و در یک حماسه کامل.

14) چند اجاره، مناطق، انطباق

برچسب ها 'tenant _ id/plan/region' در رویدادها و مخازن حماسه.
اقامت: داده ها/رویدادها منطقه را ترک نمی کنند ؛ ساگا های بین منطقه ای به عنوان فدراسیون های ساگا های محلی + رویدادهای جمع آوری شده طراحی شده اند.
اولویت بندی: ساگا های VIP وزن سهمیه بیشتری دارند. جداسازی کارگران در هر مستاجر.

15) چک لیست پیش فروش

• هر مرحله یک جبران کننده واضح دارد، هر دو بی نظیر هستند.
• قالب انتخاب شده: ارکستراسیون/رقص/TSS ؛ محدودیت های مسئولیت تعریف شده است.
• صندوق ورودی/صندوق ورودی اجرا شده، deduplication توسط 'operation _ id'.
• سیاست های Retray: عقب نشینی با لرزش، محدودیت ها و مهلت کلی حماسه را امتحان کنید.
• قراردادهای رویداد نسخه، اعتبار سنجی از طرح وجود دارد.
• DLQ و انتشار امن پیکربندی شده اند.
• تله متری: معیارها، ردیابی، همبستگی 'saga _ id'.
• playbooks عملیاتی: لغو دستی/نیروی تایید، باز کردن قفل «آویزان» sagas.
• آزمون های هرج و مرج و بار، بودجه SLO/خطا تعریف شده است.

16) خطاهای معمول

هیچ جبرانی وجود ندارد و یا «کثیف» است (عوارض جانبی دارد).
هیچ idempotence/dedup وجود دارد - دو برابر و «نوسان» از دولت ها.
«حماسه در حماسه» بدون مرزهای صریح - چرخه و قفل متقابل.
هیچ مهلت → sagas «ابدی» و نشت منابع وجود دارد.
ارکستر دولت «در حافظه» بدون یک فروشگاه پایدار ذخیره می کند.
رقص بدون مرکز تله متری → شکست «نامرئی».
UX مبهم: کاربران وضعیت های متوسط را نمی بینند.

17) دستور العمل های سریع

کلاسیک SaaS: ارکستراسیون + صندوق پستی/صندوق ورودی، عقب نشینی نمایشی، DLQ، وضعیت حماسه در UI.
منابع ثابت قوی: TCC با رزرو TTL و GC لغو.
حجم بالا/بار: رقص رویداد + idemotency دقیق و معیارهای کلیدی.

چند منطقه: sagas محلی + aggregates نهایی ؛ اجتناب از قفل های جهانی

نتیجه گیری

Sagas راهی برای به دست آوردن ثبات قابل پیش بینی در سیستم های توزیع شده بدون قفل جهانی است. جبران کننده های روشن، idemotence، تحویل قابل اعتماد (صندوق ورودی/صندوق ورودی)، نظم و انضباط timeout و retray، به علاوه تله متری و playbooks، کلید اطمینان از اینکه فرآیندهای کسب و کار پیچیده باقی می ماند پایدار و قابل خواندن با افزایش بار، تعداد خدمات و جغرافیا.