عنوان:

‫اجرای کانتینرها در WSL با استفاده از #C: بررسی عمیق ابزار wslc و SDK نیتیو مایکروسافت


نویسنده: وحید نصیری
تاریخ: ۱۴۰۵/۰۴/۱۵ ۰۹:۴۵
آدرس: www.dntips.ir
مایکروسافت در جریان کنفرانس Build 2026، از قابلیت هیجان‌انگیز و بومی WSL Containers پرده برداشت. این ویژگی به توسعه‌دهندگان اجازه می‌دهد کانتینرهای لینوکسی (OCI) را به‌طور مستقیم، بدون نیاز به ابزارهای شخص ثالث مانند Docker Desktop، بر روی ویندوز و از طریق سیستم‌عامل فرعی ویندوز برای لینوکس (WSL) مدیریت و اجرا کنند.
این معماری جدید علاوه بر معرفی یک رابط خط فرمان (CLI) جدید به نام wslc، مجموعه‌ای از SDKها را برای زبان‌های C++ ،C و به‌ویژه #C ارائه داده است. در این مقاله، ابتدا به بررسی این ابزار خط فرمان پرداخته و سپس نحوه مدیریت کانتینرها را از درون کدهای دات‌نت بررسی می‌کنیم.

۱. پیش‌نیازها و راه‌اندازی اولیه
در حال حاضر این قابلیت در فاز پیش‌انتشار (Public Preview) قرار دارد. برای استفاده از آن، ابتدا باید WSL سیستم خود را به آخرین نسخه پیش‌انتشار به‌روزرسانی کنید.
خط فرمان (PowerShell یا CMD) خود را با دسترسی Administrator باز کرده و دستور زیر را اجرا کنید:
wsl --update --pre-release
پس از اتمام به‌روزرسانی، مطمئن شوید که نسخه WSL شما 2.9.3.0 یا بالاتر باشد:
wsl --version
خروجی باید چیزی مشابه زیر باشد:
WSL version: 2.9.3.0
Kernel version: 6.18.35.2-1

۲. آشنایی با wslc CLI: جایگزینی سبک برای کانتینرها
پس از ارتقا، ابزار خط فرمان جدیدی به نام wslc.exe (که به صورت پیش‌فرض با نام مستعار container.exe نیز در دسترس است) به محیط شما اضافه می‌شود. ساختار دستورات این CLI شباهت بسیاری به داکر دارد و کار با آن بسیار سرراست است.
به عنوان مثال، چند نمونه از دستورات پرکاربرد:
# دریافت یک ایمیج از داکر هاب
wslc pull alpine:latest

# اجرای یک دستور درون کانتینر و دریافت خروجی
wslc run alpine:latest cat /etc/alpine-release

# مشاهده لیست ایمیج‌های دانلود شده
wslc images

# مشاهده کانتینرهای فعال
wslc list
نکته: شما حتی می‌توانید سناریوهای پیچیده‌تر، مانند اجرای یک دسکتاپ کامل لینوکس یا اجرای پردازش‌های سنگین یادگیری ماشین متصل به GPU را با wslc انجام دهید:
wslc run --rm --gpus all pytorch/pytorch:2.5.1-cuda12.4-cudnn9-runtime python -c "import torch; print(torch.cuda.is_available())"

۳. معماری زیرساخت: چه چیزی در پشت صحنه تغییر کرده است؟
مایکروسافت برای افزایش کارایی کانتینرها در WSL، بهبودهای بنیادینی در سطح هسته و سیستم‌عامل اعمال کرده است که شناخت آن‌ها خالی از لطف نیست:
  • فایل‌سیستم virtiofs: این فایل‌سیستم جدید سرعت دسترسی و تبادل فایل بین ویندوز و کانتینر را تا ۲ برابر افزایش می‌دهد.
  • شبکه‌سازی پیشرفته (consomme): این حالت شبکه تجربی، ترافیک لینوکس را مستقیماً از لایه‌های ویندوز عبور می‌دهد. این کار مشکل همیشگی توسعه‌دهندگان با کانتینرها در محیط‌های سازمانی (مانند قطع شدن ارتباط به دلیل تغییرات VPN یا سیستم‌های پروکسی) را کاملاً برطرف می‌کند.
  • مکانیزم بهینه مدیریت حافظه (Memory Reclaim): برخلاف گذشته که WSL بخش زیادی از رم را اشغال نگه می‌داشت، در معماری جدید به محض کاهش مصرف کانتینر، حافظه RAM به سرعت و به صورت پویا به سیستم‌عامل میزبان (ویندوز) بازگردانده می‌شود.

۴. مدیریت برنامه‌نویسی کانتینرها با Microsoft.WSL.Containers SDK
یکی از جذاب‌ترین بخش‌های این به‌روزرسانی، امکان کنترل کامل چرخه حیات کانتینرها از درون کدهای #C است. برای این کار یک پکیج نیوگت (NuGet) رسمی ارائه شده است.

تنظیمات فایل پروژه (.csproj)
نکته بسیار مهمی که باید به آن توجه کنید این است که این پکیج از مکانیسم C#/WinRT Projection استفاده می‌کند. در نتیجه، پروژه دات‌نت شما باید حتماً پلتفرم هدف (Target Framework) خود را نسخه‌های ویندوزی مشخص کند. استفاده از پلتفرم خام مانند net11.0 خطا ایجاد خواهد کرد.
پیکربندی نمونه برای یک پروژه .NET 11:
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net11.0-windows10.0.19041.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.WSL.Containers" Version="2.9.3" />
  </ItemGroup>

</Project>

نمونه کد پیاده‌سازی
کد زیر نحوه ایجاد یک نشست (Session) ایزوله، دانلود ایمیج، نمونه‌سازی از کانتینر و اجرای یک دستور را نشان می‌دهد:
using Microsoft.WSL.Containers;

const string imageName = "alpine:latest";
var storagePath = Path.Combine(AppContext.BaseDirectory, "WslcStorage");

// ۱. ایجاد و شروع یک Session (یک ماشین مجازی سبک و ایزوله اختصاصی)
Console.WriteLine("[wslc] Starting session...");
using var session = new Session(new SessionSettings("DotNetUpSession", storagePath));
session.Start();

// ۲. دانلود ایمیج درون خطی به داخل این Session
Console.WriteLine("[wslc] Pulling image...");
session.PullImage(new PullImageOptions(imageName));

// ۳. پیکربندی و ساخت کانتینر
using Container container = session.CreateContainer(new ContainerSettings(imageName)
{
    InitProcess = new ProcessSettings { CommandLine = ["/bin/sleep", "infinity"] },
    EnableAutoRemove = true,
});

// ۴. استارت کانتینر
container.Start();

// ۵. اجرای یک دستور و خواندن خروجی از Standard Output به صورت رویدادمحور
using var waitHandle = new ManualResetEventSlim();
using Stream stdout = Console.OpenStandardOutput();

using Process process = container.CreateProcess(new ProcessSettings
{
    CommandLine = [
        "/bin/sh",
        "-c",
        "echo \"Hello from a WSL container running Alpine $(cat /etc/alpine-release)\""
    ],
    OutputMode = ProcessOutputMode.Event,
});

process.OutputReceived += data => stdout.Write(data, 0, data.Length);
process.Exited += _ => waitHandle.Set();

process.Start();
waitHandle.Wait(); // منتظر ماندن تا پایان اجرای دستور درون کانتینر

// ۶. پایان دادن به کار Session و آزادسازی منابع
Console.WriteLine("\n[wslc] Terminating session...");
session.Terminate();
Console.WriteLine("[wslc] Done.");

یک نکته معماری مهم درباره ایزولاسیون (Isolation)
محیطی که شما از طریق کد و با ساخت یک Session ایجاد می‌کنید، کاملاً جدا و مستقل از کانتینرهایی است که به صورت عمومی در wslc CLI سیستم مشاهده می‌کنید.
اگر تمایل دارید کانتینرها یا ایمیج‌های ساخته شده توسط کد دات‌نتی خود را از طریق خط فرمان ویندوز بررسی یا دیباگ کنید، باید نام سشن خود را به ساختار دستور پاس دهید:
wslc --session DotNetUpSession images
wslc --session DotNetUpSession container list

۵. قابلیت‌های سازمانی و توسعه تیمی
مایکروسافت این ویژگی را صرفاً برای استفاده‌های شخصی طراحی نکرده، بلکه هماهنگی کاملی با ابزارهای سازمانی به وجود آورده است:
  • مدیریت امنیت با Microsoft Defender for Endpoint (MDE): افزونه MDE در ویندوز اکنون تمام رویدادهای امنیتی درون این کانتینرها را مانیتور می‌کند.
  • اعمال سیاست با اینتون (Intune / GPO): مدیران شبکه می‌توانند استفاده از کانتینرهای WSL را محدود کرده یا یک لیست مجاز (Allowlist) از رجیستری‌های معتبر (مانند کانتینر رجیستری اختصاصی شرکت در Azure یا GitHub) تعریف کنند تا توسعه‌دهندگان نتوانند ایمیج‌های غیرمجاز را دانلود کنند.
  • پشتیبانی در VS Code Dev Containers: از نسخه 0.462.0-pre-release افزونه Dev Containers در VS Code، شما می‌توانید با تغییر تنظیمات Docker Path به wslc، محیط‌های توسعه ایزوله خود را مستقیماً روی کانتینرهای نیتیو ویندوز بالا بیاورید.

نتیجه‌گیری
آیا کانتینرهای بومی WSL قرار است به این زودی‌ها جایگزین داکر دسکتاپ شوند؟ پاسخ قطعاً منفی است. داکر دسکتاپ اکوسیستم بسیار وسیع‌تر و ابزارهای مدیریت بصری پیشرفته‌تری دارد. با این حال، معرفی wslc و SDK بومی دات‌نت، یک گزینه فوق‌العاده سبک، سریع و ادغام‌شده با سیستم‌عامل را در اختیار ما قرار می‌دهد. این ابزار کارایی بالایی در سناریوهایی نظیر خودکارسازی تست‌های نرم‌افزاری (Integration Tests)، اجرای خطوط لوله CI/CD محلی، یا توسعه ابزارهایی دارد که نیاز دارند به صورت برنامه‌نویسی‌شده فرآیندهای لینوکسی را در محیطی امن و ایزوله روی ویندوز اجرا کنند.

نظرات

  • مجید شهاب فر در ۱۴۰۵/۰۴/۲۰ ۰۰:۲۱
    آیا همچنان همه اینها در محیط توسعه استفاده می شوند؟
    مثلا در یک محیط Production آن هم بر روی یک سرور ویندوزی می توان از آن استفاده کرد؟
    • وحید نصیری در ۱۴۰۵/۰۴/۲۰ ۰۷:۵۴
      پاسخ کوتاه این است: بله، از نظر فنی می‌توانید از WSL Containers و SDK آن در محیط Production روی ویندوز سرور استفاده کنید، اما این کار با محدودیت‌ها و ملاحظات معماری مهمی همراه است که باید پیش از تصمیم‌گیری به آن‌ها توجه کنید:

      ۱. پشتیبانی در ویندوز سرور (Windows Server)
      از آنجا که این قابلیت بر پایه لایه‌های مدرن WSL (نسخه ۲) بنا شده است، برای استفاده از آن در Production، سرور شما باید از نسخه‌های جدیدتر ویندوز سرور (مانند Windows Server 2022 یا Windows Server 2025 با آخرین آپدیت‌ها) استفاده کند که از معماری کامل WSL 2 پشتیبانی می‌کنند. از آنجا که این ویژگی فعلاً در وضعیت Preview (پیش-انتشار) است، مایکروسافت آن را برای محیط‌های حیاتی (Mission-Critical) توصیه نمی‌کند تا زمانی که به وضعیت GA (عرضه عمومی) برسد.
      ۲
      . مقایسه معماری: چرا از کانتینرهای نیتیو ویندوز یا لینوکس استفاده نکنیم؟
      در یک محیط لینوکسی، کانتینرها مستقیماً روی هسته (Kernel) سیستم‌عامل اجرا می‌شوند و هیچ لایه اضافه‌ای وجود ندارد. اما در یک سرور ویندوزی، برای اجرای کانتینر لینوکس سه راهکار وجود دارد:
      • راهکار سنتی داکر (Docker EE / Mirantis): که عمدتاً برای اجرای کانتینرهای خودِ ویندوز (Windows Containers) مناسب است.
      • یک ماشین مجازی لینوکس مجزا (Hyper-V VM): که داکر یا ابزارهای دیگر روی آن نصب شده‌اند.
      • معماری جدید WSL Containers: که مایکروسافت ارائه داده است.
      مزیت بزرگ روش سوم (WSL) در محیط Production سرورهای ویندوزی، سبک بودن فوق‌العاده و مدیریت خودکار منابع است. به لطف قابلیت‌هایی مانند شبکه‌سازی consomme و سیستم مدیریت حافظه جدید، این کانتینرها سربار بسیار کمتری نسبت به یک ماشین مجازی کامل Hyper-V دارند.

      ۳. سناریوهای طلایی برای استفاده در Production روی ویندوز
      در چه مواردی استفاده از این فناوری در محیط عملیاتی (Production) ویندوز منطقی و بسیار کاربردی است؟
      • ادغام کدهای قدیمی و جدید (Legacy Integration): فرض کنید یک اپلیکیشن بزرگ سازمانی دارید که با دات‌نت فریم‌ورک قدیمی (مثلاً .NET Framework 4.8) نوشته شده و حتماً باید روی ویندوز سرور اجرا شود. حالا می‌خواهید یک سرویس جدید هوش مصنوعی یا پردازش تصویر لینوکسی (که فقط پایتون و لینوکس را پشتیبانی می‌کند) به آن اضافه کنید. با استفاده از این SDK، اپلیکیشن ویندوزی شما می‌تواند به صورت برنامه‌نویسی‌شده، آن پردازشگر لینوکسی را در یک کانتینر WSL در پشت صحنه مدیریت، اجرا و متوقف کند.
      • ابزارهای مانیتورینگ و خطوط لوله (Internal Tools & Pipelines): اگر روی سرور ویندوزی خود ابزارهای اتوماسیون داخلی یا سرویس‌های خط لوله (مثل رانرهای CI/CD) دارید، این ابزار یک جایگزین فوق‌العاده سریع و سبک برای اجرای جاب‌های لینوکسی است.
      • سرویس‌های ایزوله‌شده محلی (Micro-Services Architecture): برای سناریوهایی که نیاز دارید بخش‌هایی از پردازش برنامه دات‌نت خود را به دلایل امنیتی یا محدودیت منابع، در یک محیط کاملاً ایزوله (Sandbox) لینوکسی پیش ببرید.

      ۴. چالش‌ها و محدودیت‌ها در محیط Production
      اگر قصد دارید یک وب‌سایت با ترافیک بسیار بالا (High-Traffic Web Application) را به صورت کانتینری در Production بالا بیاورید، کانتینرهای WSL بهترین انتخاب نیستند. دلایل آن عبارتند از:
      • عدم هماهنگی با ارکستراتورها: ابزارهای مدیریت کانتینر در مقیاس بزرگ مانند کوبرنتیز (Kubernetes) یا Swarm به صورت نیتیو با wslc سازگار نیستند. برای کارهای بزرگ سازمانی، کوبرنتیز روی سرورهای لینوکس خام (Bare-metal) همچنان استاندارد اول دنیاست.
      • مایگریشن و جابجایی کانتینرها: پکیج‌های استاندارد داکر به راحتی جابجا می‌شوند، اما پکیج Microsoft.WSL.Containers وابستگی شدیدی به سیستم‌عامل میزبان (ویندوز و سشن‌های WSL آن) دارد که پورت‌پذیری (Portability) برنامه شما را محدود می‌کند.

      نتیجه‌گیری نهایی
      این فناوری صرفاً یک ابزار محیط توسعه نیست و پتانسیل بالایی برای محیط Production دارد؛ اما نه به عنوان بستری برای هاست کردن کانتینرهای عمومی وب‌سایت‌ها، بلکه بیشتر به عنوان یک پل ارتباطی قدرتمند و نیتیو (Native Bridge) برای برنامه‌نویسان دات‌نت تا بتوانند قدرت لینوکس و کانتینرها را مستقیماً از داخل کدهای #C در سرورهای ویندوزی به خدمت بگیرند.
      • مجید شهاب فر در ۱۴۰۵/۰۴/۲۴ ۱۰:۴۹
        ممنون.
        بیشتر هدف استفاده از برخی ابزار لینوکسی در محیط Production ویندوزی هست. مثل Redis
        • وحید نصیری در ۱۴۰۵/۰۴/۲۵ ۰۸:۰۹
          اگر هدف شما به طور خاص استفاده از ابزارهای معروفی مانند Redis (یا مواردی مثل Memcached و RabbitMQ) در محیط عملیاتی (Production) ویندوز سرور است، موضوع کمی متفاوت و بسیار جذاب‌تر می‌شود. از آنجا که توسعه‌دهندگان رسمی ردیس، نسخه نیتیو (بومی) برای ویندوز ارائه نمی‌دهند، راه‌اندازی ردیس روی ویندوز همیشه یک چالش بوده‌است. حال بیایید بررسی کنیم که آیا استفاده از WSL Containers / wslc برای اجرای ابزارهایی مثل Redis در پروداکشن سرورهای ویندوزی تصمیم درستی است یا خیر.

          ۱. معماری و راندمان اجرای Redis روی WSL Containers
          ردیس یک پایگاه داده درون‌حافظه‌ای (In-Memory) بسیار حساس به سرعت دسترسی به حافظه و شبکه است. وقتی شما Redis را از طریق کانتینر بومی WSL (wslc) اجرا می‌کنید، معماری زیرساختی سیستم به شکل زیر کار می‌کند:
          این معماری نسبت به روش‌های قدیمی، چند مزیت رقابتی مهم دارد:
          • شبکه بی‌واسطه (Consomme): با معرفی تکنولوژی شبکه‌سازی consomme در WSL جدید، ترافیک شبکه کانتینر مستقیماً از سوکت‌های ویندوز عبور می‌کند. این کار تاخیر شبکه (Latency) را که در حالت عادی به دلیل لایه‌های مجازی‌سازی ایجاد می‌شد، به شدت کاهش می‌دهد.
          • حافظه پویا (Dynamic RAM): از آنجا که Redis داده‌ها را در رم نگه می‌دارد، هماهنگی پویای WSL جدید در آزادسازی رم باعث می‌شود منابع ویندوز سرور هدر نروند.

          ۲. آیا برای یک Redis پروداکشن کارآمد است؟
          پاسخ به میزان بار کاری (Workload) و نوع استفاده شما بستگی دارد:
          الف) سناریوهای کاملاً مناسب (بله، استفاده کنید):
          • کش توزیع‌شده برای وب‌سایت‌های متوسط (Distributed Caching): اگر از ردیس برای نگهداری سشن‌ها (Session State) یا کش کردن نتایج کوئری‌های دات‌نت در یک وب‌سایت با ترافیک متوسط و نیمه‌سنگین استفاده می‌کنید، اجرای آن در کانتینر WSL روی همان سرور ویندوزی فوق‌العاده سریع و پایدار است.
          • پستچی پیام‌های داخلی (Message Broker / Pub-Sub): استفاده از Redis به عنوان واسط انتقال پیام بین پردازش‌های مختلف ویندوزی (Background Tasks) از طریق WSL بسیار روان انجام می‌شود.
          ب) سناریوهای غیربهینه (ترجیحاً استفاده نکنید):
          • ذخیره‌سازی اطلاعات حیاتی با حجم بالا (High-Throughput / Heavy Persistence): ردیس برای ذخیره دائمی داده‌ها روی دیسک از دستورالعمل‌های لینوکسی مانند fork() استفاده می‌کند. اگر حجم نوشتن داده در ردیس بسیار زیاد باشد، شبیه‌سازی لینوکس در ویندوز ممکن است تحت فشارهای فوق‌سنگین دچار افت فریم و کندی عملکرد دیسک شود.

          ۳. گزینه‌های جایگزین برای اجرای Redis روی ویندوز سرور
          اگر به هر دلیلی نخواهید از کانتینرهای WSL در لایه پروداکشن استفاده کنید، دو جایگزین رایج دیگر پیش روی شماست:
          • پروژه‌های بازنویسی شده برای ویندوز (مانند Memurai): ابزارهایی مانند Memurai یک موتور کاملاً سازگار با پروتکل Redis هستند که به طور نیتیو برای ویندوز نوشته شده‌اند و به عنوان یک Windows Service نصب می‌شوند. (البته برای استفاده‌های تجاری ممکن است نیاز به خرید لایسنس داشته باشند).
          • استفاده از سرویس‌های ابری (Managed Services): استفاده از سرویس‌های ابری مانند Azure Cache for Redis که خیال شما را از مدیریت زیرساخت ردیس کاملاً راحت می‌کند.

          نتیجه‌گیری عملیاتی برای کانتینر WSL
          استفاده از WSL Containers برای اجرای ابزارهای لینوکسی مثل Redis در محیط Production ویندوز، یک راه‌حل بسیار پایدارتر و با کارایی بالاتر نسبت به نسخه‌های قدیمی و غیررسمی ویندوزی ردیس است. اگر سناریوی شما کش کردن اطلاعات برنامه‌های دات‌نتی با حجم ترافیک معمول و نیمه‌سنگین است، این معماری نه‌تنها پاسخگوی نیازهای شماست، بلکه مدیریت آن از طریق کد سی‌شارپ (با همان SDK مایکروسافت که معرفی شد) فرآیند مانیتورینگ و نگهداری سرویس را بسیار ساده‌تر می‌کند.
          • مجید شهاب فر در ۱۴۰۵/۰۴/۲۵ ۲۱:۴۷
            منون از پاسخ دقیق و جامع.
            اگر سناریوی ما کش کردن اطلاعات برنامه‌های دات‌نتی با حجم ترافیک معمول و نیمه‌سنگین باشد آیا استفاده از IMemoryCache به جای Redis با WSL Containers توصیه نمیشود؟
            • وحید نصیری در ۱۴۰۵/۰۴/۲۶ ۰۸:۱۱
              پاسخ به این سوال، یکی از کلیدی‌ترین تصمیمات در طراحی معماری نرم‌افزار است. برای ترافیک معمول و نیمه‌سنگین، استفاده از IMemoryCache (کش درون‌پروسه‌ای یا In-Process) نه‌تنها توصیه می‌شود، بلکه در بسیاری از سناریوها گزینه بسیار بهتری نسبت به راه‌اندازی ردیس در کانتینر WSL است.
              برای انتخاب دقیق بین این دو، باید یک قانون طلایی را بررسی کنید: «آیا برنامه دات‌نتی شما روی یک سرور تک‌نمونه‌ای (Single Instance) اجرا می‌شود یا به صورت توزیع‌شده و چند سروری (Multi-Instance)؟»
              در ادامه تفاوت‌ها و دلایل انتخاب هر کدام را در این سناریو مرور می‌کنیم.

              چرا برای سناریوی شما، اولویت اول باید IMemoryCache باشد؟
              اگر وب‌سایت یا سرویس دات‌نتی شما روی یک سرور ویندوزی واحد اجرا می‌شود و نیازی به Load Balancer (متعادل‌کننده بار) ندارید، استفاده از IMemoryCache به شدت توصیه می‌شود:
              • سرعت فوق‌العاده (بدون تاخیر شبکه):IMemoryCache داده‌ها را مستقیماً داخل حافظه RAM اختصاصیِ خود پروسه دات‌نت (In-Process) ذخیره می‌کند. در این حالت، خواندن داده‌ها نیازی به هیچ ارتباط شبکه‌ای، فرآیند سریال‌سازی (Serialization) به JSON یا بایت، و لایه‌های مجازی‌سازی ندارد. سرعت آن عملاً در حد نانوثانیه است، در حالی که ردیس (حتی در سریع‌ترین حالت روی لوکال) به دلیل استفاده از سوکت‌های شبکه، تاخیری در حد میلی‌ثانیه دارد.
              • پیچیدگی صفر (Zero Maintenance): نیازی به نصب، پیکربندی، آپدیت و مدیریت سشن‌های WSL، کانتینرها، مانیتورینگ منابع مصرفی WSL و تنظیمات شبکه ندارید. همه‌چیز با تزریق وابستگی (Dependency Injection) پیش‌فرض دات‌نت و فراخوانی builder.Services.AddMemoryCache() فعال می‌شود.
              • عدم درگیری با چالش‌های لایسنس یا ناسازگاری لینوکس: شما بدون نیاز به هیچ ابزار واسط یا شبیه‌ساز لینوکسی، یک کش فوق‌العاده پایدار روی ویندوز دارید.

              چه زمانی IMemoryCache دیگر پاسخگو نیست و باید به سراغ Redis رفت؟
              با وجود مزایای بالا، اگر شرایط شما شامل موارد زیر است، استفاده از کش محلی توصیه نمی‌شود و باید به سراغ ردیس (از طریق کانتینر WSL یا ابزارهای دیگر) بروید:
              • نیاز به مقیاس‌پذیری افقی (Horizontal Scaling): اگر به‌خاطر ترافیک نیمه‌سنگین تصمیم دارید اپلیکیشن دات‌نت خود را روی ۲ یا چند سرور/سرویس مختلف بالا بیاورید (پشت Load Balancer)، استفاده از کش درون‌برنامه‌ای باعث ایجاد عدم همگام‌سازی (Cache Inconsistency) می‌شود. برای مثال، اگر کاربر روی سرور ۱ سبد خرید خود را آپدیت کند، سرور ۲ از این تغییر باخبر نخواهد شد. در این حالت، شما به یک کش توزیع‌شده (Distributed Cache) مثل Redis نیاز دارید که مرجع واحد اطلاعات تمام سرورها باشد.
              • بقا در هنگام ری‌استارت (Persistence & Lifespan): از آنجا که داده‌های IMemoryCache درون پروسه برنامه قرار دارند، با هر بار آپدیت اپلیکیشن، ری‌استارت شدن IIS یا کرش کردن برنامه، کل داده‌های کش‌شده پاک می‌شوند و با اولین درخواست‌ها، فشار سنگینی به دیتابیس وارد می‌شود تا کش دوباره ساخته شود (مسئله Cache Stampede). اما ردیس خارج از پروسه برنامه شماست و با ری‌استارت شدن اپلیکیشن، داده‌های آن حفظ می‌شوند.
              • محدودیت جدی حافظه رم اپلیکیشن: اگر حجم داده‌های کش شما بسیار زیاد است و نمی‌خواهید پروسه اصلی اپلیکیشن دات‌نت شما مقدار زیادی از رم سرور را اشغال کند، انتقال این بار به یک پردازش خارجی مثل کانتینر ردیس منطقی‌تر است.

              پیشنهاد بهتر دات‌نت: استفاده از HybridCache در .NET 9 و 11
              مایکروسافت در نسخه‌های اخیر دات‌نت قابلیتی به نام HybridCache معرفی کرده است که بهترینِ هر دو جهان را به شما می‌دهد.
              این ابزار به صورت دو لایه عمل می‌کند:
              • لایه اول (L1 - سریع‌ترین): داده‌ها ابتدا درون حافظه محلی خود برنامه (IMemoryCache) جستجو می‌شوند تا در کسری از میلی‌ثانیه پاسخ داده شوند.
              • لایه دوم (L2 - توزیع‌شده): اگر داده در لایه اول نبود، سیستم به صورت خودکار به سراغ کش توزیع‌شده (مانند Redis که روی WSL Containers راه‌اندازی کرده‌اید) می‌رود و در صورت وجود، آن را به لایه اول نیز اضافه می‌کند تا در درخواست‌های بعدی سریع‌تر خوانده شود.
              همچنین HybridCache به صورت پیش‌فرض جلوی مشکل همزمانی شدید درخواست‌ها برای یک داده‌ی کش‌نشده (Stampede Protection) را می‌گیرد.

              جمع‌بندی تصمیم‌گیری
              • اگر برنامه شما روی یک سرور تک ویندوزی هاست شده است: قطعاً IMemoryCache را انتخاب کنید و خود را درگیر کانتینر و ردیس نکنید.
              • اگر برنامه شما توزیع‌شده (چند سرور یا چند کانتینر) است یا می‌خواهید با ری‌استارت شدن اپلیکیشن کش شما از بین نرود: از Redis (مثلاً روی WSL) استفاده کنید.
              • اگر می‌خواهید بهترین کارایی را با کمترین تاخیر شبکه داشته باشید: از HybridCache دات‌نت استفاده کنید که تلفیقی هوشمندانه از هر دو لایه است.