Redis gerçekte nedir
Redis bellekte yaşayan bir anahtar-değer deposudur. Ona bir anahtar ("user:1042:profile") ve bir değer verirsiniz; istendiğinde değeri geri verir — okuma yolunda hiçbir şey diske dokunmadığı için genellikle milisaniyenin çok altında. Düz string'lerin üstüne pratik veri yapıları da taşır: nesneler için hash'ler, akışlar ve skor tabloları için listeler ve sıralı kümeler, üyelik kontrolü için kümeler, atomik artırmalı sayaçlar.
Bu bileşim — RAM hızı artı gerçek veri yapıları — neredeyse her ciddi web yığınında bulunmasının sebebidir. Veritabanınızla kalıcılıkta ve sorgulanabilirlikte yarışmaz; *aynı soruyu tekrar tekrar hızlı yanıtlamakta* yarışır ve o yarışı iki-üç kat büyüklük mertebesiyle kazanır.
Çözdüğü problem: tekrarlanan pahalı iş
Tipik bir backend'in istek başına yaptığına bakın: kullanıcıyı yükle, ayarları yükle, son ziyaretçiden beri değişmemiş aynı ürün listesi ya da menü sorgusunu çalıştır, hepsini render et. Bu işin çoğu, saniyeler önce ürettiği cevabın aynısını üretir. Veritabanı yine de hepsini sadakatle yeniden çalıştırır — ayrıştırma, planlama, sayfa okuma, join — ve trafik altında bu tekrarlanan sorgular, CPU'dan çok önce darboğaz olur.
Cache-aside deseni tam bunu düzeltir: önce Redis'e bak; varsa cache'lenmiş kopyayı dön; yoksa gerçek sorguyu çalıştır, sonucu bir yaşam süresiyle (TTL) sakla, dön. On beş sorgu isteyen sayfa, sıcak yolda artık on beş bellek okuması ister. Veritabanı her istekte değil, TTL penceresi başına bir kez çalışır — Redis'li sitelerin, onsuz ezilecekleri trafik zirvelerinden ayakta çıkmasının sebebi de budur.
İkinci klasik iş oturumlardır. Login oturumlarını yerel disk yerine Redis'te tutmak, uygulamanızın herhangi bir kopyasının herhangi bir kullanıcıya hizmet edebilmesi demektir — yatay ölçeklemeyi mümkün kılan şey tam olarak budur.
Redis'in yardım etmeyeceği yerler
Dürüst bir sınır çizgisi haftalar kazandırır. Redis yavaş bir sorguyu ilk seferinde hızlandırmaz — yalnızca *ikinci* çalıştırmayı ucuzlatır; eksik bir veritabanı indeksi hâlâ eksik bir indekstir. Yavaş bir origin ağ yolunu ya da ağır görselleri de düzeltmez; onlar edge'de çözülen dağıtım problemleridir, RAM'de değil. Ve kalıcı bir kayıt sistemi değildir: bellek sonludur, tahliye (eviction) tasarım gereğidir; kaybetmeyi göze alamadığınız her şey veritabanına aittir, Redis onun gözden çıkarılabilir kopyasını tutar.
Cache'lemenin gerçek maliyeti geçersiz kılmadır (invalidation): bayat bir fiyat ya da güncelliğini yitirmiş bir yetki kontrolü, kullanıcılarınızın gördüğü bir bug'dır. Doğruluğun önemli olduğu yerde TTL'leri kısa tutun, alttaki veri değiştiğinde anahtarları açıkça silin ve her istekte değişen şeyleri cache'leme hevesine direnin — isabet oranı sıfıra yakın bir cache saf yüktür.
Yönetilen Redis: eklenti yolu
Redis'i kendiniz çalıştırmak birinci gün zor değildir — iki yüzüncü gün zordur: bellek limitleri, yeniden başlatmalar, sürüm yükseltmeleri, uygulamanın yeniden bağlandığından emin olmak. Yönetilen bir instance bunların hepsini platformun içine katlar.
cdn.com.tr container platformunda Redis, uygulamaya taktığınız bir eklentidir. Etkinleştirmek instance'ı kurar ve bağlantıyı uygulamanızın ortamına otomatik enjekte eder — REDIS_HOST, REDIS_PORT, REDIS_DB ve kullanıma hazır bir REDIS_URL — böylece Laravel, Django ya da WordPress gibi çatılar bunu kodla değil konfigürasyonla alır. WordPress platformu aynı eklentiyi nesne cache'i olarak kullanır; yoğun bir WordPress sitesi için tek hamlelik en yüksek kaldıraçlı değişikliklerden biridir. Eklentiyi kapattığınızda değişkenler de onunla birlikte temizlenir.
cdnctl ile uygulamaya yönetilen Redis ekleyin
# attach a managed Redis instance to your app
cdnctl container addons enable-redis --account <uuid> --app <app_uuid> --env-prefix REDIS
# see what is attached
cdnctl container addons list --account <uuid> --app <app_uuid>
# remove it again
cdnctl container addons disable-redis --account <uuid> --app <app_uuid>Redis ve CDN: iki cache katmanı, iki ayrı iş
Bellek-içi cache ile CDN'in ilişkisini net koymak gerekir; ikisi de "cache"tir ama birbirinin yerine geçmez. CDN *yanıtları* cache'ler — bitmiş HTML, görseller, dosyalar — ziyaretçiye yakın tutar; birçok istek uygulamanıza hiç ulaşmaz. Redis ise *uygulamanın içindeki veriyi* cache'ler; gelen istekler ucuza servis edilir.
Birbirini katlarlar: edge, trafiğin cache'lenebilir çoğunluğunu emer; Redis, kişiselleştirilmiş ve cache'lenemeyen kalanı hızlandırır. İkisine birden sahip bir yığın, anonim sayfaları edge'den onlarca milisaniyede, oturumlu sayfaları Redis'le ısınmış backend'den servis eder — yük altında anında hissettiren sitelerin çoğunun arkasındaki mimari budur.
Sık sorulan sorular
Redis bir veritabanı mı?
Diske kalıcılık yapabilir ama onu bu iş için işe almamalısınız. Redis'i, doğruluk kaynağı gerçek bir veritabanında yaşayan verinin hızlı ve gözden çıkarılabilir kopyası olarak görün. Kaybı acıtacak veri yalnızca Redis'te durmamalı.
Önce neyi cache'lemeliyim?
Cevap sorgu günlüğünde: sonucu nadiren değişen en sık ve en pahalı sorgular — ürün listeleri, menüler, ayarlar, render edilmiş parçalar. Bunları makul bir TTL ile cache'leyin; kazancın çoğunu genellikle bir öğleden sonrada alırsınız.
Redis cache için ne kadar bellek gerekir?
Sanıldığından az — cache'lenmiş sorgu sonuçları ve oturumlar küçüktür. Mütevazı başlayın, isabet oranını ve tahliyeleri izleyin; hâlâ işe yarayan anahtarlar tahliye edilmeye başlayınca büyütün. Küçük ama yüksek isabetli bir instance, boşta duran dev bir instance'tan iyidir.
WordPress Redis'ten fayda görür mü?
Gözle görülür biçimde. WordPress ayarları ve nesneleri MySQL'den sürekli yeniden okur; Redis nesne cache'i bunları bellek okumasına çevirir. Yönetilen WordPress platformunda aynı Redis eklentisi nesne cache'i olarak çalışır, önünde de edge cache vardır.