الگوی ساگا Saga: مدیریت تراکنش های توزیع شده در میکرو سرویس

در دنیای سیستم های یکپارچه سنتی (Monolith)، حفظ یکپارچگی داده ها کاری سرراست و شفاف بود؛ پایگاه داده های رابطه ای با بهره گیری از ویژگی های چهارگانه ACID (اتمیک بودن، سازگاری، برای درک بهتر ساختار سرویس ها، مطالعه مقاله معماری تمیز توصیه می شود.

جداسازی و پایایی) تضمین می کردند که تمام مراحل یک تراکنش یا به طور کامل با موفقیت انجام شود (Commit) و یا در صورت بروز کوچک ترین خطا، به حالت اولیه بازگردد (Rollback).

اما با مهاجرت گسترده سازمان ها به سوی معماری میکرو سرویس و پایبندی به اصل بنیادین «یک دیتابیس اختصاصی به ازای هر سرویس» (Database-per-Service)، تراکنش های ACID سراسری دیگر امکان پذیر نیستند.

در این میان، الگوی ساگا (Saga Pattern) به عنوان معتبرترین راهکار استاندارد معماری برای مدیریت تراکنش های توزیع شده و دستیابی به سازگاری نهایی (Eventual Consistency) شناخته می شود.

در این مقاله جامع با مفاهیم، الگو های ارکستراسیون، کوریوگرافی، تراکنش های جبرانی و چالش های تولیدی ساگا در بیش از ۳,۶۰۰ کلمه آشنا خواهید شد.

۱. چرا رویکرد سنتی دو فازی (۲PC) در سیستم های توزیع شده کارایی ندارد؟

برای سال ها، راهکار مهندسی برای مدیریت تراکنش های میان چند سرور، استفاده از پروتکل تعهد دو فازی (Two-Phase Commit یا ۲PC) بود.

در این پروتکل، یک هماهنگ کننده (Coordinator) ابتدا در فاز آماده سازی (Prepare Phase) به تمامی دیتابیس ها پیام ارسال می کند و از آنها می پرسد آیا آماده کامیت هستند یا خیر. در این مدت، دیتابیس ها رکوردهای مربوطه را قفل (Lock) می کنند.

سپس در فاز دوم (Commit Phase)، هماهنگ کننده دستور کامیت نهایی را صادر می نماید.

هرچند ۲PC در سیستم های متمرکز با تعداد محدودی سرور پاسخگو بود، در اکوسیستم های کلود و توزیع شده مدرن با ۳ شکست فاجعه بار همراه است:

• مسدودسازی همگانی (Blocking Protocol): اگر هماهنگ کننده یا یکی از دیتابیس ها موقتاً قطع شود، قفل های دیتابیس ها باز نمی شوند و منابع سرور تا مرز انفجار مسدود می مانند.
• کاهش فاحش توان عملیاتی (Low Throughput): به دلیل تاخیر شبکه میان میکرو سرویس های مختلف، قفل ماندن منابع نرخ پردازش تراکنش ها (TPS) را تا بیش از ۸۵ درصد کاهش می دهد.
• تضاد با تئوری CAP: طبق قضیه CAP، در صورت رخداد پارتیشن شبکه ای، سیستم های توزیع شده نمی توانند همزمان سازگاری قوی (Consistency) و دسترسی پذیری بالا (Availability) را ارائه دهند. ۲PC دسترسی پذیری را فدای سازگاری می کند که برای پلتفرم های مقیاس میلیونی پذیرفتنی نیست. جهت درک بیشتر مبانی داده ها، تحلیل طراحی سیستم های توزیع شده را بررسی کنید.

۲. ساختار بنیادین الگوی ساگا و انواع تراکنش ها

الگوی ساگا برای نخستین بار در سال ۱۹۸۷ توسط هکتور گارسیا-مولینا معرفی شد و سال ها بعد در دنیای میکرو سرویس ها احیا گردید. در یک ساگا، تراکنش ها به سه دسته ساختاری تقسیم می شوند:

1. تراکنش های جبران پذیر (Compensable Transactions): گام هایی از تراکنش که می توان در صورت رخداد خطا در مراحل بعدی، اثرات آنها را با یک تراکنش معکوس جبران کرد (مانند کسر پول از کیف پول کاربر یا رزرو انبار).
2. تراکنش نقطه بی بازگشت (Pivot Transaction): لحظه ای حیاتی در ساگا که اگر این گام موفق شود، کل ساگا تا پایان تضمین شده تلقی می شود و نیازی به بازگشت نیست. اگر این گام شکست بخورد، کلیه گام های قبلی باید رول بک جبرانی شوند.
3. تراکنش های تکرار شونده (Retriable Transactions): گام هایی پس از پیوت ترنزکشن که تضمین می شود در نهایت با تلاش مجدد (Retry) با موفقیت اجرا خواهند شد (نظیر ارسال ایمیل تایید یا صدور فاکتور نهایی).

۳. دو رویکرد پیاده سازی ساگا: Choreography در برابر Orchestration

پیاده سازی الگوی ساگا به دو استراتژی کاملاً متفاوت تقسیم می شود که هر یک دارای مزایا و معایب ویژه ای برای تیم های نرم افزاری است:

۱. ساگا مبتنی بر رقص آرایی (Choreography-based Saga)

در این مدل، هیچ کنترل کننده متمرکزی وجود ندارد. هر میکرو سرویس پس از اتمام موفقیت آمیز تراکنش محلی خود، یک اونت (Event) به بروکر پیام هایی نظیر معماری رویداد محور با کافکا ارسال می کند. سرویس های دیگر به این اونت ها گوش داده (Subscribe) و گام بعدی خود را آغاز می نمایند.

مزیت: سادگی استقرار اولیه در تراکنش های کوتاه (۲ تا ۴ مرحله)، عدم وجود نقطه تکینه شکست (Single Point of Failure) و ایزولاسیون کامل سرویس ها.
چالش: با افزایش تعداد سرویس ها به بیش از ۵ مورد، ردیابی جریان تراکنش بسیار دشوار شده، خطر چرخه های نامتناهی پیام وجود دارد و عیب یابی در پروداکشن به یک کابوس بدل می شود.

۲. ساگا مبتنی بر هماهنگ کننده (Orchestration-based Saga)

در این رویکرد، یک کلاس یا سرویس اختصاصی تحت عنوان ارکستریتور (Saga Orchestrator) مسئولیت کامل چرخه حیات تراکنش را بر عهده می گیرد. ارکستریتور به عنوان یک ماشین وضعیت (State Machine) عمل کرده و به نوبت به هر میکرو سرویس دستور می دهد که چه کاری انجام دهد و منتظر پاسخ وضعیت می ماند.

مزیت: جریان کسب و کار در یک نقطه متمرکز و شفاف کد نویسی می شود، مدیریت رول بک ها و تراکنش های جبرانی ساده است و وضعیت فعلی هر سفارش به راحتی قابل کوئری است.

۴. پیاده سازی عملی الگوی ارکستراسیون در معماری سرویس ها

برای فهم عمیق تر، یک فرآیند خرید آنلاین را تصور کنید که شامل ۴ سرویس مجزا است:

• Order Service: ایجاد سفارش در وضعیت PENDING
• Payment Service: برداشت مبلغ فاکتور از حساب یا درگاه
• Inventory Service: کسر موجودی کالای فیزیکی در انبار
• Shipping Service: صدور حواله ارسال بار

کد زیر نحوه ساختاردهی ارکستریتور این فرآیند را به صورت پترن تمیز در پایتون نشان می دهد:

from dataclasses import dataclass
from enum import Enum
import logging

class SagaStatus(Enum):
    PENDING = "PENDING"
    SUCCESS = "SUCCESS"
    FAILED = "FAILED"

@dataclass
class OrderContext:
    order_id: str
    user_id: str
    amount: float
    product_id: str
    payment_processed: bool = False
    inventory_reserved: bool = False

class OrderSagaOrchestrator:
    def __init__(self, payment_client, inventory_client, order_client):
        self.payment = payment_client
        self.inventory = inventory_client
        self.order = order_client
        self.logger = logging.getLogger("SagaOrchestrator")

    def execute_saga(self, context: OrderContext) -> SagaStatus:
        self.logger.info(f"شروع اجرای ساگا برای سفارش {context.order_id}")

        # گام اول: رزرو موجودی کالا در انبار
        if not self.inventory.reserve(context.product_id, quantity=1):
            self.logger.error("رزرو کالا در انبار با شکست مواجه شد.")
            self.order.mark_as_failed(context.order_id, reason="Inventory Empty")
            return SagaStatus.FAILED
        context.inventory_reserved = True

        # گام دوم: پرداخت وجه سفارش
        if not self.payment.process_charge(context.user_id, context.amount):
            self.logger.error("پرداخت ناموفق بود؛ آغاز فرآیند تراکنش های جبرانی...")
            self.rollback_saga(context)
            return SagaStatus.FAILED
        context.payment_processed = True

        # گام سوم: تکمیل نهایی سفارش (Pivot Transaction)
        self.order.mark_as_confirmed(context.order_id)
        self.logger.info(f"تراکنش ساگا با موفقیت برای سفارش {context.order_id} نهایی شد.")
        return SagaStatus.SUCCESS

    def rollback_saga(self, context: OrderContext):
        # اجرای معکوس تراکنش های جبرانی
        if context.inventory_reserved:
            self.logger.warning(f"لغو رزرو انبار برای محصول {context.product_id}")
            self.inventory.release_reservation(context.product_id, quantity=1)

        self.order.mark_as_failed(context.order_id, reason="Payment Failed")

۵. چالش عدم وجود ایزولاسیون (Lack of Isolation) و راهکارهای غلبه بر آن

بزرگ ترین چالش تئوریک الگوی ساگا، فقدان ایزولاسیون (Isolation) است. در استاندارد ACID، تغییرات یک تراکنش تا زمان کامیت شدن برای تراکنش های همزمان دیگر پنهان می ماند. اما در ساگا، چون هر تراکنش محلی بلافاصله در دیتابیس خود کامیت می شود، تغییرات ناتمام توسط سایر کاربران سیستم قابل مشاهده است.

این فقدان ایزولاسیون ممکن است منجر به سه ناهنجاری (Anomaly) پروداکشن گردد:

1. Dirty Reads (خواندن کثیف): کاربری موجودی انباری را می بیند که رزرو شده ولی هنوز پرداخت نشده و لحظاتی بعد کنسل می شود.
2. Lost Updates (به روزرسانی های گمشده): یک ساگا رکوردی را ویرایش می کند و بدون توجه به تغییرات ساگای دوم، روی آن بازنویسی می کند.
3. Non-repeatable Reads: داده ای که در ابتدای ساگا خوانده شده، پیش از پایان ساگا توسط فرآیند دیگری دستکاری می شود.

الگو های طراحی متقابل برای حل چالش ایزولاسیون

• الگوی Semantic Lock (قفل معنایی): اضافه کردن فلگ های وضعیت نظیر PENDING_APPROVAL روی رکوردها تا سایر سرویس ها متوجه ناتمام بودن تراکنش شوند.
• الگوی Pessimistic Offline Lock: ممانعت از تغییر رکوردهای اشتراکی تا زمان بسته شدن ساگا.
• الگوی Reread Value (بازخوانی مقدار): پیش از کامیت گام نهایی، مقدار فیلد مجدداً چک شود تا تضمین گردد توسط تراکنش دیگری بازنویسی نشده است.

۶. تضمین قابلیت اطمینان پیام ها با الگوی Outbox تراکنشی

در سیستم های توزیع شده، عملیات ثبت در دیتابیس محلی و ارسال پیام به مسج بروکر دو عملیات مجزا هستند. اگر دیتابیس آپدیت شود اما شبکه پیش از ارسال پیام به کافکا قطع گردد، کل زنجیره ساگا متوقف می ماند.

راهکار قطعی این بحران، پیاده سازی الگوی Outbox تراکنشی (Transactional Outbox Pattern) است. در این پترن، به جای ارسال مستقیم به بروکر، پیام مورد نظر درون همان تراکنش دیتابیس در جدولی به نام outbox_messages درج می شود. سپس یک فرآیند پس زمینه (Worker یا ابزار هایی مانند Debezium CDC) پیام های جدول اوت باکس را خوانده و با اطمینان ۱۰۰ درصدی به کافکا ارسال می کند.

۷. ابزار ها و فریم ورک های سازمانی مدیریت ساگا در سال ۲۰۲۶

پیاده سازی ارکستریتور به صورت دستی برای فرآیندهای بسیار گسترده دشوار است. امروزه ابزار های نسل جدید ارکستراسیون کدهای توزیع شده را همانند کدهای خطی ساده می کنند:

• Temporal.io: انقلابی ترین فریم ورک Workflow-as-Code در دنیا که شکست ها، تایم اوت ها و تراکنش های جبرانی را در کدهای پایتون، گو، جاوا و تایپ اسکریپت به صورت خودکار مدیریت می کند.
• Camunda ۸: موتور فرآیندهای کسب و کار سازمانی (BPMN ۲.۰) با ارکستراسیون گرافیکی و مانیتورینگ بلادرنگ.
• Axon Framework: فریم ورک تخصصی جاوا برای پیاده سازی Event Sourcing، CQRS و ساگا در سیستم های بانکی.
• MassTransit: ابزار استاندارد و فوق العاده محبوب در اکوسیستم دات نت برای پیاده سازی ماشین های وضعیت و ساگا با RabbitMQ و Azure Service Bus.

۸. استراتژی های تریس و مانیتورینگ توزیع شده در زنجیره ساگا

ردیابی تراکنشی که از میان ۱۰ میکرو سرویس مختلف عبور می کند، بدون ابزار های مانیتورینگ پیشرفته غیرممکن است. برای مشاهده پذیری کامل (Observability) در ساگا، استانداردهای زیر ضروری هستند:

• Correlation ID متمرکز: در لحظه دریافت درخواست اولیه کاربر، یک شناسه یکتا (UUID) تولید می شود و در هدر کلیه پیام های HTTP، gRPC و پیام های کافکا منتقل می گردد تا تمام لاگ ها در OpenSearch یا Elasticsearch ذیل یک شناسه قابل سرچ باشند.
• توزیع تریس با OpenTelemetry: با الصاق Spans به هر گام تراکنش محلی، زمان پاسخ دهی، تاخیر صف ها و نقاط شکست در داشبوردهای Grafana Tempo و Jaeger به صورت گرافیکی نمایش داده می شود.
• محاسبه شاخص MTTR در خرابی های تراکنش: مانیتورینگ دقیق نرخ موفقیت تراکنش های جبرانی و آلارم دهی آنی در پروداکشن در صورتی که زمان بازیابی سیستم از میانگین ۵ ثانیه تجاوز کند.

۱۰. کالبدشکافی سناریوهای واقعی: الگوی ساگا در سیستم های پرداخت و بانکی

برای آنکه درک تئوریک به مهارت عملیاتی بدل گردد، بیایید پیچیده ترین سناریوی ممکن در معماری سیستم های بانکی مدرن را کالبدشکافی کنیم: «فرآیند انتقال وجه بین بانکی آنی (Instant Interbank Transfer)».

در این سناریو، سه بانک یا سیستم مستقل درگیر هستند:

1. سرویس بانک مبدا (Debiting Account): بررسی موجودی، مسدودسازی موقت مبلغ و کسر وجه.
2. سرویس سامانه پایا یا تسویه مرکزی (Clearing Switch): اعتبارسنجی شبا و انتقال حواله بین بانکی.
3. سرویس بانک مقصد (Crediting Account): واریز وجه به شماره حساب مقصد.

اگر در گام سوم، بانک مقصد به دلیل قطعی دیتابیس یا مسدود بودن حساب مقصد پاسخ ناموفق ارسال کند، ارکستریتور ساگا موظف است فوراً فرآیند جبران را آغاز کند:

1. [Action] Core Banking: Block and Deduct 1,000,000 Rials -> Success
2. [Action] Settlement Switch: Transmit Interbank Message -> Success
3. [Action] Beneficiary Bank: Credit Account -> FAILED (Account Frozen)
4. [Compensation] Settlement Switch: Cancel Transfer Order -> Confirmed
5. [Compensation] Core Banking: Unfreeze and Refund 1,000,000 Rials -> Confirmed

نکته ای که در سیستم های بانکی وجود دارد، استفاده از الگوی Forward Recovery (بازیابی به جلو) در برابر Backward Recovery (بازیابی به عقب) است. در مواردی که امکان بازگشت وجه وجود ندارد یا فرآیند تا بیش از ۹۰ درصد پیش رفته است، سیستم به جای رول بک، پیام را در صف تلاش مجدد نگه می دارد تا با رفع مشکل بانک مقصد، تراکنش نهایی گردد.

۱۱. الگو های پیشرفته تست تراکنش های توزیع شده در ساگا

تست کردن زنجیره ای از میکرو سرویس های ناهمگام یکی از دشوارترین بخش های مهندسی نرم افزار است. با راهکارهای زیر می توان پایداری ساگا را پیش از انتشار اعتبارسنجی کرد:

• تزریق خرابی عمدی با Chaos Engineering: با ابزار هایی نظیر Chaos Mesh، قطعی ساختگی در دیتابیس سرویس دوم یا تاخیر شبکه ۵ ثانیه ای ایجاد کنید تا مطمئن شوید تراکنش های جبرانی دقیقاً در موعد مقرر و بدون نشت داده اجرا می شوند.
• تست هم توانی (Idempotency Testing): با شبیه سازی ارسال پیام های تکراری به وسیله ابزار های تست بار، تضمین کنید که پردازش یک رویداد برای بار دوم منجر به تغییر مانده حساب یا صدور فاکتور مضاعف نمی شود.
• تست وضعیت نیمه تمام (Partial State Recovery): متوقف کردن ناگهانی سرور ارکستریتور در اواسط تراکنش و روشن کردن مجدد آن، تا اثبات شود ماشین وضعیت قادر است دقیقاً از همان گام ناتمام عملیات را ادامه دهد.

۱۲. پیاده سازی الگوی Outbox با Debezium CDC و کافکا کانکت در ساگا

در سیستم های توزیع شده صنعتی، نوشتن مستقیم کد برای ارسال پیام به کافکا پس از کامیت دیتابیس (Dual-Write Problem) همواره با ریسک نشت داده و ناسازگاری همراه است. اگر دیتابیس آپدیت شود اما اینترنت یا سرور در فاصله چند میلی ثانیه تا ارسال پیام قطع شود، پیام هیچ گاه به سایر سرویس ها نمی رسد.

رویکرد استاندارد سازمانی در سال ۲۰۲۶، تلفیق تکنولوژی Change Data Capture (CDC) با ابزار Debezium است. در این معماری:

1. میکرو سرویس تغییرات بیزینس خود و پیام ارکستراسیون ساگا را در قالب یک تراکنش واحد ACID درون دو جدول محلی (مثلاً جدول orders و جدول outbox_events) در دیتابیس PostgreSQL ذخیره می کند.
2. ابزار Debezium به صورت زنده لاگ های تراکنش دیتابیس (WAL یا Write-Ahead Log) را مانیتور می کند.
3. به محض افزوده شدن یک رکورد جدید به جدول اوت باکس، Debezium رکورد را با تضمین حداقل یک بار تحویل (At-least-once Delivery) خوانده و آن را در تاپیک مربوطه در کلاستر آپاچی کافکا منتشر می کند.
4. پس از تایید دریافت از سوی کافکا، رکورد اوت باکس می تواند پاک شده یا به وضعیت PROCESSED تغییر یابد.

این رویکرد تضمین می کند که هیچ پیامی گم نشود، عملکرد پردازش تراکنش به دلیل تاخیر شبکه افت نکند و بار کاری توسعه دهندگان در نوشتن کدهای پیچیده ریکاوری شبکه به حداقل برسد.

۱۳. مدیریت همزمانی با قفل خوش بینانه (Optimistic Concurrency Control) در تراکنش های ساگا

یکی از شایع ترین باگ ها در پلتفرم های با تراکنش بالا (نظیر حراجی های آنلاین، فروش بلیت و رزرو پرواز)، رزرو همزمان یک صندلی یا کالا توسط دو کاربر متفاوت در دو ساگای مجزا است. برای غلبه بر این پدیده، باید از قفل گذاری خوش بینانه (Optimistic Locking) بر پایه فیلد نسخه (version) استفاده شود:

-- نمونه کوئری ایمن برای به روزرسانی موجودی در تراکنش محلی ساگا
UPDATE inventory_items
SET available_stock = available_stock - 1,
    version = version + 1
WHERE product_id = 'PROD-9821'
  AND available_stock > 0
  AND version = 4;

اگر دو ساگا همزمان قصد کسر موجودی داشته باشند،

تنها تراکنشی که تطابق version = ۴ دارد موفق می شود و رکورد را به نسخه ۵ ارتقا می دهد؛ تراکنش دوم با صفر ردیف تحت تاثیر (Affected Rows = ۰) روبرو شده و ارکستریتور متوجه می شود که داده تغییر یافته است.

در این حالت، ارکستریتور بدون معطلی گام جبرانی خود را فعال کرده و به کاربر اعلام می کند که کالا توسط مشتری دیگری خریداری شده است.

این روش نرخ توان عملیاتی سیستم را تا ۶۵ درصد نسبت به قفل های سنتی بدبینانه (Pessimistic Locks) بهبود می بخشد.

۱۴. استراتژی های صف های نامه مرده (DLQ) و مداخله دستی در بحران ها

حتی با کامل ترین طراحی ها، شرایط غیرقابل پیش بینی نظیر باگ های منطقی در سورس کد، تحریم های شبکه ای یا تغییر ساختار اسکیمای پیام ها ممکن است باعث شود که یک تراکنش جبرانی صدها بار تلاش مجدد کند و همچنان با شکست روبرو گردد. در چنین وضعیتی، سیستم نباید در حلقه بی نهایت گیر کند.

راهکار مهندسی، انتقال پیام معیوب به Dead Letter Queue (DLQ) پس از تعداد مشخصی تلاش (مثلاً ۵ تلاش با فاصله های تصاعدی Exponential Backoff) است:

• پیام به همراه کلیه متادیتاها، پیام های خطای ثبت شده و زمان رخ داد در صف خطاهای بحرانی ذخیره می شود.
• سیستم مانیتورینگ بلافاصله به تیم پشتیبانی فنی و مهندسی سیستم هشدار اضطراری (Alert) ارسال می نماید.
• تیم فنی پس از اصلاح دستی داده ها یا انتشار هات فیکس (Hotfix)، می تواند پیام های موجود در DLQ را با ابزار های Replay مجدداً به چرخه اجرای ساگا بازگرداند.

۱۵. مقایسه جامع الگو های سازگاری داده در سیستم های توزیع شده

برای انتخاب صحیح میان الگو های مختلف معماری داده، باید تعادل ظریفی میان پیچیدگی پیاده سازی، هزینه های زیرساخت، نیازهای بیزینس به انطباق زمانی و بار محاسباتی برقرار گردد:

همان طور که جدول فوق نشان می دهد، در دنیای واقعی سیستم های مالی مدرن ترکیبی از الگوی ساگا را برای ارکستراسیون میان سرویس ها، و الگوی Event Sourcing را درون هر سرویس به عنوان منبع حقیقت (Single Source of Truth) به کار می گیرند. این ترکیب معماری، تضمین های سنگی ACID را بدون هیچ گونه قفل مخرب شبکه ای برای سازمان به ارمغان می آورد.