Yazılımda Önbellekleme (Caching) Mantığı: Redis ve Memcached Nasıl Çalışır?

Önbellekleme, sık istenen veriyi pahalı kaynağa tekrar gitmeden hızlı bir katmandan sunma tekniğidir. 2012'den beri web projeleri yönetiyorum ve yavaş sitelerin çoğunda sorunun kod değil, aynı sorguyu binlerce kez tekrar eden bir mimari olduğunu gördüm. Bu yazıda önbellek stratejilerini, TTL ve geçersiz kılma mantığını, Redis ile Memcached farkını anlatıyorum.

Yazıyı geliştirici gözüyle yazdım ama proje yöneten okurlar için de sade tuttum. Diğer teknik yazılara yazılım kategorisinden ulaşabilirsiniz.

Önbellekleme nedir ve yazılımda neden kullanılır?

Önbellekleme, bir hesaplamanın ya da sorgunun sonucunu geçici olarak hızlı bir bellekte saklayıp sonraki isteklerde aynı sonucu yeniden üretmeden döndürme yöntemidir. Amaç, veritabanı, dış API veya ağır hesaplama gibi yavaş kaynakların yükünü azaltmak ve yanıt süresini kısaltmaktır.

Mantık basittir: RAM, diske ve ağ üzerinden yapılan bir sorguya göre çok daha hızlıdır. Bu nedenle ürün listesi, kategori menüsü veya kur bilgisi gibi sık okunan ama seyrek değişen veriyi bellekte tutarsınız. Böylece veritabanı yalnızca gerçekten yeni veri gerektiğinde çalışır.

Ancak önbellekleme bedava değildir. Veriyi iki yerde tuttuğunuz anda "hangisi doğru?" sorusu doğar. Yazının geri kalanı büyük ölçüde bu soruyu yönetmekle ilgili. Önce katmanları, ardından stratejileri, en sonunda da iki popüler aracı ele alıyorum; böylece okurken kendi projenizde hangi adımın eksik olduğunu kolayca görebilirsiniz.

Önbellek hangi katmanlarda bulunur?

Bir web isteği kullanıcıdan veritabanına giderken birçok önbellek katmanından geçer. Her katman farklı bir sorunu çözer, dolayısıyla hepsini aynı kurallarla yönetemezsiniz.

• Tarayıcı önbelleği: CSS, JavaScript ve görselleri kullanıcının cihazında tutar; Cache-Control başlığıyla yönetirsiniz.
• CDN ve ters vekil: Statik dosyaları ve bazen tüm HTML sayfasını kullanıcıya yakın sunucularda saklar.
• Uygulama önbelleği: Redis veya Memcached gibi bir sunucuda sorgu sonuçlarını, oturumları ve hesaplanmış nesneleri tutar.
• Süreç içi önbellek: Uygulamanın kendi belleğindeki küçük sözlüklerdir; en hızlısıdır ama sunucular arasında paylaşılmaz.
• Veritabanı önbelleği: Veritabanının kendi tampon havuzu sık okunan sayfaları bellekte tutar.

HTTP tarafının ayrıntılarını web.dev ekibinin HTTP önbelleği rehberi iyi özetliyor. Bu yazıda ağırlıkla uygulama katmanına, yani Redis ve Memcached dünyasına odaklanıyorum.

Cache hit ve cache miss ne anlama gelir?

Önbellekleme dilinde cache hit, aranan verinin önbellekte bulunduğu durumdur; uygulama sonucu doğrudan bellekten döndürür. Buna karşılık cache miss, verinin önbellekte olmadığı durumdur; uygulama asıl kaynağa gider, sonucu alır ve çoğu zaman önbelleğe de yazar.

İsabet oranı, toplam okumaların ne kadarının önbellekten karşılandığını gösterir. Örnek hesap: 1.000 okumanın 900'ü önbellekten gelirse isabet oranınız yüzde 90 olur. Kalan 100 istek veritabanına gider.

Yine de isabet oranını tek başına hedef yapmayın. Çok uzun TTL koyarak oranı yükseltebilirsiniz, fakat bu kez kullanıcılara eski veri gösterirsiniz. Asıl ölçü, doğru veriyi kabul edilebilir gecikmeyle sunup sunmadığınızdır.

Bir de soğuk önbellek kavramını bilin. Sunucuyu yeniden başlattığınızda ya da yeni bir sürüm yayınladığınızda önbellek boştur ve ilk dakikalarda neredeyse her istek ıskadır. Bu nedenle yoğun trafik alan sistemlerde yayından hemen sonra en popüler anahtarları bir betikle önceden doldurursunuz; buna önbellek ısıtma denir.

Cache-aside stratejisi nasıl çalışır?

Cache-aside, yani tembel yükleme, en yaygın önbellek desenidir. Uygulama önbelleği bir yan depo gibi kullanır ve kontrol tamamen uygulamadadır. AWS'in önbellek desenleri dokümanı da bu yaklaşımı temel desen olarak anlatır.

1. Uygulama önce önbelleğe anahtarı sorar.
2. Veri varsa, yani isabet olursa, sonucu hemen döndürür.
3. Veri yoksa veritabanına gider ve sonucu okur.
4. Okuduğu sonucu bir TTL ile önbelleğe yazar.
5. Son olarak sonucu kullanıcıya döndürür.

Bu desenin avantajı, yalnızca gerçekten istenen veriyi önbelleğe almanızdır. Ayrıca önbellek sunucusu çökerse uygulama yavaşlar ama çalışmaya devam eder. Bu dayanıklılık, cache-aside desenini önbellekleme projelerinde ilk tercihim yapıyor. Dezavantajı ise her ıskada üç adım atmanız ve veri güncellendiğinde önbelleği sizin temizlemeniz gerektiğidir.

Read-through ve write-through arasındaki fark nedir?

Read-through desende uygulama yalnızca önbellekle konuşur. Önbellekte veri yoksa önbellek katmanı veriyi kaynaktan kendisi yükler. Yani ıska mantığı uygulamadan çıkıp bir kütüphaneye veya önbellek sağlayıcısına geçer.

Write-through ise yazma tarafını ele alır. Uygulama bir kaydı güncellediğinde değeri aynı işlemde hem veritabanına hem önbelleğe yazar. Böylece önbellek her zaman güncel kalır ve okumalar ilk seferde isabet eder.

Öte yandan write-through her yazmayı biraz yavaşlatır, çünkü iki yere yazarsınız. Üstelik hiç okunmayacak verileri de önbelleğe doldurursunuz. Bu yüzden ben write-through yaklaşımını genellikle sık okunan ve hemen görünmesi gereken verilerde, örneğin stok veya fiyat bilgisinde tercih ediyorum.

Write-behind ne zaman mantıklıdır?

Write-behind, diğer adıyla write-back, yazmayı önce önbelleğe yapar ve veritabanına daha sonra toplu olarak aktarır. Kullanıcı açısından yazma çok hızlıdır, çünkü yavaş kaynağı beklemezsiniz.

Ancak bu desen ciddi bir risk taşır: önbellek sunucusu veriyi veritabanına aktarmadan çökerse o yazmaları kaybedebilirsiniz. Dolayısıyla ödeme, sipariş veya fatura gibi kaybı kabul edilemez verilerde write-behind kullanmam.

Peki nerede işe yarar? Sayfa görüntülenme sayaçları, beğeni sayıları veya analitik olayları gibi yaklaşık doğruluğun yettiği, yazma sıklığının çok yüksek olduğu verilerde anlamlıdır. Örneğin her görüntülenmede veritabanına yazmak yerine sayacı bellekte artırıp dakikada bir toplu kaydedebilirsiniz.

TTL değerini nasıl belirlemelisiniz?

TTL, yani yaşam süresi, bir anahtarın önbellekte kaç saniye kalacağını belirler. Süre dolunca anahtar kendiliğinden geçersiz olur ve bir sonraki okuma veriyi kaynaktan tazeler.

TTL seçerken tek soru sorarım: bu veri ne kadar eski olursa iş zarar görür? Cevaba göre kaba bir tablo çıkarırım. Aşağıdaki aralıklar saha tecrübesine dayalı başlangıç aralığıdır, garanti değildir; kendi trafiğinize göre ölçüp ayarlamanız gerekir.

• Kategori menüsü, site ayarları: saatler mertebesinde.
• Ürün detayları, blog listeleri: birkaç dakika ile bir saat arası.
• Stok ve fiyat: saniyeler ya da olay bazlı temizleme.
• Oturum verisi: kullanıcının oturum süresi kadar.

Bir ipucu daha: çok sayıda anahtara aynı TTL'i verirseniz hepsi aynı anda sona erer. Bu nedenle TTL değerine küçük rastgele bir sapma eklemeyi alışkanlık haline getirin.

Önbellek geçersiz kılma neden bu kadar zordur?

Geçersiz kılma, kaynak veri değiştiğinde önbellekteki eski kopyayı silme veya güncelleme işidir. Zordur, çünkü bir veri parçası çoğu zaman birden fazla önbellek anahtarına dağılmıştır.

Örneğin bir ürünün fiyatını değiştirdiğinizde yalnızca ürün detay anahtarı etkilenmez. Kategori listesi, arama sonuçları, kampanya sayfası ve ana sayfa vitrini de o fiyatı taşıyabilir. Birini unutursanız kullanıcı iki farklı fiyat görür.

Pratikte üç yaklaşım kullanıyorum:

• Olay bazlı silme: Kayıt güncellendiğinde ilgili anahtarları kodda açıkça silersiniz.
• Sürümlü anahtar: Anahtara bir sürüm numarası eklersiniz; veri değişince sürümü artırırsınız ve eski anahtarlar TTL ile kendiliğinden ölür.
• Kısa TTL: Kusursuz tazelik gerekmiyorsa geçersiz kılmayı tamamen TTL'e bırakırsınız.

Kısacası, önbelleğe eklediğiniz her anahtar için "bunu kim, ne zaman silecek?" sorusunun cevabını baştan yazın.

Cache stampede nedir ve nasıl önlenir?

Cache stampede, popüler bir anahtarın süresi dolduğu anda yüzlerce isteğin aynı anda ıska yaşayıp hepsinin birden veritabanına gitmesidir. Veritabanı bu ani yükle yavaşlar, yavaşladıkça daha çok istek birikir ve sistem kilitlenebilir.

Bu sorunu özellikle kampanya saatlerinde, trafiğin tepe yaptığı anlarda görürsünüz. Neyse ki çözümleri iyi bilinir:

• Kilit kullanmak: Iskada yalnızca bir istek veriyi yeniden üretir, diğerleri kısa süre bekler ya da eski değeri alır.
• Rastgele TTL sapması: Anahtarların aynı saniyede sona ermesini engeller.
• Erken yenileme: Süre dolmadan kısa bir süre önce arka planda değeri tazelersiniz.
• Eskiyi sunup arkada yenilemek: Kullanıcıya bir süre eski değeri gösterir, yeni değeri arka planda hazırlarsınız.

Redis tarafında basit bir kilidi SET komutunun NX ve EX seçenekleriyle kurabilirsiniz. Böylece anahtar yoksa kilidi alan tek süreç çalışır ve kilit belirli bir sürede kendiliğinden kalkar.

Bellek dolunca önbellek neyi siler?

Önbellek sınırlı bir RAM üzerinde çalışır ve bellek dolunca yeni veriye yer açmak için bazı anahtarları siler. Bu işleme tahliye, İngilizcesiyle eviction denir; hangi anahtarın gideceğini tahliye politikası belirler.

Redis'te bu davranışı maxmemory ve maxmemory-policy ayarlarıyla yönetirsiniz. Redis'in tahliye dokümanına göre varsayılan politika noeviction'dır; yani bellek dolunca Redis anahtar silmez, yeni yazmalara hata döndürür. Saf önbellek olarak kullanıyorsanız bu varsayılanı mutlaka değiştirmelisiniz.

• allkeys-lru: En uzun süredir kullanılmayan anahtarı siler; genel amaçlı önbellekte iyi bir başlangıçtır.
• allkeys-lfu: En az sıklıkla kullanılan anahtarı siler.
• volatile-lru ve volatile-ttl: Yalnızca TTL tanımlı anahtarlar arasından seçer.
• noeviction: Hiçbir şey silmez, yazmayı reddeder.

Memcached ise bellek dolunca kendi LRU mantığıyla eski öğeleri otomatik olarak çıkarır; ayrı bir politika seçmenize gerek kalmaz.

Redis nasıl çalışır?

Redis, veriyi bellekte tutan ve anahtar değer mantığıyla çalışan bir veri yapısı sunucusudur. Onu sıradan bir önbellekten ayıran şey, değer olarak yalnızca metin değil zengin veri tipleri tutabilmesidir.

Redis string, hash, list, set, sıralı set ve stream gibi yapıları destekler. Örneğin bir liderlik tablosunu sıralı setle, bir iş kuyruğunu list ile, bir kullanıcı profilini hash ile modellersiniz. Bu sayede sunucu tarafında sıralama veya sayma gibi işlemleri tek komutla yaparsınız.

Ayrıca Redis kalıcılık sunar. RDB belirli aralıklarla anlık görüntü alır, AOF ise her yazma komutunu bir günlük dosyasına ekler. Böylece sunucu yeniden başladığında veriyi diskten geri yükleyebilirsiniz.

Komut yürütme ağırlıklı olarak tek bir ana iş parçacığında gerçekleşir; Redis 6 ile birlikte ağ girdi çıktısı için ek iş parçacıkları geldi. Tek iş parçacıklı yürütme, her komutun atomik çalışmasını sağlar. Öte yandan çok uzun süren tek bir komut, örneğin büyük bir anahtar kümesini tarayan KEYS, diğer tüm istekleri bekletir.

Redis'te replikasyon ve küme nasıl işler?

Redis, bir ana sunucudan bir veya daha fazla kopya sunucuya replikasyon destekler. Okuma yükünü kopyalara dağıtabilir, ana sunucu çöktüğünde Sentinel ile otomatik devralma kurabilirsiniz.

Veri tek bir sunucunun belleğine sığmadığında Redis Cluster devreye girer. Cluster anahtar alanını 16.384 hash slotuna böler ve bu slotları düğümlere dağıtır. Böylece veriyi yatay olarak birden çok makineye yayarsınız.

Bir de lisans konusunu bilmelisiniz. Redis 2024'te BSD lisansından RSALv2 ve SSPLv1 ikili lisansına geçti; Redis 8 ile AGPLv3 seçeneği de eklendi. Bu değişiklik sonrasında Linux Foundation çatısı altında Valkey adlı açık kaynak bir çatal doğdu. Kurumsal projelerde hangi dağıtımı kullandığınızı hukuk ekibinizle birlikte netleştirmenizi öneririm.

Memcached nasıl çalışır?

Memcached, yalnızca önbellek olmak için tasarlanmış, sade ve çok iş parçacıklı bir bellek içi anahtar değer deposudur. Değerleri yorumlamaz; ona bir bayt dizisi verirsiniz, o da aynen geri döndürür.

Belleği slab adı verilen boyut sınıflarına bölerek yönetir. Bu yaklaşım bellek parçalanmasını azaltır, fakat çok farklı boyutta değerler sakladığınızda bir miktar alan israfına yol açabilir. Memcached wikisine göre varsayılan en büyük öğe boyutu 1 MB'dır ve anahtarlar en fazla 250 bayt olabilir; öğe sınırını başlangıç parametresiyle değiştirebilirsiniz.

Memcached kalıcılık ve yerleşik replikasyon sunmaz. Birden çok sunucuya dağıtım genellikle istemci tarafında tutarlı karma ile olur; yani hangi anahtarın hangi sunucuya gideceğine istemci kütüphanesi karar verir. Kısacası Memcached bir şeyi yapar ve onu hızlı yapar.

Bu sadelik bir avantajdır. Yapılandırılacak az şey olduğu için yanlış yapılandırma riski de düşer ve çok çekirdekli sunucularda iş parçacıkları sayesinde yükü rahatça dağıtırsınız.

Küçük bir tuzağa dikkat edin: Memcached'de 30 günden uzun bir süre verirseniz sistem bu değeri saniye olarak değil Unix zaman damgası olarak yorumlar. Yanlış hesaplanmış bir değer, anahtarın hemen sona ermesine neden olabilir.

Redis ve Memcached arasındaki farklar nelerdir?

İki araç da bellekte çalışır ve basit önbellek işlerinde benzer hızlar sunar. Asıl fark, sundukları özellik genişliğinde ve operasyon modelindedir. Aşağıdaki tablo seçimi kolaylaştırmak için temel farkları özetliyor.

Tablodan da anlaşılacağı gibi Redis bir İsviçre çakısına, Memcached ise tek işlevli keskin bir bıçağa benzer.

Hangi durumda Redis, hangi durumda Memcached seçmelisiniz?

Yeni projelerin büyük çoğunluğunda Redis ile başlıyorum. Bunun nedeni hız farkı değil; aynı altyapıyla önbellek, oturum deposu, kuyruk ve hız sınırlama gibi ihtiyaçları tek araçla karşılamanızdır.

Redis'i şu durumlarda seçin: sıralı listeler veya sayaçlar gibi veri yapılarına ihtiyacınız varsa, yeniden başlatmada verinin kalması önemliyse ya da pub/sub ile anlık bildirim kuracaksanız.

Memcached ise şu durumlarda mantıklıdır: yalnızca basit ve geçici nesne önbelleği gerekiyorsa, çok çekirdekli tek bir sunucudan en yüksek verimi almak istiyorsanız veya mevcut altyapınız zaten Memcached üzerine kuruluysa. Örneğin eski bir PHP projesinde çalışan Memcached kurulumunu yalnızca moda uymak için değiştirmem.

Son olarak ekibin bilgisini hesaba katın. İyi bildiğiniz sade bir araç, yarım bildiğiniz güçlü bir araçtan daha güvenlidir.

Bulut tarafında da iki seçenek yaygındır. AWS ElastiCache gibi yönetilen hizmetler hem Redis uyumlu motorları hem Memcached'i sunar; böylece yedekleme, yama ve devralma işini sağlayıcıya bırakırsınız. Küçük projelerde ise aynı sunucuya kurulan tek bir Redis örneği çoğu zaman yeterlidir.

Tam sayfa önbellekleme ile nesne önbellekleme arasındaki fark nedir?

Tam sayfa önbellekleme, sunucunun ürettiği HTML çıktısının tamamını saklar ve sonraki ziyaretçiye aynen gönderir. Nesne önbellekleme ise sayfanın parçalarını, örneğin bir sorgu sonucunu veya hesaplanmış bir menüyü saklar; sayfa her istekte bu parçalardan yeniden birleşir.

Tam sayfa önbellekleme en büyük hız kazancını verir, çünkü uygulama kodu neredeyse hiç çalışmaz. Ancak sepet, oturum açmış kullanıcı adı veya kişiye özel fiyat gibi değişken alanlar içeren sayfalarda tehlikelidir. Bu yüzden blog yazıları, kurumsal tanıtım sayfaları ve kampanya açılış sayfaları için tam sayfa önbellekleme uygularım.

Nesne önbellekleme ise daha esnektir. Kişiye özel sayfada bile ortak parçaları, örneğin kategori ağacını veya ürün özelliklerini önbellekten okursunuz. Pratikte iki yöntemi birlikte kullanırsınız: anonim ziyaretçiye tam sayfa, giriş yapmış kullanıcıya nesne önbellekleme.

Oturum verisini önbellekte tutmak mantıklı mı?

Evet, çoğu durumda mantıklıdır ve Redis'in en yaygın kullanım alanlarından biri tam olarak budur. Birden fazla uygulama sunucusu çalıştırdığınızda oturumu dosyada tutarsanız kullanıcı her istekte farklı sunucuya düşer ve oturumu kaybolur. Oturumu ortak bir Redis sunucusunda tuttuğunuzda bu sorun ortadan kalkar.

Yine de burada saf önbellekleme mantığından farklı düşünmelisiniz. Oturum verisi silindiğinde kullanıcı sistemden atılır; dolayısıyla bu anahtarların tahliye politikası tarafından rastgele silinmesini istemezsiniz. Ben oturumları genellikle ayrı bir Redis örneğinde ya da ayrı bir veritabanı numarasında tutuyorum.

Ayrıca oturum TTL'ini güvenlik politikanızla uyumlu tutun. Çok uzun oturum, çalınan bir çerezin uzun süre işe yaramasına izin verir.

Önbellekleme katmanının güvenliğini nasıl sağlarsınız?

Önbellekleme sunucuları hızlı olmak için tasarlandığından varsayılan kurulumlarda güvenlik ikinci planda kalabilir. İnternete açık, parolasız bir Redis veya Memcached sunucusu, saldırganların veri okuması ve hatta sunucuyu kötüye kullanması için davetiye çıkarır.

• Önbellek sunucusunu yalnızca özel ağa veya localhost'a bağlayın.
• Redis'te parola ve ACL ile kullanıcı bazlı yetki tanımlayın.
• Güvenlik duvarında ilgili portu dış dünyaya kapatın.
• Ağ üzerinden bağlanıyorsanız TLS şifrelemesini açın.
• Önbelleğe kart bilgisi veya parola gibi hassas veriyi hiç yazmayın.

Kısacası önbellekleme katmanını veritabanı kadar ciddiye alın; içinde aynı verinin kopyası duruyor.

Önbellekleme hangi durumlarda gereksizdir?

Her proje önbelleğe ihtiyaç duymaz. Günde birkaç yüz ziyaret alan, sorguları zaten milisaniyeler içinde dönen küçük bir kurumsal sitede önbellekleme eklemek, fayda getirmeden yeni bir hata kaynağı yaratır.

Ayrıca her istekte benzersiz sonuç üreten işlemler, örneğin kişiye özel rapor sorguları, önbellekten pek fayda görmez; isabet oranı hep düşük kalır. Önce veritabanı indekslerini ve sorgu yapısını düzeltin. Çoğu zaman eksik bir indeks, önbellekleme katmanından çok daha büyük kazanç sağlar.

Benim kuralım şu: ölçüm yapıp darboğazı gördükten sonra önbellekleme eklerim, önce değil.

Önbellek anahtarlarını nasıl tasarlamalısınız?

Anahtar tasarımı ilk bakışta önemsiz görünür, ancak geçersiz kılmanın kolaylığı doğrudan buna bağlıdır. İyi bir anahtar okunabilir, benzersiz ve tahmin edilebilir olmalıdır.

Ben genellikle "uygulama:varlık:kimlik:sürüm" kalıbını kullanıyorum. Örneğin "shop:urun:4521:v3" anahtarı neyi tuttuğunu tek bakışta anlatır. Dil veya para birimine göre değişen içeriklerde bu bilgiyi de anahtara eklersiniz; aksi halde Türkçe sayfa Almanca kullanıcıya gidebilir.

Ayrıca üretimde KEYS komutuyla desen araması yapmaktan kaçının; büyük veri setinde sunucuyu bloklar. Toplu silme gerekiyorsa SCAN komutunu ya da sürümlü anahtar yaklaşımını tercih edin. Kullanıcıya özel veriyi ise asla herkese açık bir anahtarda tutmayın; kişisel veri sızıntısının en sessiz yolu budur.

Önbellekleme site hızını ve SEO'yu nasıl etkiler?

Önbellekleme, sunucunun ilk bayta yanıt süresini, yani TTFB'yi doğrudan kısaltır. Sayfa her istekte veritabanından yeniden üretilmediği için HTML daha erken yola çıkar ve tarayıcı sayfayı daha erken çizmeye başlar.

Google, sayfa deneyimini değerlendirirken Core Web Vitals metriklerine bakar ve yavaş sunucu yanıtı LCP'yi olumsuz etkiler. Bu ilişkiyi site hızının SEO'ya etkisi yazımda ayrıntılı anlattım. Değişikliğin etkisini ölçmek için Lighthouse ile performans testi rehberindeki adımları izleyebilirsiniz.

Öte yandan önbellek arama motoru tarayıcıları için de önemlidir. Hızlı yanıt veren bir sunucu, tarayıcının aynı sürede daha çok sayfa ziyaret etmesine izin verir. Teknik tarafın diğer başlıkları için teknik SEO ipuçları yazısına göz atabilirsiniz.

Önbellekleme projelerinde en sık hangi hatalar yapılıyor?

Denetlediğim projelerde aynı hataları tekrar tekrar görüyorum. Çoğu teknik değil, planlama eksikliğinden doğuyor.

1. Her şeyi önbelleğe almak: Nadiren okunan veri belleği doldurur ve işe yarayan anahtarları tahliye ettirir.
2. TTL koymamak: Süresiz anahtarlar zamanla eski veriyle dolar.
3. Varsayılan tahliye politikasını bırakmak: Redis bellek dolunca yazma hatası verir ve uygulama çöker.
4. Kişiye özel sayfayı paylaşılan önbelleğe koymak: Bir kullanıcının sepeti başka kullanıcıya görünebilir.
5. Önbelleği birincil veri kaynağı gibi kullanmak: Kalıcılık ayarı olmadan kritik veriyi yalnızca önbellekte tutmak veri kaybına yol açar.
6. Ölçmeden optimize etmek: Hangi sorgunun yavaş olduğunu bilmeden önbellek eklemek, sorunu gizler ama çözmez.

E-ticaret sitelerinde son maddeyi özellikle önemsiyorum; bu tür altyapı kararlarını e-ticaret danışmanlığı sürecinde ölçüme dayanarak veriyorum.

Önbellek performansını nasıl ölçersiniz?

Ölçmediğiniz önbellek, çalışıp çalışmadığını bilmediğiniz bir önbellektir. Bu yüzden en az dört metriği düzenli izlemenizi öneririm.

• İsabet oranı: Redis'te INFO stats çıktısındaki keyspace_hits ve keyspace_misses değerlerinden hesaplarsınız.
• Bellek kullanımı: maxmemory sınırına ne kadar yaklaştığınızı gösterir; sürekli sınırda çalışmak tahliyeyi artırır.
• Tahliye sayısı: evicted_keys hızla artıyorsa bellek yetersizdir ya da gereksiz veri saklıyorsunuz.
• Yanıt süresi: Uygulama tarafında önbellekli ve önbelleksiz isteklerin sürelerini ayrı ayrı kaydedin.

Ayrıca yavaş komutları görmek için Redis'in SLOWLOG özelliğini kullanabilirsiniz. Böylece tek bir ağır komutun tüm sistemi beklettiği durumları erkenden yakalarsınız.

Uygulama tarafında ise her önbellek çağrısını etiketleyerek loglamak işinizi kolaylaştırır. Örneğin hangi anahtar grubunun en çok ıska ürettiğini gördüğünüzde, TTL'i mi uzatmanız yoksa geçersiz kılma kuralını mı düzeltmeniz gerektiğini hemen anlarsınız.

Önbellekleme stratejisini nereden başlatmalısınız?

Önbellekleme yolculuğuna küçük başlayın. Önce uygulamanızın en yavaş ve en sık çalışan beş sorgusunu bulun; çoğu zaman yükün büyük kısmı birkaç sorgudan gelir. Ardından bu sorgulara cache-aside deseniyle kısa bir TTL uygulayın ve isabet oranını izleyin.

İkinci adımda geçersiz kılma kurallarını yazıya dökün. Hangi kayıt değiştiğinde hangi anahtarların silineceğini bir tabloda tutmak, ekibe yeni katılan geliştiricinin de hata yapmasını önler. Sonra stampede korumasını ekleyin.

Üçüncü adımda izlemeyi kurun. İsabet oranı, bellek kullanımı ve tahliye sayısı için basit bir panel bile, önbellekleme katmanının sessizce bozulduğu anı haftalar öncesinden gösterir. Son adımda ise kararlarınızı belgeleyin: hangi veri neden önbellekte, TTL neden bu değerde, kim temizliyor. Bu belge, altı ay sonra sistemi devralan kişinin en değerli rehberi olur.

Mimarinin büyüdüğü projelerde önbellek katmanı, ön yüzün nasıl bölündüğüyle de ilişkilidir; bu konuyu micro frontend mimarisi yazısında ele aldım. Yeni bir site kuruyorsanız önbellek kararlarını en baştan web tasarım planına dahil etmek, sonradan yama yapmaktan çok daha ucuza gelir. Alan adınızın doğru sunucuyu gösterdiğini kontrol etmek için DNS sorgulama aracını, yönlendirme zincirlerini görmek için de yönlendirme denetleyicisini kullanabilirsiniz.