Microsoft Orleans

مشکل: میلیون‌ها سبد خرید

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

راه معمول این است که هر تغییر را مستقیم در دیتابیس بنویسیم. ولی:

1. دیتابیس زیر بار می‌رود. هر کلیک یعنی یک خواندن و یک نوشتن.
2. همزمانی دردسر دارد. کاربر در دو تب همزمان کالا اضافه می‌کند و یکی از تغییرها گم می‌شود.
3. کش کردن سخت است. اگر سبد را در حافظه یک سرور نگه داریم، درخواست بعدی شاید به سرور دیگری برود.

ایده Actor اینجا کمک می‌کند: یک Actor برای هر سبد. ولی چه کسی میلیون‌ها Actor را بسازد، روی سرورها پخش کند و بعد از restart دوباره بسازد؟ Orleans همین کار را می‌کند.

ایده اصلی: Actor مجازی

در Orleans به هر Actor یک Grain می‌گوییم. به هر سرور هم یک Silo. چند Silo با هم یک کلاستر می‌سازند.

فرق بزرگ Orleans با Actor های کلاسیک این است: Grain همیشه وجود دارد. نه ساختن لازم است و نه از بین بردن.

1. هر Grain یک شناسه دارد. مثلاً سبد خرید علی.
2. کد فقط شناسه را می‌خواهد. اگر Grain در حافظه نباشد، Orleans همان لحظه آن را روی یکی از Silo ها فعال می‌کند.
3. هر Grain در هر لحظه معمولاً فقط یک نسخه فعال در کل کلاستر دارد. پس همه درخواست‌های سبد علی به یک جا می‌روند.
4. اگر Silo بمیرد، پیام بعدی Grain را روی Silo دیگری فعال می‌کند. کد ما هیچ تغییری نمی‌بیند.

به همین دلیل به آن Virtual Actor می‌گوییم. مثل حافظه مجازی: تو فقط آدرس را داری و سیستم می‌داند داده واقعاً کجاست.

کد یک Grain

اول رابط Grain. همه متدها async هستند، چون ممکن است Grain روی سرور دیگری باشد:

public interface ICartGrain : IGrainWithStringKey
{
    Task AddItem(string productId, int quantity);
    Task<IReadOnlyDictionary<string, int>> GetItems();
}

بعد خود Grain. وضعیت آن به صورت خودکار از دیتابیس خوانده می‌شود:

[GenerateSerializer]
public sealed class CartState
{
    [Id(0)] public Dictionary<string, int> Items { get; set; } = [];
}

public sealed class CartGrain(
    [PersistentState("cart", "carts")] IPersistentState<CartState> cart) : Grain, ICartGrain
{
    public async Task AddItem(string productId, int quantity)
    {
        // No lock: Orleans runs one request at a time for this grain.
        cart.State.Items[productId] = cart.State.Items.GetValueOrDefault(productId) + quantity;
        await cart.WriteStateAsync();
    }

    public Task<IReadOnlyDictionary<string, int>> GetItems()
        => Task.FromResult<IReadOnlyDictionary<string, int>>(cart.State.Items.AsReadOnly());
}

راه‌اندازی Silo و استفاده از Grain در یک API:

var builder = WebApplication.CreateBuilder(args);

builder.UseOrleans(silo =>
{
    silo.UseLocalhostClustering();          // for local development only
    silo.AddMemoryGrainStorage("carts");    // use a real database in production
});

var app = builder.Build();

app.MapPost("/carts/{customerId}/items", async (
    string customerId, AddItemRequest request, IGrainFactory grains) =>
{
    var cart = grains.GetGrain<ICartGrain>(customerId);   // no "new", no lookup
    await cart.AddItem(request.ProductId, request.Quantity);
    return Results.NoContent();
});

app.Run();

public sealed record AddItemRequest(string ProductId, int Quantity);

تک‌نخی بودن: هم مزیت، هم تله

هر Grain به طور پیش‌فرض Non-Reentrant است. یعنی:

1. یک درخواست شروع می‌شود.
2. اگر وسط کار await کند، Grain درخواست دیگری را شروع نمی‌کند. صبر می‌کند تا همین درخواست کامل تمام شود.
3. پس بین دو await، هیچ درخواست دیگری وضعیت را عوض نمی‌کند.

این عالی است: داخل Grain هیچ قفلی لازم نیست. ولی یک تله بزرگ هم دارد.

بن‌بست: وقتی دو Grain منتظر هم هستند

سبد علی موقع تسویه حساب، از Grain تخفیف می‌پرسد «تخفیف این سبد چقدر است؟». Grain تخفیف برای محاسبه، اقلام سبد را لازم دارد. پس دوباره سبد علی را صدا می‌زند.

// CartGrain
public async Task<decimal> Checkout()
{
    var discounts = GrainFactory.GetGrain<IDiscountGrain>(0);
    var discount = await discounts.Calculate(this.GetPrimaryKeyString()); // waits...
    return discount;
}

// DiscountGrain
public async Task<decimal> Calculate(string cartId)
{
    var cart = GrainFactory.GetGrain<ICartGrain>(cartId);
    var items = await cart.GetItems(); // queued behind Checkout: deadlock
    return items.Count >= 3 ? 0.1m : 0m;
}

قدم به قدم:

1. سبد درخواست Checkout را شروع می‌کند و منتظر جواب تخفیف می‌ماند.
2. از نظر Orleans، Checkout هنوز تمام نشده است. پس درخواست دیگری به سبد داده نمی‌شود.
3. تخفیف درخواست GetItems را به سبد می‌فرستد. این درخواست در صف، پشت Checkout می‌ماند.
4. حالا یک چرخه داریم. Checkout منتظر تخفیف است، تخفیف منتظر GetItems، و GetItems منتظر تمام شدن Checkout.
5. هیچ کدام جلو نمی‌روند. بعد از زمان انتظار پیش‌فرض (سی ثانیه)، فراخوانی با خطای Timeout شکست می‌خورد.

راه‌ها، از بهتر به بدتر

1. چرخه را در طراحی حذف کن. سبد، اقلامش را همراه درخواست بفرستد. دیگر تماس برگشتی لازم نیست.

var discount = await discounts.Calculate(cart.State.Items.AsReadOnly());

2. اجازه ورود دوباره فقط برای همین زنجیره. متد AllowCallChainReentrancy از کلاس RequestContext فقط به درخواست‌هایی که از همین زنجیره برمی‌گردند اجازه ورود می‌دهد.

using var scope = RequestContext.AllowCallChainReentrancy();
var discount = await discounts.Calculate(this.GetPrimaryKeyString());

3. متدهای فقط‌خواندنی را علامت بزن. با attribute های ReadOnly یا AlwaysInterleave روی متد GetItems در رابط، این متد می‌تواند وسط کارهای دیگر اجرا شود.
4. کل Grain را Reentrant کن. ساده‌ترین راه است، ولی خطرناک‌ترین هم هست. بین دو await، درخواست دیگری می‌تواند وضعیت را عوض کند. همان Race Condition که از آن فرار کرده بودیم برمی‌گردد.

Grain داغ

فرض کن یک Grain داریم که تعداد کل سفارش‌های امروز را می‌شمارد. همه سفارش‌ها آن را صدا می‌زنند. با اضافه کردن Silo هم سریع‌تر نمی‌شود. چرا؟

1. این Grain فقط یک نسخه فعال دارد، روی یک Silo.
2. درخواست‌ها را یکی‌یکی اجرا می‌کند.
3. پس Silo بیشتر به یک Grain تنها کمکی نمی‌کند.

راه‌ها:

• شمارنده را تقسیم کن. مثلاً شانزده شمارنده جزئی بر اساس شناسه سفارش، و یک Grain که هر چند ثانیه آن‌ها را جمع می‌کند.
• تغییرها را دسته‌ای بفرست، به جای یک تماس برای هر سفارش.
• برای کار بدون وضعیت، StatelessWorker. این نوع Grain می‌تواند چند نسخه همزمان داشته باشد.

چند ابزار دیگر Orleans

• تایمر و یادآور (Timer و Reminder). تایمر فقط تا وقتی Grain فعال است کار می‌کند. یادآور ذخیره می‌شود و حتی Grain غیرفعال را بیدار می‌کند.
• جریان (Stream). برای فرستادن رویداد از یک Grain به چند Grain دیگر، بدون منتظر ماندن.
• متدهای یک‌طرفه (OneWay). فرستنده منتظر جواب نمی‌ماند. برای کارهایی که جواب لازم ندارند.

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

چه وقت Orleans؟