Laravel’in depolama tabanlı önbelleği, genellikle ya göz ardı edilen ya da yanlış kullanılan bir özelliktir. Göz ardı edilir ve Redis’e erken başvurulursa, yanlış kullanılırsa dosya sistemini, kötü anahtarlar, yetersiz geçersiz kılma ve sıcak durumu sıfırlayan dağıtımlara atfederler.
Default görüşüm basit: eğer uygulamanız henüz gerçek bir dağıtık sistem değilse, depolama önbelleği genellikle doğru ilk önbellektir. Uygun topoloji için yeterince dayanıklıdır, ucuzdur ve iyi bir şekilde operasyonel olarak sıkıcıdır. Ancak, onu bir alt sistem olarak ele almadığınız sürece iyi çalışmaz. Bunun yerine, Cache::remember() çağrılarını kontrolcülerinizin etrafına serpiştirip gecikme grafiğinin aşağıya inmesini beklemeniz yeterli değildir.
Laravel geliştiricileri burada hataya düşme eğilimindedir. Arka uç tercihi, önbellek sözleşmesinden daha az önemlidir. Anahtarlarınız belirsiz ise, geçersiz kılmanız göz ardı ediliyorsa ve dağıtım modeliniz yerel durumu yavaşça yok ediyorsa, Redis size yardımcı olmayacaktır. Sadece daha pahalı bir karmaşa ile kalmış olursunuz.
Laravel’in önbellek API’si arka uç geçişini kolaylaştırır. Bu faydalıdır, ancak aynı zamanda önemli bir gerçeği gizler: her önbellek deposu aynı şekilde başarısız olmaz. Depolama tabanlı bir önbellek, farklı güçlü ve farklı tuzaklara sahiptir. Bunları net bir şekilde anladığınızda, bir ağ önbellek katmanına ihtiyaç duymadan çok fazla değer elde edebilirsiniz.
Dağıtım şekli ile başlayın, API ile değil
Dağıtım şekli ile başlayın, API ile değil
İlk soru, dosya sistemi önbelleğinin “yeterince hızlı olup olmadığı” değildir. İlk soru, dağıtım şeklinizin önbelleği tutarlı hale getirip getirmediğidir.
Eğer Laravel uygulamanız tek bir VPS, tek bir bare-metal kutu veya stabil yazılabilir bir hacme sahip tek bir sürekli konteyner üzerinde çalışıyorsa, depolama önbelleği genellikle mantıklı bir varsayılandır. Okuma ve yazma işlemleri yerel kalır, soğuk başlangıçlar yönetilebilir ve önbellek süreç yeniden başlatmalarını aşar çünkü disk üzerinde yaşar, PHP işçisinin belleğinde değil.
O dayanıklılık, göz ardı edilen bir kısımdır. Takımlar genellikle dosya destekli önbelleği sadece hız açısından Redis ile karşılaştırır. Uygulamada, dayanıklılık ve operasyonel maliyet de önemlidir. Uygulama yeniden başlatmalarını aşmayı başaran bir önbellek, render edilmiş parçalar, besleme yükleri, özellik matrisleri veya hesaplanmış kontrol panelleri gibi pahalı türetilmiş durumlar için tam olarak istediğiniz şey olabilir.
Bizim için sorun çok düğümlü dağıtımlarla başlar.
Eğer yük dengeleyici arkasında üç uygulama sunucunuz varsa ve her biri kendi yerel diskine yazıyorsa, tek bir önbellek yoktur. Aynı API’ye sahip, birbirinden bağımsız üç önbelleğiniz var. Bu hala düğüm yerel hız artışı için kabul edilebilir olabilir, ancak ne olduğunu kabullenmeniz gerekir. Node A’ya gelen bir istek sıcak bir önbelleğe ulaşırken, node B soğuk olacaktır. Eğer uygulama davranışınız önbellek durumunun paylaşılmış bir görüşünü varsayıyorsa, bu kurulum zaten yanlıştır.
Paylaşımlı bir ağ hacmi, bariz bir çözüm gibi görünüyor; ancak kendi dezavantajlarıyla gelir: tutarlılık artar, gecikme genellikle kötüleşir ve kilit davranışı depolama performansına daha hassas hale gelir. Bu yöntem otomatik olarak yaklaşımı öldürmez, fakat geçerli ölçümünüz gerçekliği yansıtmalı, localhost iyimserliğini değil.
Pratik karar matrisiniz şöyle görünmelidir:
- Tek sunucu veya tek sürekli uygulama düğümü: depolama önbelleği güçlü bir varsayılandır.
- Paylaşılan dayanıklı depolama ile çoklu düğümler: uygulanabilir, ancak gerçek IO’yu ve kilit rekabetini ölçün.
- Her düğüm için yerel diskleri olan çok düğümlü yapı: yalnızca tutarsız sıcak durumun kabul edilebilir olduğunu düşünüyorsanız kullanın.
- Geçici konteynerler veya sunucusuz tarzda dağıtımlar: paylaşılan uygulama önbelleği için atlayın.
İlk sıkı kural: topoloji, depolama önbelleğinin bir sistem olup olmadığını belirler.
Depolama önbelleği aslında neye iyi gelir
Depolama önbelleği aslında neye iyi gelir
Depolama tabanlı önbellek, önbelleğe alınan değer, disk okuma maliyetine göre pahalı olduğunda, ancak yalnızca bellek hızının zorunlu olmadığı durumlarda parlayabilir.
Bu, birçok gerçek Laravel iş yükünü içerir:
- sayfalandırılmış kamu içerik sorguları
- pazarlama veya blog sayfaları için render edilmiş HTML parçaları
- birkaç veritabanı sorgusunu birleştiren hesaplanan API yanıtları
- istekler arasında kullanılan türetilmiş ayar anlık görüntüleri
- kontrol panelleri için pahalı “bir kez biçimlendir, birçok kez sun” verileri
Koordinasyona ihtiyaç duyan iş yükleri, yüksek değişken geçici veriler veya önbellek gecikmesinin önemli eşzamanlılık altında kritik yol olduğu sistemler için kötü bir uyum sağlar.
Yaygın hata, depolama önbelleğini yetersiz bir Redis olarak görmek yerine, kararlı türetilmiş veriler için ucuz dayanıklı bir önbellek olarak ele almaktır.
Bu ayrım tasarımınızı nasıl şekillendirdiğinizi değiştirir.
Örneğin, ana sayfa beslemesini 15 dakika boyunca önbelleğe alıyorsanız ve yayın etkinlikleriyle geçersiz kılıyorsanız, dosya destekli depolama çok iyi çalışabilir. Eğer sürekli değişen bir kullanıcı durumu blob’unu birçok işçi arasında paylaşıyorsanız, bu arka uç yanlış ve muhtemelen yanlış bir önbellek şeklidir de.
Laravel’in resmi önbellek dokümantasyonu, API yüzeyi ve sürücü yetenekleri için hala referans noktasıdır: https://laravel.com/docs/12.x/cache. Soyutlama, o kadar kararlı bir şekilde yeterli ki, daha yüksek düzeydeki tasarım tavsiyeleri bireysel yöntem adlarını ezberlemekten daha önemlidir.
Önbellek anahtarları tasarlanmalı, doğaçlama yapılmamalıdır
Önbellek anahtarları tasarlanmalı, doğaçlama yapılmamalıdır
Çoğu önbellek sistemi, anahtarlar fırsatçı bir şekilde icat edildiğinde güvenilmez hale gelir.
Aşağıdaki gibi bir anahtar bir alarm işareti:
Cache::remember('posts', 900, fn() => Post::latest()->take(10)->get());
Bu anahtar hemen hemen hiçbir şey söylemez. Hangi gönderiler? Sadece kamuya açık mı? Yerel belirli mi? Kiracıya özel mi? Taslaklar hariç mi? Bu anahtar ana sayfa widget’ı mı yoksa bir yönetici paneli sorgusu mu? Eğer biri daha sonra kategori filtrelemesi veya kiracı bazlı görünürlük eklerse, anahtar sessizce yanlış olur.
İyi bir anahtar, üç şeyi açıkça tanımlamalıdır:
- Önbelleğe alınan nesne
- Değeri şekillendiren kapsam
- Geçersiz kılmayı sağlayan sürüm sınırı
Bu genellikle anahtarlarınızı çoğu ekibin yaptığı kadar saldırgan bir şekilde isimlendirmeyi gerektirir.
$key = sprintf(
'blog:index:v%d:tenant:%s:locale:%s:page:%d',
$version,
$tenantId,
app()->getLocale(),
$page
);
$posts = Cache::store('file')->remember($key, now()->addMinutes(15), function() use ($page) {
return Post::query()
->published()
->latest('published_at')
->paginate(12, page: $page);
});
Bu anahtar daha uzun ve bu iyi. Kısa anahtarlar mühendislik zarafeti olarak bir rozet değildir. Eğer daha uzun bir anahtar önbellek sözleşmesini açık hale getiriyorsa, ek karakterler ucuzdur.
Anahtarları merkezi olarak oluşturun
Anahtarları merkezi olarak oluşturun
String olarak yazılmış anahtarları kontrolcüler, Livewire bileşenleri, işler, konsol komutları ve gözlemciler arasında yaymayın. Onları küçük, özel bir katmanda merkezi hale getirin.
Bu sınıf “mimari astronot” çalışması değildir. Temel hijyen kurallarındandır. Ekibinize isimlendirme, kapsam ve geçersiz kılma sınırlarını düşünmek için bir yer sunar.
Kazara karmaşayı serileştirmekten kaçının
Kazara karmaşayı serileştirmekten kaçının
Diğer bir başarısızlık modu, Laravel’in bunu kolaylaştırdığı için devasa Eloquent koleksiyonlarını veya model grafiğini önbelleğe almaktır.
Genellikle okuma problemini çözen en küçük kararlı temsilin önbelleğe alınması istenir. Çoğu durumda bu, ham model nesneleri yerine diziler, DTO benzeri yük veya görünüm modelleri anlamına gelir.
Kötü desen:
return Cache::remember($key, 3600, fn() => User::with(['roles', 'permissions', 'teams'])->findOrFail($id));
Daha iyi desen:
return Cache::remember($key, now()->addHour(), function() use ($id) {
$user = User::query()
->with(['roles:id,name', 'teams:id,name'])
->findOrFail($id);
return [
'id' => $user->id,
'name' => $user->name,
'roles' => $user->roles->pluck('name')->all(),
'teams' => $user->teams->pluck('name')->all(),
];
});
Daha küçük yükler dosya boyutunu, serileştirme yükünü ve Eloquent grafiğinizin şekli gelişirken karşılaşılacak sürprizleri azaltır.
Geçersiz kılma, gerçek mühendisliğin olduğu yerdir
Geçersiz kılma, gerçek mühendisliğin olduğu yerdir
Arka uç nadiren en zor kısmıdır. Geçersiz kılma, sistemdir.
Eğer önbellek geçersiz kılma stratejiniz “garip bir şey olduğunda sil” ise, bir önbellek stratejiniz yoktur. Bir kesinti ritüeline sahipsinizdir.
Depolama önbelleği bunu daha belirgin hale getirir çünkü geniş kapsama alanları acı vericidir. Dayanıklı sıcak durumu temizler ve dağıtım, içerik yayını veya yönetici eylemi hemen ardından yeniden hesaplama patlaması tetikleyebilir.
Birçok Laravel uygulaması için temiz desen sürümlü isimlendirmedir.
Konkret anahtarları takip etmek yerine, her mantıksal veri parçası için küçük bir sürüm anahtarı tutun. Temel durum değiştiğinde, sürümü artırın. Yeni okumalar otomatik olarak yeni anahtarları kullanır. Eski değerler, TTL sona erene veya manuel temizliğe kadar zararsız kalır.
get(BlogCacheKeys::version($tenantId), 1);
}
public static function bump(int $tenantId): int
{
$next = self::current($tenantId) + 1;
Cache::store('file')->forever(BlogCacheKeys::version($tenantId), $next);
return $next;
}
}
?>
Bu, sizi tüm önbelleği yok etmeden istikrarlı bir geçersiz kılma kolu sağlar.
Geçersiz kılmayı durum değişikliklerinin yanına koyun
Geçersiz kılmayı durum değişikliklerinin yanına koyun
Geçersiz kılmayı kontrolcülerde yapmayın, yalnızca durumun değiştiği yer burasıysa. Çoğu uygulamada bu durum böyle değildir.
Durum değişiklikleri şu şekillerde gerçekleşir:
- yönetici formları
- kuyruklu işler
- Artisan komutları
- arka ofisteki akışlarda model fabrikaları
- webhooks
- içerik alma hatları
Eğer geçersiz kılma sadece HTTP yöneticilerinde yaşarsa, gerçeklikten senkronizasyonunu kaybeder.
Model gözlemcileri veya alan olayları genellikle daha iyi bir yerdir.
wasChanged(['title', 'slug', 'status', 'published_at'])) {
BlogCacheVersion::bump($post->tenant_id);
}
}
public function deleted(Post $post): void
{
BlogCacheVersion::bump($post->tenant_id);
}
}
?>
Bu, beş farklı kod teması ve bir yığın anahtar arasında takip yapmaktan çok daha güvenilirdir.
TTL geçersiz kılmanın yerine geçirilmemelidir
TTL geçersiz kılmanın yerine geçirilmemelidir
Birçok geliştirici 10 dakikalık bir TTL kullanarak düşünmekten kaçınmaya çalışır. Bu tembel ve genellikle yanlıştır.
TTL, temel verinin değişkenliği ve okuyucular için kabul edilebilir eski durum penceresi ile eşleşmelidir.
Örnekler:
- biraz eski olabilecek kontrol paneli metrikleri: 30 ila 120 saniye
- günde birkaç kez güncellenen içerik dizinleri: açık sürüm artışları ile 10-30 dakika
- birkaç tablodan türetilen referans yapılandırması: saatler veya etkili olarak sonsuza dek olay bazlı geçersiz kılma ile
- pahalı rapor anlık görüntüleri: uzun TTL ve manuel yenileme kontrolü
Gerçek doğruluk sınırı “bir gönderi yayınlandığında yenileyin” ise, cevap “belki 15 dakika yeter” değildir. Cevap, yayın sırasında açık bir geçersiz kılmadır.
Stampede ve dağıtım zamanı öz sabotajını önleyin
Stampede ve dağıtım zamanı öz sabotajını önleyin
Önbellek bir kez çalışmaya başladıktan sonra, bir sonraki problem genellikle eşzamanlılıktır.
Bir sıcak anahtar süresinin dolması. Birkaç işçi eşzamanlı olarak kaçar. Herkes aynı pahalı değeri yeniden hesaplıyor. Veritabanı, önbelleğin tam olarak koruması gereken zaman daha yoğun bir şekilde vuruluyor.
Laravel’in kilit destekleri burada önemlidir; depolama tabanlı önbellekle bile. Çerçeve, desteklenen mağazalar için atomik kilitleri belgelemektedir ve pahalı okuma yolları için bunları kullanmalısınız, sadece remember() yeterli değildir.
use Illuminate\Contracts\Cache\LockTimeoutException;
use Illuminate\Support\Facades\Cache;
function getAccountSummary(int $accountId): array
{
$key = "accounts:summary:v1:id:{$accountId}";
$store = Cache::store('file');
if ($store->has($key)) {
return $store->get($key);
}
try {
return $store->lock("lock:{$key}", 15)->block(3, function() use ($store, $key, $accountId) {
return $store->remember($key, now()->addMinutes(20), function() use ($accountId) {
return app(AccountSummaryBuilder::class)->build($accountId);
});
});
} catch (LockTimeoutException $e) {
$staleKey = "{$key}:stale";
if ($store->has($staleKey)) {
return $store->get($staleKey);
}
$fresh = app(AccountSummaryBuilder::class)->build($accountId);
$store->put($key, $fresh, now()->addMinutes(20));
$store->put($staleKey, $fresh, now()->addHours(2));
return $fresh;
}
}
Önemli olan fikir, bir işçi pahalı yeniden üretimi gerçekleştirmelidir ve diğer işçiler ya kısa bir süre beklemeli ya da kontrollü bir geri dönüş almalıdır.
Özellikle pahalı değerler için geçersiz kılma paternleri, sert bir sona ermeden daha iyidir. Kısa ömürlü bir taze anahtar ve daha uzun ömürlü bir bayat yedek tutun. Yeniden üretimin bekleme ya da yavaş olduğunda, yoğun yük altında veritabanınızı patlatmak yerine geçici olarak eski sonucu sunun.
Dağıtım işlemleri, trafiğin kırılmasından daha fazla önbelleği bozar
Dağıtım işlemleri, trafiğin kırılmasından daha fazla önbelleği bozar
Depolama tabanlı önbellek, dağıtım davranışını dürüstçe düşünmeye zorlar.
Eğer dağıtım süreciniz, yeni yazılabilir katmanlarla konteynerleri değiştirirse, önbellek dayanıklılığınız sahte olur.
Eğer yayın kancanız uygulama önbelleklerini agresif bir şekilde temizlerse, uygulamanızı her yeni yayınladığınızda gerçek trafik altında soğuk başlanması için eğitiyorsunuz demektir.
Eğer anahtar şekliniz sürümler arasında değişiyorsa ve ad alanını sürümlendirmediyseniz, ince serileştirme veya yük eşleşmesi hataları yaşayabilirsiniz.
Daha güvenli dağıtım deseni:
- Eski ve yeni önbellek şekilleri arasında kısa bir örtüşmeyi tolere edebilecek kod gönderin.
- Yük taşıma uzun süreliyse, yük biçimi değiştiğinde yeni bir anahtar sürümü tanıtın.
- Kirliliği temizlemediğiniz sürece küresel boşaltmalardan kaçının.
- Eski anahtarların doğal olarak yok olmasına izin verin.
Bu, php artisan cache:clear kadar dramatik değildir ve bu nedenle daha iyidir.
Ne zaman ucuz olmaktan vazgeçip Redis’e geçeceğinizi bilin
Ne zaman ucuz olmaktan vazgeçip Redis’e geçeceğinizi bilin
Depolama önbelleği yaşam süresini aşmanın bir madalyası yoktur.
Bir noktada, Redis veya başka bir paylaşılan bellek tabanlı arka uç doğru cevap olur. İlerlemenizin doğru nedenlerle yapılması önemlidir.
Aşağıdaki durumlarda hareket edin:
- birçok uygulama düğümü arasında tutarlı paylaşılan önbellek
- eşzamanlılık altında daha düşük ve daha öngörülebilir gecikme
- kilitlerle, kuyruklarla, kısıtlama veya koordinasyon ufuklarının daha yoğun kullanımı
- dosya IO’nun fark edilebilir olduğu daha yüksek önbellek çürümesi
- vurulma oranları, hatalar ve bellek baskısını takip etmede daha iyi operasyonel görünürlük
Basitçe, sadece Redis’in daha ciddi görünmesinden dolayı hareket etmeyin. Bu, ekiplerin gerçek problemleri çözmeden altyapıyı eklediği yoldur.
Eğer gerçek sorunlarınız belirsiz anahtarlar, bozuk geçersiz kılmalar veya dağıtım zamanındaki önbellek yok etmeleri ise, Redis hızlı bir sürümde aynı kötü tasarımı sunar.
Daha iyi zihinsel model şudur: depolama önbelleği, birçok Laravel uygulaması için doğru ilk ciddi önbellektir çünkü sistemi basit tutarken, önemli olan kısımları öğrenmeye zorlar. Size topolojiyi yüzleştirir. Anahtarları tasarlatır. Geçersiz kılmayı ve dağıtım davranışını düşündürtür, altyapının arkasına gizlenmeye zorlar.
Bu değerlidir.
Tavsiyem basit: Uygulama tek düğümlü veya gerçekten paylaşımlı dayanıklı depolama ile destekleniyorsa, önbelleğe alınan değerler kararlı türetilmiş verilerdir ve açık geçersiz kılma kurallarına sahipseniz Laravel depolama önbelleğini kullanın. Eşzamanlılık, koordinasyon veya çok düğümlü tutarlılık gerçek bir sorun haline geldiğinde Redis’e geçin.
Eğer bir karar kuralını hatırlarsanız, bu olmalı: dağıtım şeklinize uygun en ucuz önbellek arka ucunu seçin, ardından mühendislik enerjinizi anahtarlar, geçersiz kılma ve stampede kontrolü üzerine harcayın. Kazanımlar aslında burada gelir.
Tam yazıyı QCode’da okuyun: https://qcode.in/laravel-storage-cache-patterns-cheap-durable-app-caching/
Kaynak: Orijinal Makale
