انواع سیستم های کش در دات نت ؛ راهنمای جامع و کاربردی افزایش سرعت نرم افزار

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

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

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

استفاده اصولی از حافظه موقت (Cache) به عنوان هوشمندانه ترین راهکار مهندسی، ارتباط برنامه با دیتابیس را بهینه می سازد. اگر مایل هستید نرم افزار دات نت شما زیر ترافیک سنگین بدون افت کارایی به کار خود ادامه دهد، این راهنمای جامع دیدگاهی عمیق به شما خواهد داد.

---

کش چیست و چرا در اکوسیستم دات نت نقشی حیاتی دارد؟

کش یک لایه ذخیره سازی پرسرعت بین منطق برنامه (Business Logic) و منابع ذخیره سازی اصلی نظیر پایگاه داده است. این لایه نسخه ای از داده های پرتقاضا را در حافظه رم با سرعت دسترسی نانوثانیه نگهداری می کند. در نتیجه هنگامی که کلاینت درخواستی تکراری می فرستد، سیستم بدون مراجعه مجدد به دیسک یا شبکه، پاسخ را مستقیما از حافظه بازمی گرداند.

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

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

به صورت کلی سیستم های کش بر مبنای دو وضعیت کلیدی تصمیم گیری می کنند:

• موفقیت در بازیابی (Cache Hit): حالتی است که داده مورد نظر در حافظه موقت وجود دارد و سیستم بدون معطلی آن را در اختیار کاربر می گذارد.
• عدم موفقیت (Cache Miss):** شرایطی است که داده در حافظه یافت نمی شود و برنامه ناچار می شود رکورد را از پایگاه داده اصلی واکشی کند.

---

۱. کش درون حافظه (In-Memory Caching) با IMemoryCache

ساده ترین و سریع ترین روش ذخیره سازی موقت در فریم ورک دات نت، کش درون حافظه است. برنامه نویسان در این روش، داده ها را مستقیما در فضای رم همان پردازه ای که هاست ASP.NET Core روی آن در حال اجرا است نگه می دارند.

ویژگی ها و موارد کاربرد In-Memory Cache

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

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

پیاده سازی عملی IMemoryCache در کد نویسی

فریم ورک دات نت امکانات فوق العاده ای برای رجیستر کردن و مدیریت این ابزار دارد. ابتدا در فایل Program.cs سرویس مربوطه را فعال می کنیم:

// ثبت سرویس کش درون حافظه در کانتینر DI
builder.Services.AddMemoryCache(options =>
{
    options.SizeLimit = 1024; // تعیین سقف مجاز حافظه بر حسب واحد دلخواه
});

سپس در کلاس سرویس یا کنترلر، اینترفیس IMemoryCache را تزریق کرده و آیتم ها را مدیریت می نماییم:

public class ProductService
{
    private readonly IMemoryCache _cache;
    private readonly ApplicationDbContext _context;

    public ProductService(IMemoryCache cache, ApplicationDbContext context)
    {
        _cache = cache;
        _context = context;
    }

    public async Task<Product> GetProductByIdAsync(int id)
    {
        string cacheKey = $"product_{id}";

        if (!_cache.TryGetValue(cacheKey, out Product product))
        {
            // در صورت عدم وجود داده، رکورد را از پایگاه داده می خوانیم
            product = await _context.Products.FindAsync(id);

            if (product != null)
            {
                var cacheEntryOptions = new MemoryCacheEntryOptions()
                    .SetSlidingExpiration(TimeSpan.FromMinutes(5))
                    .SetAbsoluteExpiration(TimeSpan.FromHours(1))
                    .SetSize(1)
                    .SetPriority(CacheItemPriority.High);

                _cache.Set(cacheKey, product, cacheEntryOptions);
            }
        }

        return product;
    }
}

تنظیم همزمان Absolute Expiration و Sliding Expiration در قطعه کد بالا یک الگوی استاندارد محسوب می شود. انقضای لغزنده زمان اعتبار کش را با هر بار واکشی تمدید می کند، اما انقضای مطلق تضمین خواهد داد که داده نهایتا بعد از یک ساعت از دیتابیس تازه سازی شود.

---

۲. کش توزیع شده (Distributed Caching) با IDistributedCache

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

با افزایش ترافیک، کش توزیع شده نقش آفرینی می کند. در این مدل، یک سرویس مستقل مانند Redis یا Memcached وظیفه نگهداری متمرکز داده های مشترک را بر دوش می کشد. تمام سرورهای وب فعال به همین پایگاه متصل می شوند و داده های یکسانی را مشاهده می کنند.

اگر یکی از سرورهای وب ری استارت یا خاموش شود، هیچ اختلالی در کش رخ نخواهد داد. این ساختار بار پردازشی دیتابیس اصلی را سبک می کند. شما می توانید برای مقایسه عملکرد کوئری ها، مطلب بهینه سازی Query های پیچیده SQL Server را مطالعه فرمایید.

پیاده سازی عملی کش توزیع شده با Redis در دات نت

ردیس به عنوان یک پایگاه داده NoSQL کلید-مقدار، محبوب ترین بستر برای کش اشتراکی است. ابتدا پکیج Microsoft.Extensions.Caching.StackExchangeRedis را به پروژه اضافه می کنیم.

سپس در فایل Program.cs تنظیمات اتصال ردیس را ثبت می کنیم:

// پیکربندی کش توزیع شده مبتنی بر ردیس
builder.Services.AddStackExchangeRedisCache(options =>
{
    options.Configuration = builder.Configuration.GetConnectionString("RedisConnection");
    options.InstanceName = "TarahanNovin_";
});

جهت ذخیره و بازیابی رکوردها به کمک IDistributedCache، تبدیل اشیاء به رشته متنی JSON ضروری خواهد بود:

public class DistributedUserService
{
    private readonly IDistributedCache _distributedCache;

    public DistributedUserService(IDistributedCache distributedCache)
    {
        _distributedCache = distributedCache;
    }

    public async Task<UserProfile> GetUserProfileAsync(string userId)
    {
        string cacheKey = $"user_{userId}";
        string cachedData = await _distributedCache.GetStringAsync(cacheKey);

        if (!string.IsNullOrEmpty(cachedData))
        {
            return JsonSerializer.Deserialize<UserProfile>(cachedData);
        }

        // شبیه سازی واکشی داده از منبع اصلی
        var userProfile = new UserProfile { Id = userId, FullName = "کاربر تستی" };

        var options = new DistributedCacheEntryOptions()
            .SetAbsoluteExpiration(TimeSpan.FromMinutes(30))
            .SetSlidingExpiration(TimeSpan.FromMinutes(10));

        string serializedData = JsonSerializer.Serialize(userProfile);
        await _distributedCache.SetStringAsync(cacheKey, serializedData, options);

        return userProfile;
    }
}

برای آگاهی از تنظیمات تکمیلی شبکه و مدیریت کلاستر ردیس می توانید به مستندات کش توزیع شده در سایت مایکروسافت مراجعه فرمایید.

---

۳. نسل نوین کش هیبریدی (HybridCache) در دات نت ۹

توسعه دهندگان سال ها مجبور بودند میان سرعت خارق العاده In-Memory و یکپارچگی Distributed Cache یکی را برگزینند، یا با نوشتن کدهای پیچیده یک معماری دو لایه بسازند. مهندسان مایکروسافت در دات نت ۹ با معرفی کتابخانه HybridCache این چالش قدیمی را ریشه کن کردند.

مزایای رقابتی HybridCache در معماری مدرن

این بستر جدید، یک معماری هوشمند دو سطحی L1 و L2 را مدیریت می کند:

• لایه محلی (L1 – In-Memory): داده در حافظه رم محلی سرور قرار می گیرد تا دسترسی های پرتکرار بدون کوچک ترین تاخیر شبکه ای خوانده شوند.
• لایه بیرونی (L2 – Distributed): در صورت تعریف یک پرووایدر نظیر ردیس، کپی داده به کش مرکزی انتقال می یابد تا میان سایر نودها به اشتراک درآید.

قابلیت برجسته دیگر HybridCache، پیشگیری ذاتی از رخداد مخرب Cache Stampede است. زمانی که اعتبار یک کلید تمام می شود و صدها کاربر همزمان صفحه را باز می کنند، این سیستم با ایجاد یک قفل ایمن فقط یک درخواست را به سمت دیتابیس می فرستد.

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

نحوه کد نویسی و ثبت HybridCache در دات نت ۹

پیاده سازی این مکانیزم ساختاری بسیار روان و یکدست دارد:

// ثبت سرویس هیبرید کش در دات نت 9
builder.Services.AddHybridCache(options =>
{
    options.MaximumPayloadBytes = 1024 * 1024; // سقف حجم داده برای ذخیره در L1
    options.DefaultEntryOptions = new HybridCacheEntryOptions
    {
        Expiration = TimeSpan.FromMinutes(20),
        LocalCacheExpiration = TimeSpan.FromMinutes(5)
    };
});

فراخوانی و بازیابی رکوردها به کمک متد هوشمند GetOrCreateAsync انجام می گیرد:

public class ArticleService
{
    private readonly HybridCache _hybridCache;
    private readonly ApplicationDbContext _db;

    public ArticleService(HybridCache hybridCache, ApplicationDbContext db)
    {
        _hybridCache = hybridCache;
        _db = db;
    }

    public async Task<ArticleDto> GetArticleAsync(int id, CancellationToken ct)
    {
        string cacheKey = $"article_{id}";

        return await _hybridCache.GetOrCreateAsync(
            cacheKey,
            async cancelToken =>
            {
                // این قطعه کد زیر بار ترافیک شدید فقط یک بار اجرا می شود
                var article = await _db.Articles.FindAsync([id], cancelToken);
                return new ArticleDto(article.Id, article.Title, article.Content);
            },
            cancellationToken: ct
        );
    }
}

این متد کلیه جزئیات سریال سازی داده ها و همگام سازی وظایف ناهمگام را در پشت صحنه کنترل می کند و خطوط کد برنامه را تمیز نگه می دارد.

---

۴. کش خروجی (Output Caching) و کش پاسخ (Response Caching)

تا این بخش روی کش کردن داده های انتزاعی تمرکز داشتیم. اما در لایه وب، کش کردن خروجی کامل HTTP راندمان پاسخگویی اندپوینت ها را به حداکثر می رساند.

تفاوت Response Caching و Output Caching

مفهوم Response Caching با متکی بودن بر هدرهای پروتکل HTTP نظیر Cache-Control کار می کند. وظیفه اصلی آن راهنمایی مرورگرها و پراکسی های CDN برای ذخیره پاسخ است.

در طرف مقابل، Output Caching که از دات نت ۷ معرفی شد، بدنه پاسخ را در سمت وب سرور ذخیره می نماید. بنابراین حتی اگر مرورگر کاربر هدر no-cache بفرستد، سیستم دات نت خروجی را از کش بازمی گرداند.

پیاده سازی Output Caching با برچسب گذاری (Tags)

قابلیت تگ گذاری امکان باطل کردن گروهی کش ها را به آسانی فراهم می کند:

// فعال سازی میان افزار در Program.cs
builder.Services.AddOutputCache(options =>
{
    options.AddBasePolicy(builder => builder.Expire(TimeSpan.FromMinutes(10)));
    options.AddPolicy("ProductCatalogPolicy", builder => 
        builder.Expire(TimeSpan.FromMinutes(30)).Tag("catalog"));
});

var app = builder.Build();
app.UseOutputCache();

// اعمال کش خروجی روی اندپوینت API
app.MapGet("/api/catalog", async (CatalogService service) =>
{
    return Results.Ok(await service.GetCatalogAsync());
}).CacheOutput("ProductCatalogPolicy");

هنگامی که داده های کاتالوگ در پنل مدیریت تغییر می کنند، برنامه نویس با یک دستور ساده تمام صفحات وابسته را ابطال می نماید:

// ابطال هدفمند و بلادرنگ حافظه با برچسب مشخص
await outputCacheStore.EvictByTagAsync("catalog", default);

---

الگوهای کاربردی کش گذاری در معماری نرم افزار

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

• الگوی Cache-Aside: برنامه نویس ابتدا کش را می خواند؛ اگر رکوردی نیافت، اطلاعات را از دیتابیس استخراج کرده و درون کش قرار می دهد. این رویکرد انعطاف پذیرترین مدل در وب سرویس ها است.
• الگوی Write-Through: هرگاه داده جدیدی ذخیره می شود، سیستم همزمان کش و دیتابیس را آپدیت می کند. این متد جلوی ناهماهنگی اطلاعات را می گیرد.
• الگوی Write-Behind: برنامه ابتدا تغییرات را با سرعت در کش می نویسد و سپس فرآیندی در پس زمینه، دیتابیس اصلی را به روز می کند. این روش برای لاگ های حجیم بسیار کارآمد است.
• الگوی Refresh-Ahead: سیستم قبل از سررسید انقضای کلید، داده ها را بر اساس تحلیل رفتاری کاربران تازه سازی می کند تا برنامه همواره سریع بماند.

---

چالش های عملیاتی و امنیتی مدیریت کش

به کارگیری کش اگر با دقت کافی همراه نباشد، می تواند چالش هایی در محیط پروداکشن به وجود آورد:

• ابطال داده های نامعتبر (Cache Invalidation): چنانچه داده های دیتابیس تغییر کنند اما کلیدهای کش منقضی نشوند، کاربران با اطلاعات قدیمی مواجه خواهند شد. استفاده از سیستم های پیام رسان نظیر RabbitMQ یا تگ های Output Cache این معضل را برطرف می سازد.
• امنیت داده های حساس: ذخیره اطلاعات هویتی و محرمانه بدون رمزنگاری در فضاهای اشتراکی مانند ردیس، امنیت نرم افزار را تهدید می کند. همیشه مقادیر حساس را قبل از کش گذاری رمزنگاری نمایید.
• مدیریت ظرفیت حافظه (Eviction Policies): اگر فضای رم پر شود، دات نت یا سرور ردیس بر اساس الگوریتم هایی نظیر LRU آیتم های کم استفاده را پاک می کنند. تنظیم درست این سیاست ها جلوی افت ناگهانی پرفورمنس را می گیرد. شما می توانید جزئیات فنی مدل های ذخیره سازی را در صفحه مستندات انواع داده های ردیس مطالعه فرمایید.

---

جدول مقایسه جامع انواع سیستم های کش در دات نت

برای ارزیابی سریع و انتخاب آگاهانه، ویژگی های هر ابزار را در جدول زیر خلاصه کرده ایم:

---

نتیجه گیری و انتخاب استراتژی هوشمندانه

انتخاب مناسب ترین سیستم کش در دات نت ارتباط مستقیمی با حجم ترافیک، ابعاد سیستم و رفتار کاربران دارد. برای اپلیکیشن های جمع وجور، IMemoryCache سریع ترین پاسخگویی را ارائه می دهد. اما اگر به سمت مقیاس پذیری و چند سروره شدن حرکت می کنید، ترکیب ردیس با سیستم نوین HybridCache دات نت ۹ پایدارترین نتایج را رقم می زند.

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