الگوی Saga

مشکل: تراکنش در چند سرویس

مشتری یک خرید انجام می‌دهد. سیستم باید چهار کار انجام دهد: سفارش را ثبت کند، کالا را در انبار رزرو کند، پول را بگیرد و بسته را ارسال کند.

در یک Monolith با یک دیتابیس، کار ساده است. همه را داخل یک تراکنش می‌گذاریم. اگر یک قدم شکست بخورد، دیتابیس همه را برمی‌گرداند (Rollback).

ولی در Microservices، هر سرویس دیتابیس خودش را دارد. تراکنش مشترک نداریم.

حالا فرض کن پول گرفته شد، ولی انبار گفت «این کالا تمام شده». در سیستم ما:

• پول مشتری کم شده است.
• کالایی برای ارسال نیست.
• هیچ دیتابیسی این را خودکار برنمی‌گرداند.

Saga راه حل همین مشکل است.

چرا تراکنش توزیع‌شده (2PC) نه؟

یک راه قدیمی تراکنش دو مرحله‌ای (Two-Phase Commit) است. یک هماهنگ‌کننده از همه دیتابیس‌ها می‌پرسد «آماده‌ای؟». اگر همه گفتند بله، به همه می‌گوید «ثبت کن». این روش در Microservices معمولاً مناسب نیست:

1. قفل طولانی. تا آخرین سرویس جواب ندهد، همه رکوردها قفل می‌مانند.
2. وابستگی به همه. اگر یک سرویس یا هماهنگ‌کننده از کار بیفتد، بقیه منتظر می‌مانند.
3. پشتیبانی کم. Kafka، RabbitMQ، Redis و بیشتر دیتابیس‌های NoSQL در 2PC شرکت نمی‌کنند.

ایده Saga: قدم‌های کوچک و کار جبرانی

کار بزرگ را به چند تراکنش محلی تقسیم می‌کنیم. هر سرویس فقط تراکنش دیتابیس خودش را انجام می‌دهد. برای هر قدم، یک کار جبرانی (Compensation) هم می‌نویسیم که اثر آن قدم را خنثی می‌کند.

سه نوع قدم داریم:

1. قدم قابل جبران. اگر بعداً مشکلی پیش آمد، کار جبرانی دارد. مثل رزرو کالا.
2. قدم بی‌بازگشت (Pivot). اگر این قدم موفق شود، Saga دیگر برنمی‌گردد. در مثال ما، گرفتن پول.
3. قدم تکرارشونده. بعد از نقطه بی‌بازگشت می‌آید و باید آخر کار موفق شود. اگر شکست خورد، دوباره تلاش می‌کنیم. مثل ارسال بسته.

مثال زنده

یک سناریو را انتخاب کن و ببین Saga قدم به قدم چه می‌کند:

جبران، Rollback نیست

Rollback دیتابیس طوری رفتار می‌کند که انگار هیچ اتفاقی نیفتاده است. ولی در Saga، هر قدم واقعاً انجام شده و ممکن است دیگران آن را دیده باشند.

برای همین، کار جبرانی یک کار کسب‌وکاری است، نه یک حذف ساده. مثلاً اگر سفارشی بعد از پرداخت لغو شود، جبرانِ پرداخت «برگشت پول» است. رکورد پرداخت را پاک نمی‌کنیم. یک رکورد برگشت پول اضافه می‌کنیم.

دو روش اجرا: Choreography و Orchestration

روش اول: Choreography (هر سرویس به رویداد قبلی گوش می‌دهد)

هیچ مدیری وجود ندارد. هر سرویس کارش را انجام می‌دهد و یک رویداد می‌فرستد. سرویس بعدی به آن رویداد گوش می‌دهد.

روش دوم: Orchestration (یک مدیر، دستور می‌دهد)

یک بخش به اسم Orchestrator کل جریان را می‌داند. به هر سرویس دستور می‌دهد، جواب را می‌گیرد و قدم بعدی را تصمیم می‌گیرد.

کد

نسخه ساده برای فهمیدن ایده

هر قدم که موفق شد، کار جبرانی‌اش را روی یک پشته (Stack) می‌گذاریم. اگر قدمی شکست خورد، کارهای جبرانی را به ترتیب برعکس اجرا می‌کنیم.

public sealed class PlaceOrderSaga(
    IOrders orders, IWarehouse warehouse, IPayments payments, IShipping shipping)
{
    public async Task RunAsync(Order order, CancellationToken ct)
    {
        var compensations = new Stack<Func<Task>>();
        try
        {
            await orders.CreateAsync(order, ct);
            compensations.Push(() => orders.CancelAsync(order.Id));

            await warehouse.ReserveAsync(order.Id, order.Items, ct);
            compensations.Push(() => warehouse.ReleaseAsync(order.Id));

            await payments.ChargeAsync(order.Id, order.Total, ct);
            // Pivot: after a successful payment we only move forward.
        }
        catch
        {
            while (compensations.TryPop(out var compensate))
                await compensate();
            throw;
        }

        await shipping.ShipWithRetryAsync(order.Id, ct);
    }
}

نسخه واقعی: وضعیت در دیتابیس

در Production، وضعیت هر Saga باید در دیتابیس ذخیره شود. کتابخانه MassTransit این کار را با State Machine انجام می‌دهد. هر سفارش یک ردیف وضعیت دارد. هر پیام، Saga را از یک وضعیت به وضعیت بعدی می‌برد:

public sealed class OrderState : SagaStateMachineInstance
{
    public Guid CorrelationId { get; set; }          // = OrderId
    public string CurrentState { get; set; } = "";
}

public sealed class OrderSaga : MassTransitStateMachine<OrderState>
{
    public State Reserving { get; private set; } = null!;
    public State Paying { get; private set; } = null!;
    public State Completed { get; private set; } = null!;
    public State Cancelled { get; private set; } = null!;

    public Event<OrderCreated> OrderCreated { get; private set; } = null!;
    public Event<StockReserved> StockReserved { get; private set; } = null!;
    public Event<StockFailed> StockFailed { get; private set; } = null!;
    public Event<PaymentDone> PaymentDone { get; private set; } = null!;
    public Event<PaymentFailed> PaymentFailed { get; private set; } = null!;

    public OrderSaga()
    {
        // Every message has a CorrelationId (the OrderId),
        // so MassTransit finds the right saga row by itself.
        InstanceState(x => x.CurrentState);

        Initially(
            When(OrderCreated)
                .Publish(ctx => new ReserveStock(ctx.Saga.CorrelationId))
                .TransitionTo(Reserving));

        During(Reserving,
            When(StockReserved)
                .Publish(ctx => new ChargePayment(ctx.Saga.CorrelationId))
                .TransitionTo(Paying),
            When(StockFailed)
                .Publish(ctx => new CancelOrder(ctx.Saga.CorrelationId))
                .TransitionTo(Cancelled));

        During(Paying,
            When(PaymentDone)
                .Publish(ctx => new ShipOrder(ctx.Saga.CorrelationId))
                .TransitionTo(Completed),
            When(PaymentFailed)
                .Publish(ctx => new ReleaseStock(ctx.Saga.CorrelationId))
                .Publish(ctx => new CancelOrder(ctx.Saga.CorrelationId))
                .TransitionTo(Cancelled));
    }
}

این کد دقیقاً همان شکل بالا است. هر خط During یک وضعیت است. هر When یک پیام است که Saga منتظر آن است. وضعیت را می‌شود با EF Core یا Redis ذخیره کرد.

قانون‌های مهم

1. هر قدم و هر کار جبرانی Idempotent باشد. پیام ممکن است دو بار برسد. اگر «آزاد کردن کالا» دو بار اجرا شود، نباید دو برابر کالا آزاد شود. با شناسه سفارش چک کن که قبلاً انجام شده یا نه.
2. کار جبرانی نباید شکست نهایی بخورد. اگر خطا داد، با فاصله دوباره تلاش کن. اگر بعد از چند بار باز هم نشد، به صف خطا (Dead Letter) بفرست و به یک آدم هشدار بده. هیچ وقت آن را بی‌صدا رها نکن.
3. وضعیت Saga را ذخیره کن. بعد از restart، Saga باید از همان قدمی که بود ادامه دهد.
4. تغییر دیتابیس و ارسال پیام با هم باشد. از الگوی Outbox استفاده کن. وگرنه ممکن است دیتابیس تغییر کند، ولی پیام هیچ وقت ارسال نشود.
5. Timeout بگذار. اگر سرویس انبار هیچ وقت جواب نداد، Saga نباید تا ابد منتظر بماند. بعد از مدت مشخص، جبران را شروع کن.
6. کار جبرانی ممکن است قبل از خود کار برسد. مثلاً «لغو رزرو» قبل از «رزرو» برسد. سرویس باید این را ثبت کند تا وقتی «رزرو» رسید، آن را انجام ندهد.

اشتباه‌های رایج

چه وقت Saga؟