Redis’te en tehlikeli cümle: “zaten önbellek”
Bir veri önbellek ise önemsiz sanılabilir. Ama yanlış önbellek tasarımı veritabanını korumak yerine onu daha fazla yorabilir. TTL yoksa bellek şişer, hot key varsa tek nokta ısınır, big key varsa tek komut herkesi bekletebilir.
İyi Redis tasarımı, yalnızca hızlı okuma değil, kontrollü unutma tasarımıdır.
Önce bellek profilini çıkarın
Bellek profili çıkarırken hedef tüm keyleri tek tek saymak değildir; riskli desenleri yakalamaktır. Hangi prefix büyüyor, TTL olmayan keyler nerede birikiyor, hangi key beklenenden büyük, bunlar daha değerlidir.
Temel bellek ve TTL örneklemesi
redis-cli -u "$REDIS_URL" INFO memory redis-cli -u "$REDIS_URL" INFO keyspace redis-cli -u "$REDIS_URL" --scan --pattern "product:*" | head -100 redis-cli -u "$REDIS_URL" TTL "product:acme:123" redis-cli -u "$REDIS_URL" MEMORY USAGE "product:acme:123"
Hot key varsa kapasite değil dağılım konuşulur
Bir key çok sık okunuyorsa Redis genel olarak sağlıklı görünse bile tek komut deseni gecikme yaratabilir. Hot key problemi bazen ürün davranışından gelir: ana sayfa konfigürasyonu, popüler ürün, global sayaç veya tek tenant’a aşırı trafik.
Çözüm bazen keyi parçalamak, bazen local önbellek eklemek, bazen TTL jitter kullanmak, bazen de veriyi farklı modellemektir.
TTL jitter ile aynı anda expire olmayı azaltma
const baseTtl = 300
const jitter = Math.floor(Math.random() * 60)
await redis.set(key, JSON.stringify(value), {
EX: baseTtl + jitter,
})Aynı anda expire olan çok sayıda key, veritabanına ani yük bindirebilir. Küçük jitter bu dalgayı yumuşatır.
Big key gördüğünüzde veri modelini sorgulayın
Büyük hash, büyük list veya büyük set tek bir komutu pahalı hale getirir. LRANGE 0 -1 veya HGETALL gibi komutlar küçükken zararsız, büyüyünce risklidir.
Bu noktada “Redis’i büyütelim” yerine “Bu key neden bu kadar büyüyor?” diye sormak daha öğreticidir. Sayfalama, parçalama veya veriyi kalıcı bir motora taşımak gerekebilir.