بچه‌ها بریم سراغ جواب اون سوال مصاحبه که قولش رو داده بودم. وقتی صحبت از استراتژی‌های کشینگ میشه، ما چند تا الگوی استاندارد داریم که بسته به سناریو و نیازمندی سیستم باید بهترینش رو انتخاب کنیم.

استراتژی اول: Cache Aside یا Lazy Loading

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

استراتژی دوم: Write Through

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


استراتژی سوم: Write Behind یا Write Back

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

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

رفرنس :

https://devscape.in/blog/caching-strategies

@codehalics | کدهالیک