‫Cache Stampede: وقتی کش به جای محافظت، به دشمن سیستم تبدیل می‌شود

public async Task<Report> GetReportAsync(string key)
{
    if (_cache.TryGetValue(key, out Report cached))
    {
        return cached;
    }

    var report = await _reportService.BuildExpensiveReportAsync(key);

    _cache.Set(key, report, TimeSpan.FromSeconds(60));

    return report;
}

private static readonly ConcurrentDictionary<string, SemaphoreSlim> _locks = new();

public async Task<Report> GetReportAsync(string key)
{
    if (_cache.TryGetValue(key, out Report cached))
    {
        return cached;
    }

    var keyLock = _locks.GetOrAdd(key, _ => new SemaphoreSlim(1, 1));

    await keyLock.WaitAsync();
    try
    {
        // بررسی دوباره: ممکن است در حالی که منتظر آزاد شدن
        // سمافور بودیم، درخواست دیگری کش را بازسازی کرده باشد.
        if (_cache.TryGetValue(key, out cached))
        {
            return cached;
        }

        var report = await _reportService.BuildExpensiveReportAsync(key);
        _cache.Set(key, report, TimeSpan.FromSeconds(60));
        return report;
    }
    finally
    {
        keyLock.Release();
    }
}

• رشد نامحدود دیکشنری قفل‌ها:ConcurrentDictionary هیچ‌گاه به‌طور خودکار پاک‌سازی نمی‌شود؛ اگر فضای کلیدها کوچک و محدود باشد مشکلی ایجاد نمی‌کند، اما برای فضای کلیدهای بزرگ یا نامحدود (مثلاً کلیدهایی که شامل شناسه کاربر یا پارامترهای پویا هستند)، باید مکانیزمی برای حذف سمافورهای استفاده‌نشده در نظر بگیرید، یا به‌جای آن از راهکارهای مبتنی بر کتابخانه که در ادامه توضیح داده می‌شوند استفاده کنید.
• محدود بودن به یک نمونه (Instance) از برنامه: این قفل فقط در محدوده‌ی یک پردازه (Process) عمل می‌کند. اگر برنامه روی چند سرور یا چند نمونه (مثلاً پشت یک Load Balancer) اجرا شود، هر نمونه قفل مستقل خودش را دارد و ممکن است همزمان چند نمونه، همان کوئری را روی دیتابیس اجرا کنند. برای رفع این محدودیت به قفل توزیع‌شده (Distributed Lock) نیاز است که در ادامه به آن اشاره می‌شود.

services.AddHybridCache(options =>
{
    options.DefaultEntryOptions = new HybridCacheEntryOptions
    {
        Expiration = TimeSpan.FromSeconds(60),
        LocalCacheExpiration = TimeSpan.FromSeconds(60)
    };
});

public async Task<Report> GetReportAsync(string key, HybridCache cache)
{
    return await cache.GetOrCreateAsync(
        key,
        async cancel => await _reportService.BuildExpensiveReportAsync(key, cancel),
        cancellationToken: default);
}

var jitter = TimeSpan.FromSeconds(Random.Shared.Next(0, 10));
_cache.Set(key, report, TimeSpan.FromSeconds(60) + jitter);

• برای یک یا چند نقطه‌ی داغ مشخص در یک سرویس کوچک، یک قفل ساده به‌ازای هر کلید با SemaphoreSlim شما را تا حد زیادی به هدف می‌رساند، به‌شرط رعایت الگوی Double-Checked Locking و توجه به مدیریت طول عمر قفل‌ها.
• برای پروژه‌های بزرگ‌تر یا زمانی که این الگو در چندین سرویس تکرار می‌شود، استفاده از HybridCache انتخاب منطقی‌تری است، چون این قابلیت را به‌صورت آماده و بدون نیاز به کد اضافه در اختیار می‌گذارد و به‌عنوان یک راهکار رسمی و پشتیبانی‌شده از سوی مایکروسافت، هزینه نگهداری کمتری دارد.
• اگر علاوه بر محافظت در برابر Stampede، به رفتار Fail-Safe نیز نیاز دارید — یعنی می‌خواهید در صورت از دسترس خارج شدن موقت بک‌اند، برنامه همچنان آخرین مقدار معتبر کش را برگرداند به‌جای شکست کامل — کتابخانه‌هایی مانند FusionCache یا مشابه آن ارزش بررسی و افزودن به پروژه را دارند.
• در نهایت، صرف‌نظر از راهکاری که انتخاب می‌کنید، افزودن Jitter به زمان انقضا یک بیمه‌ی کم‌هزینه و ساده در برابر انقضاهای همزمان است و بهتر است همیشه به‌عنوان یک عادت خوب در طراحی کش، در نظر گرفته شود.