‫بازنگری در استراتژی کش‌گذاری: آیا باید همه‌چیز را کش کرد؟

چکیده: در مهندسی عملکرد سامانه‌های نرم‌افزاری مدرن، کش‌گذاری اغلب به عنوان نخستین و در دسترس‌ترین راه‌حل برای جبران کندی پایگاه داده قلمداد می‌شود. با این حال، رویکرد ساده‌انگارانه «کش کردن همه‌چیز» نه تنها تضمین‌کننده مقیاس‌پذیری نیست، بلکه چالش‌های ساختاری متعددی نظیر مصرف غیربهینه حافظه، ناسازگاری داده‌ها (Data Inconsistency) و پیچیدگی ابطال کش (Cache Invalidation) را به سامانه تحمیل می‌کند. این مقاله مفهومی تحت عنوان «منطق خاکستری» (Grey Logic) را معرفی می‌کند؛ چارچوبی تصمیم‌گیری بر مبنای تحلیل چندبعدی فرکانس دسترسی، نرخ تغییرات داده، هزینه محاسباتی و میزان تحمل کسب‌وکار در برابر کهنگی داده (Data Staleness). علاوه بر این، راهکارهای عملیاتی نظیر لایه‌بندی حافظه پنهان، الگوهای ابطال رویدادمحور و مقابله با آسیب‌پذیری‌های همروندی نظیر کشند هجوم کش (Cache Stampede) در اکوسیستم دات‌نت مورد بحث و پیاده‌سازی قرار گرفته است.

• داده چه زمانی خوانده می‌شود؟ (الگوی دسترسی)
• داده چه زمانی نامعتبر می‌شود؟ (نرخ نوسان)
• هزینه خواندن یا محاسبه آن چقدر است؟ (سربار سربارگیری)
• تراز خطای کسب‌وکار چقدر است؟ (تحمل کهنگی)

نرخ دسترسی (Access Frequency)
                           ▲
                           │     کاندیدای ایده‌آل
               کش بیهوده     │    (Ideal Candidate)
                           │
       ────────────────────┼────────────────────► نرخ تغییرات (Volatility)
                           │
       عدم کش‌گذاری  │     ریسک بالای ناسازگاری
                           │

• فرکانس دسترسی (Access Frequency): داده‌ای که روزانه ۲ بار خوانده می‌شود، حتی با تغییرات ماهانه یک بار، نیازی به حافظه پنهان ندارد. کش نیازمند مدیریت حافظه، رصد و اعتبارسنجی است که برای چنین فرکانسی توجیه فنی ندارد.
• نرخ نوسان (Data Volatility): عمر داده در کش مستقیماً از آهنگ تغییر داده در منبع اصلی (Source of Truth) تبعیت می‌کند.
• هزینه پردازش یا واکشی (Query/Compute Cost): واکشی یک کوئری ساده بر روی جدول ایندکس‌شده با تاخیر ۲ میلی‌ثانیه نسبت به یک تجمیع چندجدولی سنگین با تاخیر ۴۰۰ میلی‌ثانیه، اولویت بسیار کمتری برای کش‌گذاری دارد.

نکته: حتی داده‌های شدیداً پویا مانند قیمت سهام را می‌توان برای مدت ۵۰۰ میلی‌ثانیه کش کرد. در سامانه‌های پرترافیک، این بازه ناچیز می‌تواند هزاران کوئری مکرر و همزمان به دیتابیس را حذف کند بدون اینکه به تجربه کاربر خدشه‌ای وارد شود.

• فشار بر Garbage Collector دات‌نت: تخصیص بیش از حد اشیاء بزرگ در حافظه پنهان محلی می‌تواند منجر به ارتقای غیرضروری داده‌ها به نسل ۲ (Gen 2) و بخش LOH (Large Object Heap) شود که توقف‌های طولانی‌مدت GC را در پی دارد.
• دوگانگی واقعیت (Split-Brain / Stale Data): هنگامی که دیتابیس آپدیت شده اما کش همچنان مقدار قدیمی را ارائه می‌دهد.
• کشند هجوم کش (Cache Stampede / Thundering Herd): وضعیتی که یک کلید پرطرفدار منقضی می‌شود و صدها درخواست همزمان به طور موازی تلاش می‌کنند پایگاه داده را برای محاسبه مجدد آن تحت فشار قرار دهند.

using System.Collections.Concurrent;
using Microsoft.Extensions.Caching.Memory;

public class CountryService
{
    private readonly IMemoryCache _cache;
    private readonly AppDbContext _dbContext;
    
    // مدیریت قفل‌های مجزا به ازای هر کلید کش برای جلوگیری از قفل شدن کل سامانه
    private static readonly ConcurrentDictionary<string, SemaphoreSlim> _locks = new();

    public CountryService(IMemoryCache cache, AppDbContext dbContext)
    {
        _cache = cache;
        _dbContext = dbContext;
    }

    public async Task<IReadOnlyCollection<Country>> GetCountriesAsync(CancellationToken cancellationToken = default)
    {
        const string cacheKey = "ref_countries";

        // گام اول: تلاش برای خواندن مستقیم از کش (Fast Path)
        if (_cache.TryGetValue(cacheKey, out IReadOnlyCollection<Country>? cachedCountries))
        {
            return cachedCountries!;
        }

        // دریافت یا ایجاد سمافور جهت همگام‌سازی دسترسی همزمان به دیتابیس
        var keyLock = _locks.GetOrAdd(cacheKey, _ => new SemaphoreSlim(1, 1));
        await keyLock.WaitAsync(cancellationToken);

        try
        {
            // گام دوم: بررسی مجدد کش پس از ورود به قفل (Double-Check Pattern)
            if (_cache.TryGetValue(cacheKey, out cachedCountries))
            {
                return cachedCountries!;
            }

            // خواندن بدون رهگیری (No-Tracking) برای بهینه‌سازی تخصیص حافظه EF Core
            var countries = await _dbContext.Countries
                .AsNoTracking()
                .ToListAsync(cancellationToken);

            var cacheOptions = new MemoryCacheEntryOptions
            {
                // زمان انقضای مطلق بر اساس ماهیت تغییرات اندک داده مرجع
                AbsoluteExpirationRelativeToNow = TimeSpan.FromHours(12),
                
                // زمان انقضای لغزنده در صورت عدم استفاده
                SlidingExpiration = TimeSpan.FromHours(2),
                
                // تعیین اولویت حفظ در حافظه هنگام مواجهه با کمبود منابع
                Priority = CacheItemPriority.High
            };

            _cache.Set(cacheKey, countries, cacheOptions);

            return countries;
        }
        finally
        {
            keyLock.Release();
        }
    }
}

نکته معماری دات‌نت: در پروژه‌های مدرن مبتنی بر دات‌نت ۹، کتابخانه HybridCache به عنوان راه‌حلی پیش‌فرض جهت ترکیب L1 (حافظه محلی درون‌برنامه‌ای) و L2 (کش توزیع‌شده نظیر Redis) استفاده می‌شود که به شکل توکار قابلیت محافظت در برابر Cache Stampede را نیز در خود جای داده است.

• نسبت موفقیت کش (Cache Hit Ratio): نسبت درخواست‌های پاسخ‌داده‌شده از کش به کل درخواست‌ها. مقدار کمتر از ۵۰٪ اغلب نشانه طراحی نادرست کلیدها یا کوتاه بودن بیش از حد TTL است.
• نرخ تخلیه اجباری (Eviction Rate): سرریز حافظه که منجر به دور انداختن کلیدها پیش از انقضای واقعی می‌شود.
• تاخیر قبل و بعد از کش‌گذاری: آیا کاهش مراجعات دیتابیس، هزینه سریال‌سازی (Serialization Cost) در کش‌های توزیع‌شده را توجیه می‌کند؟