- Konu sahibi
- #1
Redis cache nedir?
Redis cache, uygulamanın sık ihtiyaç duyduğu verileri ana veritabanı yerine hızlı erişilebilen bellekte geçici olarak tutan bir önbellek katmanıdır. Redis veriyi anahtar-değer yapısında saklar; uygulama önce Redis’e bakar, veri varsa doğrudan kullanır, yoksa asıl kaynaktan alıp Redis’e yazar. Böylece veritabanı sorguları ve yanıt süresi azalabilir. Redis, kalıcı veritabanının yerine değil, genellikle onun önünde çalışan hızlandırıcı bir katman olarak düşünülmelidir.
Redis cache nasıl çalışır?
En yaygın kullanım biçimi “cache-aside” yaklaşımıdır:
- Uygulama, istenen veri için belirli bir Redis anahtarı oluşturur; örneğin
product:42. - Önce Redis’te bu anahtarı arar.
- Anahtar bulunursa buna cache hit denir ve veri doğrudan Redis’ten döndürülür.
- Anahtar yoksa buna cache miss denir. Uygulama veriyi veritabanından veya başka bir kaynaktan alır.
- Alınan veri, uygun bir süreyle Redis’e yazılır ve istemciye gönderilir.
Örneğin ürün sayfası
product:42 anahtarını kullanıyor olsun. İlk istekte ürün verisi veritabanından okunur ve Redis’e 300 saniyelik yaşam süresiyle yazılır. Aynı ürün için sonraki isteklerde uygulama önce Redis’e bakar. Anahtar hâlâ mevcutsa veritabanına tekrar sorgu göndermeden yanıt verir; bellek tahliye politikası bir anahtarı TTL dolmadan da çıkarabilir. Süre dolduğunda bir sonraki istek yeniden veritabanından güncel veriyi alır.Bu modelde Redis’teki veri kesin gerçeklik kaynağı değildir. Gerçeklik kaynağı veritabanı, dosya sistemi veya başka bir servis olabilir. Redis yalnızca yeniden üretilebilen ya da asıl kaynaktan tekrar okunabilen verilerin hızlı kopyasını tutmalıdır.
Hangi veriler Redis’e uygundur?
Redis cache özellikle sık okunan ve hesaplanması veya alınması görece pahalı olan verilerde anlamlıdır. Ürün bilgileri, yapılandırma verileri ve API yanıtlarının tekrar üretilebilir kopyaları buna örnek olabilir. Oturum saklama ve sayaçlar da Redis kullanım alanlarıdır; fakat tek kopya tutulan bu veriler sıradan, gerektiğinde silinebilen cache ile aynı dayanıklılık varsayımına sahip değildir. Ancak her veri cache’e konulmamalıdır.
| Veri türü | Redis cache kararı | Dikkat edilmesi gereken nokta |
|---|---|---|
| Herkese ortak ürün veya kategori verisi | Genellikle uygundur | Değişiklikte anahtarı silin veya kısa TTL kullanın |
| Kullanıcıya özel hesap bilgisi | Koşullu olarak uygundur | Kullanıcı kimliğini ayırın; erişim yetkisini ayrıca denetleyin |
| Ödeme veya muhasebe kaydı | Ana veri olarak uygun değildir | Kalıcı kayıt için veritabanını kullanın |
| Büyük dosya veya sınırsız sonuç kümesi | Genellikle uygun değildir | Bellek tüketimini ve serileştirme maliyetini hesaplayın |
Örneğin kullanıcıya özel bir değer için yalnızca
profile anahtarını kullanmak hatalıdır; kullanıcılar birbirinin verisini görebilir. Bunun yerine profile:user:42 gibi kullanıcı kimliğini içeren, çakışmayan bir anahtar şeması kullanılmalıdır. Anahtar adlandırma kuralı baştan belirlenmeli; nesne türü, kimlik ve gerekiyorsa sürüm bilgisi açıkça ayrılmalıdır.Uygulamada izlenecek kararlar
- Cache’lenecek verinin kaynağını belirleyin. Redis’teki kayıt silinse bile uygulama veriyi asıl kaynaktan yeniden oluşturabilmelidir.
- Anahtar biçimini tasarlayın. Örneğin
product:42:v1vecategory:7:page:1birbirinden ayrılmalıdır. - Verinin ne kadar süreyle kabul edilebilir olduğunu belirleyin. Daha sık değişen veriye daha kısa TTL, seyrek değişen veriye daha uzun TTL verilebilir.
- Cache miss durumunu uygulayın. Redis bağlantısı veya anahtar yokluğu, isteğin otomatik olarak hataya dönüşmesi yerine uygun olduğunda asıl kaynağa geri dönüşle ele alınmalıdır.
- Asıl veri değiştiğinde ilgili cache anahtarını silin veya güncelleyin. Yalnızca TTL’ye güvenmek, eski verinin gereğinden uzun görünmesine yol açabilir.
- Bellek kullanımını, hit/miss oranını, gecikmeyi ve Redis bağlantı hatalarını izleyin. Cache performansı artırmıyorsa anahtar seçimini ve veri boyutunu yeniden değerlendirin.
Sık yapılan hatalar
Redis’in tüm kullanım biçimlerini geçici cache ile aynı sanmak yanıltıcıdır. Burada ele alınan cache katmanındaki veri silinebilir kopyadır; Redis’in başka kullanım ve kalıcılık seçenekleri olması bunu değiştirmez. Yeniden oluşturulamayan tek kopya veriler yalnızca cache’te tutulmamalıdır. Ayrıca her kayda sınırsız yaşam süresi vermek belleğin dolmasına ve eski verilerin kalmasına neden olabilir. TTL, bellek sınırı ve uygun tahliye politikası birlikte planlanmalıdır.
Bir başka sorun, aynı kaynağın güncellenmesinden sonra cache’in temizlenmemesidir. Ürün fiyatı veritabanında değiştiği halde eski anahtar Redis’te kalırsa kullanıcı eski fiyatı görebilir. Çok sayıda anahtar aynı anda sona erdiğinde de asıl veritabanına ani yük binebilir; bu nedenle yoğun sistemlerde TTL değerlerine uygun küçük sapmalar ekleyerek anahtarların sona ermesini zamana yaymak ve yeniden oluşturma yükünü sınırlamak gerekebilir.
Son olarak, Redis’e yazılan verinin serileştirme biçimi, boyutu ve sürüm uyumluluğu kontrol edilmelidir. Büyük nesneleri düşünmeden cache’lemek, sorgu sayısını azaltırken Redis belleğini ve ağ trafiğini gereksiz artırabilir.
