وقتی یک پروژه Laravel کوچک است، معمولاً اجرای مستقیم Queryهای دیتابیس مشکل خاصی ایجاد نمی‌کند. اما با افزایش تعداد کاربران و درخواست‌ها، شرایط تغییر می‌کند.
فرض کنید صفحه‌ای دارید که در هر درخواست اطلاعات زیر را از دیتابیس دریافت می‌کند:
- لیست دسته‌بندی‌ها
- تنظیمات سایت
- محصولات محبوب
- آخرین مقالات
- اطلاعات آماری
- منوهای سایت
اگر این اطلاعات در هر درخواست دوباره از دیتابیس خوانده شوند، تعداد Queryها به‌مرور افزایش پیدا می‌کند و فشار بیشتری به Database وارد می‌شود.
اینجاست که Cache وارد معماری برنامه می‌شود.
Cache به ما اجازه می‌دهد نتیجه عملیات‌های پرتکرار را برای مدت مشخصی ذخیره کنیم و در درخواست‌های بعدی، به‌جای انجام دوباره عملیات، داده ذخیره‌شده را سریع‌تر در اختیار کاربر قرار دهیم.
Laravel یک سیستم Cache قدرتمند و استاندارد دارد که می‌تواند با Storeهای مختلفی مانند File، Database و Redis کار کند.
در این مقاله از صفر با Cache در Laravel آشنا می‌شویم و در ادامه نحوه استفاده صحیح از آن در پروژه‌های واقعی را بررسی می‌کنیم.
Cache چیست؟
Cache یا کش، محلی برای نگهداری موقت داده‌هایی است که احتمال دارد دوباره مورد استفاده قرار بگیرند.
هدف اصلی Cache این است که از انجام دوباره عملیات‌های پرهزینه جلوگیری کند.
برای مثال فرض کنید اجرای این Query زمان‌بر باشد:
$products = Product::where('status', 'active')
->latest()
->take(20)
->get();
اگر این Query در هر درخواست اجرا شود، دیتابیس باید بارها همان اطلاعات را پردازش کند.
اما می‌توان نتیجه را Cache کرد:
Request
↓
Cache
↓
داده وجود دارد؟
├── بله → استفاده از Cache
│
└── خیر
↓
Database
↓
ذخیره در Cache
↓
Response
در نتیجه درخواست‌های بعدی می‌توانند بدون اجرای دوباره Query از داده Cache شده استفاده کنند.
# چرا Cache در Laravel مهم است؟
یکی از مهم‌ترین دلایل استفاده از Cache، کاهش هزینه پردازش و افزایش سرعت پاسخ‌گویی برنامه است.
فرض کنید یک Query سنگین دارید که 300 میلی‌ثانیه زمان می‌برد.
اگر این Query در هر درخواست اجرا شود:
1000 Request
×
300ms Query
می‌تواند فشار زیادی به Database وارد کند.
اما اگر نتیجه برای چند دقیقه Cache شود، بسیاری از درخواست‌ها بدون اجرای دوباره Query پاسخ داده می‌شوند.
در این حالت:
Request
↓
Cache
↓
Response
به همین دلیل Cache یکی از ابزارهای مهم در بهینه‌سازی Application است.
# Cache در Laravel چگونه کار می‌کند؟
Laravel یک API یکپارچه برای Cache در اختیار توسعه‌دهنده قرار می‌دهد.
یعنی شما معمولاً لازم نیست در تمام قسمت‌های برنامه بدانید داده دقیقاً در کجا ذخیره شده است.
برای مثال:
use Illuminate\Support\Facades\Cache;
Cache::put('site_name', 'CMSNevis', 3600);
برای دریافت:
$siteName = Cache::get('site_name');
اگر بعداً تصمیم بگیرید Store مربوط به Cache را تغییر دهید، کد Application تا حد زیادی بدون تغییر باقی می‌ماند.
این یکی از مزیت‌های مهم سیستم Cache لاراول است.
# Cache Store چیست؟
Cache Store مشخص می‌کند داده‌های Cache در کجا ذخیره شوند.
Laravel می‌تواند با Storeهای مختلفی کار کند.
برخی گزینه‌های رایج عبارت‌اند از:
| Store | محل ذخیره |
|---|---|
| File | فایل‌های روی سرور |
| Database | جدول دیتابیس |
| Redis | Redis |
| Memcached | Memcached |
| Array | حافظه موقت Application |
انتخاب Store به نیاز پروژه بستگی دارد.
برای یک پروژه کوچک ممکن است File Cache کافی باشد.
برای یک پروژه بزرگ‌تر ممکن است Redis انتخاب مناسب‌تری باشد.
# File Cache در Laravel
File Cache یکی از ساده‌ترین روش‌های ذخیره Cache است.
در این روش اطلاعات Cache به‌صورت فایل در Storage مربوط به Laravel ذخیره می‌شوند.
مزیت اصلی File Cache این است که برای استفاده از آن معمولاً به سرویس جداگانه‌ای مانند Redis نیاز ندارید.
بنابراین برای پروژه‌های کوچک یا محیط Development می‌تواند گزینه مناسبی باشد.
اما برای پروژه‌های بزرگ و پرترافیک، معمولاً باید گزینه‌های مناسب‌تری را بررسی کرد.
# Database Cache در Laravel
در Database Cache اطلاعات Cache داخل Database ذخیره می‌شوند.
این روش زمانی می‌تواند مفید باشد که نمی‌خواهید سرویس جداگانه‌ای مثل Redis راه‌اندازی کنید.
اما باید توجه داشت که Cache کردن داده در همان Database اصلی همیشه به معنی کاهش فشار روی Database نیست.
اگر هدف اصلی شما کاهش بار دیتابیس است، استفاده از Database به‌عنوان Cache ممکن است آن نتیجه‌ای را که انتظار دارید ایجاد نکند.
# Redis Cache در Laravel
Redis یکی از گزینه‌های محبوب برای Cache در پروژه‌های Laravel است.
Redis اطلاعات را عمدتاً در حافظه نگهداری می‌کند و برای عملیات سریع روی داده‌ها بسیار مناسب است.
معماری معمول:
Laravel
│
├── MySQL
│
└── Redis
└── Cache
در مقاله قبلی درباره Redis در Laravel به‌صورت کامل درباره اتصال Laravel به Redis و کاربردهای آن صحبت کردیم.
در این مقاله تمرکز ما روی API مربوط به Cache است.
# تنظیم Cache Store در Laravel
در پروژه‌های Laravel جدید می‌توانید Store مربوط به Cache را از طریق Environment تنظیم کنید.
برای مثال:
CACHE_STORE=redis
یا بسته به معماری پروژه می‌توانید Store دیگری را انتخاب کنید.
تنظیمات دقیق Storeها در Configuration مربوط به Cache پروژه قرار دارد.
اگر تنظیمات .env را تغییر دادید و Laravel همچنان مقدار قبلی را استفاده کرد، Configuration Cache را بررسی کنید:
php artisan config:clear
در Production نیز پس از اطمینان از تنظیمات می‌توانید Configuration را Cache کنید:
php artisan config:cache
# Cache::put در Laravel
یکی از ساده‌ترین روش‌های ذخیره داده در Cache، استفاده از put است.
use Illuminate\Support\Facades\Cache;
Cache::put('site_name', 'CMSNevis', 3600);
در این مثال:
Key:
site_name
Value:
CMSNevis
TTL:
3600 seconds
پس مقدار موردنظر برای مدت مشخصی در Cache ذخیره می‌شود.
# TTL چیست؟
TTL مخفف:
Time To Live
است.
TTL مشخص می‌کند یک داده چه مدت در Cache باقی بماند.
مثلاً:
Cache::put('site_name', 'CMSNevis', 3600);
یعنی Cache برای این داده یک زمان انقضا در نظر گرفته شده است.
TTL برای داده‌هایی که ممکن است تغییر کنند اهمیت زیادی دارد.
برای مثال:
تنظیمات سایت → TTL طولانی
قیمت محصول → TTL کوتاه‌تر
آمار لحظه‌ای → TTL بسیار کوتاه
مدت مناسب TTL به نوع داده بستگی دارد.
# Cache::get در Laravel
برای دریافت داده از Cache:
$value = Cache::get('site_name');
اگر کلید وجود داشته باشد، مقدار آن برگردانده می‌شود.
اگر وجود نداشته باشد، نتیجه معمولاً null خواهد بود.
می‌توانید مقدار پیش‌فرض هم مشخص کنید:
$value = Cache::get('site_name', 'Default Name');
در این حالت اگر site_name وجود نداشته باشد، مقدار Default Name برگردانده می‌شود.
# بررسی وجود Cache با has
اگر فقط می‌خواهید بدانید یک Cache وجود دارد یا خیر:
if (Cache::has('site_name')) {
// Cache exists
}
این روش برای بررسی وجود یک کلید مفید است.
# حذف Cache با forget
برای حذف یک مقدار:
Cache::forget('site_name');
این عملیات زمانی بسیار مهم است که داده اصلی تغییر کرده باشد.
مثلاً:
$product->update($data);
Cache::forget('product:' . $product->id);
در اینجا بعد از تغییر محصول، Cache قبلی آن حذف می‌شود.
# پاک کردن تمام Cache
در شرایط خاص ممکن است بخواهید Cache مربوط به Application را پاک کنید.
برای مدیریت Cacheهای Laravel می‌توانید از Artisan استفاده کنید:
php artisan cache:clear
اما نباید از پاک کردن کل Cache به‌عنوان راه‌حل همیشگی برای مشکلات Application استفاده کنید.
اگر مشکل از Configuration باشد، بهتر است Configuration Cache را مدیریت کنید:
php artisan config:clear
اگر مشکل از Route Cache باشد:
php artisan route:clear
و برای View Cache:
php artisan view:clear
هر Cache باید متناسب با نوع خودش مدیریت شود.
# Cache::remember چیست؟
یکی از مهم‌ترین و کاربردی‌ترین متدهای Cache در Laravel، remember است.
این متد برای سناریوی زیر بسیار مناسب است:
> اگر داده در Cache وجود دارد، آن را برگردان؛ اگر وجود ندارد، داده را تولید کن، ذخیره کن و برگردان.
مثلاً:
$products = Cache::remember('products', 3600, function () {
return Product::latest()->get();
});
Laravel ابتدا Cache را بررسی می‌کند.
اگر products وجود داشته باشد:
Cache
↓
Return
اگر وجود نداشته باشد:
Cache
↓
Not Found
↓
Database
↓
Store in Cache
↓
Return
این الگو یکی از پرکاربردترین روش‌های Cache کردن Queryهای Laravel است.
# Cache::remember در یک پروژه واقعی
فرض کنید یک سایت خبری دارید.
در صفحه اصلی آخرین 10 مقاله نمایش داده می‌شوند:
$posts = Cache::remember('homepage:posts', 600, function () {
return Post::query()
->where('status', 'published')
->latest('published_at')
->take(10)
->get();
});
در این مثال:
Cache Key:
homepage:posts
TTL:
600 seconds
در نتیجه Query فقط زمانی اجرا می‌شود که Cache وجود نداشته باشد یا منقضی شده باشد.
# Cache::rememberForever
برای داده‌هایی که به‌ندرت تغییر می‌کنند، می‌توان از Cache دائمی استفاده کرد:
$settings = Cache::rememberForever('site:settings', function () {
return SiteSetting::all();
});
اما عبارت «دائمی» را نباید به معنای ذخیره همیشگی و بدون مدیریت در نظر گرفت.
اگر داده‌ای با rememberForever ذخیره شود، باید هنگام تغییر داده اصلی Cache آن را به‌صورت دستی پاک یا بازسازی کنید.
مثلاً:
SiteSetting::update($data);
Cache::forget('site:settings');
# Cache::add چیست؟
گاهی می‌خواهیم یک مقدار فقط زمانی ذخیره شود که کلید موردنظر از قبل وجود نداشته باشد.
برای این کار می‌توان از add استفاده کرد:
Cache::add('process:lock', true, 60);
اگر کلید از قبل وجود داشته باشد، مقدار جدید جایگزین نمی‌شود.
این قابلیت در بعضی سناریوهای هماهنگ‌سازی و جلوگیری از اجرای تکراری عملیات مفید است.
# افزایش و کاهش مقدار Cache
Laravel امکان کار با مقادیر عددی Cache را نیز فراهم می‌کند.
برای افزایش:
Cache::increment('page_views');
برای افزایش با مقدار مشخص:
Cache::increment('page_views', 5);
و برای کاهش:
Cache::decrement('page_views');
این قابلیت برای شمارنده‌هایی مانند تعداد بازدید، تعداد عملیات یا بعضی آمارهای موقت کاربرد دارد.
# Cache Key چیست؟
هر داده Cache شده با یک Key شناسایی می‌شود.
مثلاً:
products
یا:
product:25
یا:
category:12:products
انتخاب Key مناسب بسیار مهم است.
برای پروژه‌های بزرگ بهتر است یک الگوی مشخص داشته باشید.
مثلاً:
product:{id}
category:{id}:products
user:{id}:profile
homepage:latest-products
settings:site
این ساختار باعث می‌شود مدیریت Cache بسیار ساده‌تر شود.
# چرا Cache Key خوب مهم است؟
فرض کنید کلیدهای پروژه شما این شکلی باشند:
data1
data2
data3
test
cache1
newdata
بعد از مدتی مشخص نیست هر کلید مربوط به چه چیزی است.
اما اگر از ساختار مشخص استفاده کنید:
product:15
product:20
category:5:products
user:10:permissions
به‌راحتی می‌توان فهمید هر Cache مربوط به چه بخشی است.
# Cache Invalidation چیست؟
یکی از مهم‌ترین مفاهیم در سیستم‌های Cache، Cache Invalidation است.
به زبان ساده:
> چه زمانی باید Cache قبلی را حذف یا به‌روزرسانی کنیم؟
فرض کنید محصولی در دیتابیس داریم:
Product #25
Price = 500,000
قیمت محصول در Cache هم ذخیره شده است.
حالا قیمت در Database تغییر می‌کند:
Database:
700,000
Cache:
500,000
اگر Cache حذف یا به‌روزرسانی نشود، کاربر ممکن است قیمت قدیمی را ببیند.
بنابراین بعد از تغییر داده باید سیاست مشخصی برای Cache داشته باشید.
# یک مثال صحیح برای Cache Invalidation
فرض کنید اطلاعات محصول را Cache کرده‌ایم:
$product = Cache::remember(
'product:' . $id,
3600,
fn () => Product::findOrFail($id)
);
وقتی محصول تغییر می‌کند:
$product->update($data);
Cache::forget('product:' . $product->id);
در درخواست بعدی:
Cache
↓
Not Found
↓
Database
↓
New Data
↓
Cache
به این ترتیب داده جدید دوباره Cache می‌شود.
# Cache کردن Queryهای Eloquent
یکی از رایج‌ترین کاربردهای Cache در Laravel، Cache کردن نتیجه Queryهای Eloquent است.
مثلاً:
$categories = Cache::remember(
'categories:active',
3600,
fn () => Category::where('active', true)->get()
);
این روش مخصوصاً برای داده‌هایی مناسب است که:
- زیاد خوانده می‌شوند
- کم تغییر می‌کنند
- تولید آنها هزینه دارد
# چه چیزهایی را نباید Cache کنیم؟
هر داده‌ای الزاماً گزینه مناسبی برای Cache نیست.
مثلاً اگر داده‌ای:
- دائماً تغییر می‌کند
- حجم بسیار زیادی دارد
- فقط یک بار استفاده می‌شود
- تولید آن بسیار ارزان است
ممکن است Cache کردن آن ارزش خاصی نداشته باشد.
مثلاً اگر یک Query بسیار ساده دارید:
$user = User::find($id);
و فقط در یک بخش محدود از Application استفاده می‌شود، Cache کردن آن الزاماً تصمیم خوبی نیست.
Cache باید برای کاهش هزینه واقعی استفاده شود، نه صرفاً به این دلیل که امکان Cache کردن داده وجود دارد.
# چه داده‌هایی برای Cache مناسب هستند؟
معمولاً داده‌های زیر گزینه‌های خوبی هستند:
تنظیمات سایت
site settings
دسته‌بندی‌ها
categories
منوها
menus
داده‌های پرتکرار
popular products
popular posts
Queryهای سنگین
complex reports
statistics
aggregations
داده‌های کم‌تغییر
configuration
permissions
metadata
# Cache کردن API Response
Cache فقط مخصوص Query دیتابیس نیست.
اگر یک API خارجی را فراخوانی می‌کنید و نتیجه برای چند دقیقه قابل استفاده است، می‌توانید Response را Cache کنید.
مثلاً:
$data = Cache::remember('currency:rates', 300, function () {
return Http::get('https://example.com/api/rates')
->json();
});
در این مثال اگر API خارجی در هر درخواست فراخوانی شود، هم زمان پاسخ بیشتر می‌شود و هم تعداد Requestها افزایش پیدا می‌کند.
Cache می‌تواند این مشکل را کاهش دهد.
# Cache کردن اطلاعات سرویس‌های خارجی
این روش برای مواردی مانند:
- نرخ ارز
- آب‌وهوا
- اطلاعات APIهای خارجی
- داده‌های عمومی
- اطلاعات سرویس‌های Third-party
بسیار کاربردی است.
البته TTL باید با میزان تغییرپذیری داده هماهنگ باشد.
# Cache و N+1 Query
Cache و N+1 Query دو موضوع متفاوت هستند.
Cache نمی‌تواند جای اصلاح Queryهای بد را بگیرد.
مثلاً اگر کد شما دچار N+1 Query باشد، بهتر است ابتدا مشکل Query را با روش‌هایی مانند Eager Loading حل کنید:
$orders = Order::with('user')->get();
بعد اگر همین Query هنوز پرتکرار یا پرهزینه بود، می‌توانید Cache را نیز بررسی کنید.
بنابراین ترتیب منطقی می‌تواند این باشد:
Optimize Query
↓
Fix N+1
↓
Add Index
↓
Measure Performance
↓
Cache if needed
# Cache و Eloquent
Cache می‌تواند در کنار Eloquent بسیار قدرتمند باشد.
مثلاً:
$products = Cache::remember(
'products:featured',
1800,
fn () => Product::where('featured', true)
->where('status', 'active')
->latest()
->get()
);
اما باید توجه داشته باشید که Cache کردن Collectionهای بسیار بزرگ می‌تواند مصرف حافظه را افزایش دهد.
پس حجم داده Cache شده نیز اهمیت دارد.
# Cache کردن داده‌های بزرگ
فرض کنید می‌خواهید چند صد هزار رکورد را Cache کنید.
این کار معمولاً ایده خوبی نیست.
Cache برای نگهداری سریع داده است، نه اینکه یک دیتابیس دوم بسازیم.
بهتر است:
- فقط داده موردنیاز را Cache کنید
- Pagination داشته باشید
- داده‌های پرتکرار را Cache کنید
- TTL منطقی انتخاب کنید
- حجم Cache را کنترل کنید
# Cache Tags چیست؟
در بعضی Cache Storeها امکان استفاده از Cache Tags وجود دارد.
مثلاً می‌توانید Cacheهای مربوط به محصولات را با یک Tag مشخص کنید.
ایده کلی:
Cache::tags(['products'])->put(
'product:25',
$product,
3600
);
سپس می‌توانید Cacheهای مرتبط با آن Tag را مدیریت کنید.
این قابلیت برای سیستم‌هایی که Cacheهای زیادی دارند می‌تواند مفید باشد.
اما باید توجه داشت که همه Cache Storeها تمام قابلیت‌ها را به یک شکل پشتیبانی نمی‌کنند.
بنابراین قبل از طراحی معماری خود، Store موردنظر را بررسی کنید.
# Cache و چند سرور Laravel
فرض کنید Application شما روی چند Server اجرا می‌شود:
Load Balancer
│
┌─────────┼─────────┐
↓ ↓ ↓
Server 1 Server 2 Server 3
│ │ │
└─────────┼─────────┘
↓
Redis
اگر هر Server Cache محلی خودش را داشته باشد، ممکن است Cacheها با یکدیگر هماهنگ نباشند.
برای چنین معماری‌هایی معمولاً استفاده از یک Cache Store مشترک مانند Redis می‌تواند مناسب‌تر باشد.
این موضوع یکی از دلایل مهم استفاده از Redis در پروژه‌های بزرگ Laravel است.
# Cache و Deployment
یکی از مواردی که در Production باید به آن توجه کنید، Cacheهای Laravel است.
بعد از Deployment ممکن است نیاز باشد Configuration، Route یا Viewهای Cache شده مدیریت شوند.
برخی دستورات رایج:
php artisan config:clear
php artisan route:clear
php artisan view:clear
php artisan cache:clear
همچنین برای ساخت Cacheهای مناسب Production:
php artisan config:cache
php artisan route:cache
php artisan view:cache
باید دقت کنید که این دستورات با توجه به فرآیند Deployment پروژه استفاده شوند و نباید بدون شناخت محیط Production به‌صورت تصادفی اجرا شوند.
# اشتباهات رایج در استفاده از Cache
1. Cache کردن همه چیز
بیشتر Cache همیشه به معنی Performance بیشتر نیست.
Cache اضافی باعث افزایش پیچیدگی و مصرف منابع می‌شود.
2. نداشتن TTL مناسب
اگر Cache برای مدت بسیار طولانی باقی بماند، ممکن است داده قدیمی نمایش داده شود.
3. فراموش کردن Invalidation
یکی از رایج‌ترین مشکلات Cache همین است.
داده اصلی تغییر می‌کند اما Cache قدیمی باقی می‌ماند.
4. Cache کردن داده بسیار بزرگ
این کار می‌تواند RAM یا Storage را بی‌دلیل مصرف کند.
5. استفاده از Cache به جای Database
Cache نباید بدون دلیل تبدیل به منبع اصلی داده شود.
6. Cache کردن Queryهای ضعیف به جای اصلاح آنها
اگر Query مشکل دارد، اول Query را اصلاح کنید.
Cache نباید پوششی برای معماری ضعیف Database باشد.
# یک مثال کامل از Cache در Laravel
فرض کنید در فروشگاه خود لیست محصولات پرفروش را داریم.
بدون Cache:
$products = Product::query()
->where('status', 'active')
->orderByDesc('sales_count')
->take(10)
->get();
هر بار Query اجرا می‌شود.
حالا آن را Cache می‌کنیم:
$products = Cache::remember(
'products:bestsellers',
1800,
fn () => Product::query()
->where('status', 'active')
->orderByDesc('sales_count')
->take(10)
->get()
);
اکنون جریان به این شکل است:
Request
↓
products:bestsellers
↓
┌───────────────────┐
│ Cache موجود است؟ │
└─────────┬─────────┘
│
┌────┴────┐
│ │
Yes No
│ │
↓ ↓
Return Database
↓
Cache
↓
Return
اگر اطلاعات محصولات تغییر کند:
Cache::forget('products:bestsellers');
در درخواست بعدی داده جدید ساخته و Cache می‌شود.
# Cache در پروژه‌های فروشگاهی
Cache در فروشگاه‌های اینترنتی کاربرد بسیار زیادی دارد.
برای مثال می‌توان موارد زیر را Cache کرد:
لیست دسته‌بندی‌ها
منوی فروشگاه
محصولات ویژه
محصولات پرفروش
تنظیمات فروشگاه
اطلاعات صفحات عمومی
نتایج Queryهای سنگین
اطلاعات APIهای خارجی
اما اطلاعاتی مانند موجودی لحظه‌ای، قیمت‌های حساس یا اطلاعات مالی باید با دقت بیشتری Cache شوند.
در چنین مواردی باید بین سرعت و تازگی داده تعادل ایجاد شود.
# Cache در پروژه‌های SaaS
در یک SaaS ممکن است اطلاعات مشترک یا پرتکراری داشته باشیم:
plans
features
settings
permissions
statistics
بعضی از این داده‌ها می‌توانند گزینه‌های مناسبی برای Cache باشند.
اما در SaaSهای Multi-Tenant باید در طراحی Cache Key دقت بیشتری داشت.
مثلاً به جای:
settings
ممکن است نیاز باشد از ساختاری مانند:
tenant:15:settings
استفاده کنید.
در غیر این صورت ممکن است داده یک Tenant اشتباهاً برای Tenant دیگری برگردانده شود.
این موضوع از مهم‌ترین نکات طراحی Cache در سیستم‌های چندمستاجری است.
# بهترین روش برای انتخاب TTL
TTL را نمی‌توان برای همه داده‌ها یکسان تعیین کرد.
بهتر است براساس میزان تغییر داده تصمیم بگیرید.
| نوع داده | TTL پیشنهادی |
|---|---|
| تنظیمات ثابت | طولانی |
| دسته‌بندی‌ها | متوسط تا طولانی |
| لیست محصولات | کوتاه تا متوسط |
| آمار لحظه‌ای | کوتاه |
| API خارجی | وابسته به سرویس |
| داده حساس | با احتیاط زیاد |
این اعداد قانون ثابت نیستند.
TTL باید با رفتار واقعی Application و میزان تغییر داده تعیین شود.
# آیا Cache همیشه باعث افزایش سرعت می‌شود؟
نه لزوماً.
Cache خودش هزینه دارد.
برای مثال:
Generate Data
↓
Serialize
↓
Store
↓
Read
↓
Deserialize
اگر تولید داده بسیار ارزان باشد، ممکن است Cache کردن آن هیچ سود قابل‌توجهی نداشته باشد.
بنابراین بهترین روش این است که قبل و بعد از Cache کردن، Performance را اندازه‌گیری کنید.
# Cache در Laravel و Performance
یک فرآیند منطقی برای بهینه‌سازی می‌تواند چنین باشد:
Identify Slow Operation
↓
Measure
↓
Optimize Query / Code
↓
Check Indexes
↓
Check N+1
↓
Measure Again
↓
Cache if Useful
یعنی Cache باید بخشی از استراتژی Performance باشد، نه اولین راه‌حل برای هر مشکل سرعت.
# جمع‌بندی
Cache یکی از مهم‌ترین ابزارهای افزایش Performance در پروژه‌های Laravel است.
Laravel یک API ساده و یکپارچه برای کار با Cache در اختیار توسعه‌دهنده قرار می‌دهد و می‌توان از Storeهای مختلفی مانند File، Database و Redis استفاده کرد.
مهم‌ترین متدهایی که در این مقاله یاد گرفتیم عبارت‌اند از:
Cache::put()
Cache::get()
Cache::has()
Cache::forget()
Cache::remember()
Cache::rememberForever()
Cache::add()
Cache::increment()
Cache::decrement()
اما استفاده حرفه‌ای از Cache فقط به یادگیری این متدها محدود نمی‌شود.
مواردی مانند:
- انتخاب Cache Store
- طراحی Cache Key
- TTL
- Cache Invalidation
- حجم داده
- هماهنگی Cache بین Serverها
- امنیت
- مصرف منابع
- جلوگیری از داده‌های قدیمی
همگی بخشی از طراحی صحیح سیستم Cache هستند.
در یک پروژه کوچک ممکن است File Cache کافی باشد، اما با رشد Application، Redis می‌تواند انتخاب قدرتمندتری برای Cache و همچنین Queue باشد.
در نهایت باید همیشه این اصل را در نظر داشته باشید:
> Cache برای کاهش هزینه عملیات‌های پرتکرار است، نه جایگزین Database.
# سوالات متداول
Cache در Laravel چیست؟
Cache در Laravel سیستمی برای ذخیره موقت داده‌ها و جلوگیری از اجرای دوباره عملیات‌های پرهزینه مانند Queryهای دیتابیس یا درخواست‌های API است.
بهترین Cache Store در Laravel چیست؟
پاسخ ثابتی وجود ندارد. برای پروژه‌های کوچک File یا Database ممکن است کافی باشد؛ در پروژه‌های بزرگ‌تر Redis معمولاً گزینه قدرتمندی است.
Cache::remember چه کاری انجام می‌دهد؟
ابتدا Cache را بررسی می‌کند. اگر داده وجود داشته باشد همان داده را برمی‌گرداند و اگر وجود نداشته باشد Callback را اجرا کرده، نتیجه را Cache می‌کند و برمی‌گرداند.
چگونه Cache در Laravel را پاک کنیم؟
برای حذف یک کلید:
Cache::forget('key');
برای پاک کردن Cache Application نیز می‌توانید از:
php artisan cache:clear
استفاده کنید.
TTL در Laravel چیست؟
TTL یا Time To Live مدت زمانی است که یک داده می‌تواند در Cache باقی بماند.
آیا Redis برای Cache در Laravel ضروری است؟
خیر. Laravel می‌تواند از Storeهای مختلف استفاده کند و Redis برای همه پروژه‌ها الزامی نیست.
آیا Cache باعث کاهش Queryهای دیتابیس می‌شود؟
اگر به‌درستی طراحی شود، بله. داده‌های پرتکرار می‌توانند از Cache خوانده شوند و در نتیجه نیاز به اجرای مجدد بعضی Queryها کاهش پیدا کند.
آیا می‌توان تمام اطلاعات پروژه را Cache کرد؟
خیر. Cache کردن همه اطلاعات معمولاً تصمیم خوبی نیست. باید داده‌هایی را انتخاب کنید که پرتکرار، هزینه‌بر و مناسب ذخیره موقت باشند.
