Redis cache kaliplari

Redis bellek icinde çalışan, düşük gecikmeli veri yapisi sunan bir cache ve message broker cozumudur. Yanlış kullanıldığında tutarsiz veri, bellek tukenmesi ve thundering herd gibi sorunlar ortaya cikar. Doğru cache kalıbı seçimi; okuma yogunlugu, tutarlılık gereksinimi ve invalidation maliyetine baglidir. Bu yazida cache-aside, read-through, write-through, TTL stratejileri, Redis veri yapilari ve invalidation modellerini inceliyoruz.

Cache-aside (lazy loading)

Uygulama once cache'e bakar; miss ise veritabanindan okur ve cache'e yazar. En yaygın kalıptir. Avantaj: yalnizca okunan veri cache'lenir. Dezavantaj: ilk okuma yavas; invalidation uygulama sorumlulugundadir.

var cached = await redis.GetAsync(key);
if (cached is null) {
    var data = await db.GetProductAsync(id);
    await redis.SetAsync(key, data, TimeSpan.FromMinutes(15));
    return data;
}

Read-through ve write-through

Read-through'ta cache katmanı miss'te otomatik yukler. Write-through'ta yazma hem DB hem cache'e gider; tutarlılık güçlü, yazma latency artar. Write-behind (write-back) performansli ama veri kaybi riski tasir; dikkatli kullanılmalı.

TTL politikasi

Sonsuz TTL bellek siser ve stale veri riski artar. Kisa TTL basit invalidation sağlar; cache hit orani duser. Jitter eklenerek ayni anda expire olan anahtarlar dagitilir. Kritik veride TTL + explicit invalidation birlikte kullanılır.

Cache invalidation

• Key delete: Güncelleme/silmede ilgili anahtarlar silinir.
• Tag/prefix invalidation: category:5:* pattern ile toplu silme (SCAN dikkatli).
• Versioned key: product:v3:123; versiyon artinca eski anahtarlar dogal olarak kullanılmaz.
• Pub/Sub: Diger instance'lara invalidation sinyali.

Veri yapisi seçimi

String: JSON serialize DTO. Hash: alan bazli güncelleme. Set: uniq koleksiyon. Sorted Set: leaderboard. List: kuyruk (dikkatli; blocking list consumer pattern). HyperLogLog: cardinality tahmini. Stream: event log.

Thundering herd onleme

Cache expire oldugunda binlerce istek ayni anda DB'ye gidebilir. Çözümler: mutex/singleflight, probabalistic early expiration, stale-while-revalidate, per-key lock (Redis SET NX).

if (!await redis.SetAsync(lockKey, "1", TimeSpan.FromSeconds(10), When.NotExists))
    return await WaitAndRetryGet(key);
var data = await db.LoadAsync();
await redis.SetAsync(key, data, ttl);

Belleg yönetimi

maxmemory policy: allkeys-lru, volatile-lru, allkeys-lfu. volatile-ttl sadece TTL'li anahtarlari evict eder. Büyük degerler compression veya ayri key shard dusunulur. Memory fragmentation INFO memory ile izlenir.

Tutarlılık seviyeleri

Strong consistency cache ile DB arasinda zordur. Eventual consistency çoğu okuma agir senaryoda kabul edilir. Finansal bakiye gibi kritik veriler cache'lenmemeli veya cok kisa TTL + invalidation ile korunmali.

Redis ve veritabanı birlikte

Cache DB'nin yerini almaz. Transaction commit sonrasi invalidation yapilmali; commit oncesi invalidation stale read üretir. Outbox veya domain event invalidation'i diger servislere yayabilir.

Anti-pattern'ler

1. Cache'i birincil veri kaynagi sanmak
2. Pattern KEYS * production'da
3. Dev transaction icinde cache güncelleme
4. Serialization format degisikliginde versiyonsuz key

Özet

Cache-aside çoğu senaryo icin baslangic noktasidir. TTL, invalidation ve herd onleme birlikte tasarlanmali. Veri yapisi erişim pattern'ine uygun secilmeli. Ölçüm: hit ratio, latency, evicted keys.

Redis Cluster ve yüksek erisilebilirlik

Tek node Redis geliştirme icin yeterlidir; production'da Sentinel veya Redis Cluster tercih edilir. Cluster modunda key slot dagilimi hash tag ({user}:123) ile ilişkili anahtarlar ayni node'da tutulabilir. Failover sirasinda kisa sureli yazma kaybi toleransi uygulama tarafinda ele alinmalidir.

Güvenlik ve ag izolasyonu

Redis AUTH ve TLS zorunlu olmalidir. Public internet'e açık Redis instance'lari duzenli olarak taranir ve ele gecirilir. VPC icinde private subnet, security group kisitlamasi ve least privilege erişim uygulanir. Hassas veri cache'lenmemeli; PII cache gerekiyorsa sifreleme ve kisa TTL sarttir.

Cache warming ve cold start

Deploy sonrasi bos cache thundering herd üretir. Warm-up job kritik anahtarlari onceden doldurur. Staggered TTL (jitter) ayni anda binlerce anahtarin expire olmasini onler. Lazy loading + singleflight (mutex) ayni anahtar icin paralel cache miss'i tek sorguya indirir.

Observability

Hit ratio, memory usage, evicted keys, connected clients ve command latency izlenir. Düşük hit ratio tasarım hatasi veya TTL politikasini isaret eder. Redis slowlog ve latency doctor tani araci olarak kullanılır. Cache metrikleri uygulama SLI'lari ile birlikte dashboard'da gosterilir.