6 dk okuma

Redis cache-aside stratejisi, uygulamanın sık okunan verileri ana veritabanına her seferinde gitmeden hızlı biçimde sunmasını sağlayan en yaygın önbellekleme desenlerinden biridir. Akış basittir: önce Redis kontrol edilir; cache miss oluşursa veri ana kaynaktan okunur, Redis’e belirli bir TTL ile yazılır ve sonraki istekler cache’ten servis edilir. Fakat üretimde gerçek başarı yalnızca SET ve GET komutlarıyla gelmez. TTL seçimi, cache stampede, stale data, invalidation, memory limiti ve eviction politikası birlikte tasarlanmalıdır.

Redis’in resmi cache-aside rehberi, tekrarlanan okumaları düşük gecikmeyle karşılamak ve ana veritabanı yükünü azaltmak için bu desenin uygun olduğunu vurgular. Aynı dokümantasyon, popüler bir key aynı anda expire olduğunda çok sayıda instance’ın veritabanına yük bindirebildiği cache stampede riskine de dikkat çeker. Bu rehberde cache-aside mimarisini yedi adımda üretim seviyesine taşıyoruz.

İçindekiler

Redis cache-aside stratejisi nedir?
TTL ve jitter nasıl seçilir?
Cache stampede nasıl engellenir?
Negative caching ne zaman kullanılır?
Eviction politikası nasıl seçilir?
Invalidation nasıl güvenli yapılır?
Hit rate, latency ve evictions nasıl izlenir?
Sonuç ve üretim kontrol listesi

Redis Cache-Aside Stratejisi Nedir?

Cache-aside modelinde Redis ana veri kaynağı değildir; uygulama cache ile veritabanı arasındaki koordinasyonu kendisi yönetir. Okuma sırasında önce cache key kontrol edilir. Key varsa veri hemen döner. Yoksa ana veritabanından okunur, Redis’e yazılır ve kullanıcıya gönderilir. Yazma tarafında ise en güvenli başlangıç yaklaşımı önce ana veritabanını güncellemek, ardından ilgili cache key’ini silmektir. Bir sonraki okuma yeni veriyi yeniden cache’e taşır.

1. TTL’yi İş Verisinin Değişim Hızına Göre Belirleyin

Tek bir global TTL değeri kullanmak kolaydır ancak her veri tipi aynı tazelik gereksinimine sahip değildir. Ürün açıklaması saatlerce cache’te kalabilirken stok, fiyat veya yetki verisi çok daha kısa TTL isteyebilir. TTL’yi iş verisinin kabul edilebilir stale süresiyle eşleştirin. Aynı anda oluşturulmuş binlerce key’in aynı saniyede expire olmasını önlemek için TTL üzerine küçük bir random jitter eklemek, ani cache miss dalgalarını azaltır.

2. Cache Stampede İçin Single-Flight veya Kısa Kilit Kullanın

Popüler bir key expire olduğunda yüzlerce paralel istek aynı anda cache miss görebilir ve ana veritabanına aynı sorguyu gönderebilir. Redis’in cache-aside örneklerinde bu problem, tek bir worker’ın kaynağı yeniden doldurmasını sağlayan single-flight kilidiyle sınırlandırılır. Kilidi çok uzun tutmayın; timeout kullanın ve lock sahibinin çökmesi durumunda sistemin kendi kendini toparlamasını sağlayın. Kilit alamayan worker’lar kısa süre bekleyip cache’i yeniden kontrol edebilir.

3. Negative Caching ile Tekrarlanan ‘Yok’ Sorgularını Azaltın

Veritabanında bulunmayan bir kimlik için her istekte tekrar sorgu yapmak da yük yaratır. Özellikle bot trafiği veya hatalı ID üretimi varsa, “kayıt bulunamadı” sonucunu çok kısa bir TTL ile cache’lemek faydalıdır. Buna negative caching denir. Ancak sonsuz veya uzun süreli negative cache kullanmayın; veri daha sonra oluşturulduğunda kullanıcı gereksiz yere eski ‘yok’ sonucunu görmemelidir.

4. Eviction Politikasını Trafik Modeline Göre Seçin

Redis bellek sınırı maxmemory seviyesine ulaştığında maxmemory-policy hangi key’lerin çıkarılacağını belirler. Resmi Redis dokümantasyonu, çok kullanılan küçük bir veri alt kümesinin öne çıktığı yaygın erişim modellerinde allkeys-lru politikasını iyi bir başlangıç seçeneği olarak önerir. allkeys-lfu ise sık erişilen key’leri korumaya odaklanır. Redis 8.6 ile gelen LRM politikası, son okunma yerine son değiştirilme zamanını dikkate alır ve özellikle read-heavy ancak eski veriyi çıkarmak istediğiniz senaryolarda farklı bir seçenek sunar.

Redis cache-aside stratejisi hızlı bakış

5. Cache Invalidation İçin ‘DB Sonra DEL’ Modelini Tercih Edin

Cache-aside yazma akışında önce cache’i silip sonra veritabanını güncellemek yarış koşullarına açıktır. İki istek arasında eski veri yeniden cache’e yazılabilir. Daha güvenli temel model, önce ana veritabanı transaction’ını başarıyla tamamlamak ve ardından cache key’ini silmektir. Silme işlemi geçici olarak başarısız olursa kısa TTL stale pencereyi sınırlar. Daha kritik sistemlerde event-driven invalidation veya outbox deseniyle cache invalidation olaylarını tekrar denenebilir hale getirebilirsiniz.

6. Client-Side Caching’i Ağ Maliyetinin Gerçekten Kritik Olduğu Yerde Kullanın

Redis ayrıca server-assisted client-side caching desteği sunar. Bu yaklaşımda istemci sık okunan key’lerin yerel kopyasını tutabilir ve Redis değişiklik olduğunda invalidation mesajı gönderir. Resmi dokümantasyona göre bu, Redis’e yapılan ağ round-trip sayısını azaltarak gecikmeyi ve sunucu yükünü düşürebilir. Ancak her istemcinin invalidation davranışını doğru desteklemesi gerekir; bağlantı kopmalarında yerel cache’in temizlenmesi gibi güvenlik mekanizmalarını dikkate almadan kullanmak stale data riskini artırır.

7. Hit Rate Tek Başına Yeterli Bir Başarı Metriği Değildir

Yüksek hit rate iyi görünse de yanlış veya bayat veri sunan cache başarılı değildir. Hit/miss oranının yanında P95/P99 cache latency, ana veritabanına düşen sorgu sayısı, evicted_keys, expired_keys, used_memory, keyspace_hits ve keyspace_misses gibi sinyalleri takip edin. Ani eviction artışı memory baskısını, miss artışı TTL veya invalidation problemini gösterebilir. Redis INFO çıktısı ve uygulama metriği birlikte değerlendirildiğinde gerçek performans etkisi daha net görülür.

Üretim Kontrol Listesi

Her veri tipi için tazelik ihtiyacına uygun TTL tanımlandı.
TTL’lere jitter eklenerek toplu expire riski azaltıldı.
Popüler key’lerde cache stampede için single-flight/lock yaklaşımı var.
Negative caching yalnızca kısa TTL ile ve uygun senaryoda kullanılıyor.
maxmemory ve eviction politikası bilinçli seçildi.
Yazma sonrası cache invalidation akışı test edildi.
Hit/miss yanında latency, evictions ve stale data sinyalleri izleniyor.

Sonuç

Redis cache-aside stratejisi, doğru tasarlandığında ana veritabanı yükünü ciddi biçimde azaltır ve sık okunan verileri çok düşük gecikmeyle sunabilir. Ancak üretim kalitesi, cache’e veri yazmaktan çok cache’in ne zaman boşaltılacağını, hangi key’in memory baskısında çıkarılacağını ve cache miss dalgasının nasıl kontrol edileceğini belirlemekle ilgilidir. TTL + jitter, stampede koruması, doğru eviction politikası, güvenli invalidation ve ölçülebilirlik birlikte kurulduğunda Redis, performans optimizasyonundan güvenilir bir uygulama bileşenine dönüşür.

Güvenilir Araştırma Kaynakları

Redis resmi dokümantasyonu: Cache-Aside • Key Eviction • Client-Side Caching • Persistence