حل مشکل Invalidating کش توزیع‌شده با Redis و HybridCache 🧠🚀
سیستم‌های توزیع‌شده برای مقیاس‌پذیری عالی هستند، اما یک کلاس کاملاً جدید از مشکلات را هم معرفی می‌کنند. یکی از سخت‌ترین این مشکلات، cache invalidation است. ⚠️
در NET 9.، مایکروسافت کتابخانه‌ای به نام HybridCache معرفی کرد تا فرآیند caching را ساده‌تر کند. این یک کتابخانه فوق‌العاده است که سرعت کش در حافظه (L1) را با پایداری کش توزیع‌شده (L2) مثل Redis ترکیب می‌کند. همچنین به‌صورت پیش‌فرض از محافظت در برابر cache stampede پشتیبانی می‌کند. 🛡
اما یک نکته وجود دارد. ❗️
وقتی چندین instance از اپلیکیشن خود را اجرا می‌کنید، HybridCache به‌صورت خودکار کش محلی L1 را بین تمام نودها همگام‌سازی نمی‌کند. اگر داده‌ای روی Node A به‌روزرسانی شود، Node B همچنان داده‌ی قدیمی را از کش درون‌حافظه‌ای خودش برمی‌گرداند تا زمانی که آن entry منقضی شود. ⏳
در حالی که HybridCache یک گام بزرگ رو به جلو است، نبود یک backplane داخلی برای invalidation یک محدودیت شناخته‌شده است. در واقع، یک بحث فعال در ریپازیتوری GitHub مربوط به dotnet/extensions وجود دارد که دقیقاً همین feature request را دنبال می‌کند. تا زمانی که این قابلیت ارائه شود، مجبوریم خودمان راه‌حل بسازیم. 🛠
در این خبرنامه بررسی می‌کنیم:
• معضل کش توزیع‌شده 🌍
• چرا HybridCache به‌تنهایی این مشکل را حل نمی‌کند 🤔
• استفاده از Redis Pub/Sub به‌عنوان backplane 📡
• پیاده‌سازی invalidation بلادرنگ کش ⚡️
بیایید شروع کنیم. 👇
معضل کش توزیع‌شده (The Distributed Caching Dilemma)
بیایید یک سناریوی معمول در محیط production را تصور کنیم. شما یک API دارید که روی چندین سرور (یا pod) پشت یک load balancer اجرا می‌شود. ⚙️
برای بهبود performance، از caching استفاده می‌کنید. سرعت حافظه محلی را می‌خواهید، پس از HybridCache استفاده می‌کنید. 🚀
سناریوی شکست به این صورت است:
• کاربر A پروفایل خود را روی Server 1 به‌روزرسانی می‌کند. 👤
• ءServer 1 دیتابیس را آپدیت می‌کند و کش محلی خودش را پاک می‌کند. 🗑
• کاربر A (یا کاربر B) به Server 2 درخواست می‌زند. 🔁
• ءServer 2 هنوز داده‌ی قدیمی پروفایل را در HybridCache محلی خودش نگه داشته است. 🧊
• کاربر اطلاعات قدیمی را می‌بیند، چون کش محلی invalidate نشده است. 😕